MichaelPrice

• The Future of C++

  Nov 02, 2012 at 8:01 AM

  Just to clear it up, this will be broadcast live?  On this page or on some other one?

• Day 2 Keynote - Herb Sutter: C++11, VC++11 and Beyond

  Feb 24, 2012 at 8:26 AM

  @Charles: Yep, ended up seeing it in his Twitter feed about 8:00 PM last night!

• Day 2 Keynote - Herb Sutter: C++11, VC++11 and Beyond

  Feb 23, 2012 at 11:03 AM

  Charles, Herb, or Stephan:

  I've been anticipating a Beta release of VS11 for weeks now... and we are rapidly nearing the end of February.  Is a February Beta release still going to happen?

• C&B 2011 Panel: Herb Sutter, Andrei Alexandrescu and Scott Meyers - C++11

  Oct 07, 2011 at 8:53 AM

  @Waldemar Pawlaszek: Isn't it the job of the class with the non-public constructor to define who it's friends are? If he would like for someone to be able to make shared_ptrs to him, then he can have make_shared be a friend function or he can just have a

  template <typename ... Params>
  static shared_ptr<Me> make_shared (Params && ... params)
  {
      // call to std::make_shared here...
  }

• C&B 2011 Panel: Herb Sutter, Andrei Alexandrescu and Scott Meyers - C++11

  Oct 06, 2011 at 8:57 AM

  17 hours ago, new2STL wrote

  @Philhippus: C&B2011 take place before the finalizing of the standard, I think they are talking about what Stephan called lambdas v1.1 (in reference to some last minute revision on decltype), I'm not the right person to answer it anyway but hope helped.

  While the standard had not been voted on at the point that C&B2011 took place (it was unanimously approved a few days later), it's content had been all but frozen since early summer, particularly the language surrounding lambdas.  Although I have yet to hear Scott's actual comment, my guess would be that he is ribbing Herb about the lack of "polymorphic lambdas"; the idea that lambdas should be able to infer the types of their parameters instead of being explicit in the lambda declaration.

• GoingNative Live at BUILD: Herb Sutter, Joanna Mason, Tony Goodhew

  Sep 30, 2011 at 7:06 AM

  I'm taken back by the vitriol in many posts about C++.  I love C++ as much as the next guy (or I thought I did), but the fact that Microsoft will not have completed any significant features of C++11 (beyond what was in VC10) is not the end of the world.

  I am very disappointed, but I also understand why it has happened.  If Microsoft cannot get Metro launched with great success, then Microsoft will be in for a rough time over the next 5 years.  It is a testament of the power of C++ that they came back to native in order to ensure the success of this platform.

  Sure, MS could have done a better job of managing their product backlog (suspending variadic work at the first sign of trouble for instance), but they didn't, which means that they can learn from this.  If anything, it seems like there is a push (probably thanks to Herb) to reduce the amount of time between release of new compiler features because of this failure.  THIS IS A GOOD THING!!!

  Advice for the trolls: How about you worry about your own feature set and shipping on time instead of needlessly attacking someone who is improving a broken system from the inside?

• C++ and Beyond 2011: Benedict Gaster on C++11, C++ AMP, C++ Renaissance

  Sep 01, 2011 at 11:09 AM

  @Ian: I disagree.  Example (please ignore the poor memory management in the example):

  class Base
  {
  public:
      void X () { cout << "Base" << endl; }
  
  protected:
      Base() { }
  };
  
  class Derived : public Base
  {
  public:
      Derived() { }
  
      void X () { cout << "Derived" << endl; } // Hides Base::X
  };
  
   Base * getObject() { return new Derived; }
  // Refactor ^ into V
  //Derived * getObject() { return new Derived; }
  
  int main ()
  {
      auto aobj = getObject();
      aobj->X();
  
      Base * bobj = getObject();
      bobj->X();
  }

  By refactoring some code, you get very different behavior (perhaps unexpected) in the using code that uses 'auto'.

  IMO, 'auto' usage is appropriate under two scenarios (particularly where the two scenarios overlap):

  1) Extremely long type name that is not frequently used within a particular scope.  If you use the type more than once or twice, consider a typedef instead.  This should be a rare usage.

  2) Code that is likely to survive a refactor, such as swapping out a std::list and a std::vector.

  These two overlap iterating over a container, which *should* the the predominant usage of 'auto' (see range-based for-loop for an example).

• GoingNative 1: VC++ vNext, CRT, C++ and Beyond

  Aug 31, 2011 at 9:03 AM

  1 day ago,STL wrote

  [MichaelPrice]
  > What is up with that range-for snippet?  The snippet should read:
  > for (object var : collection_to_loop) { }
  > instead of
  > for each (object var in collection_to_loop) { }

  "for each" is an old non-Standard extension. I recommend against using it (as it's generating weird code that can't be used to mutate elements in place). Either "for (auto i = v.begin(); i != v.end(); ++i)" or "std::for_each(v.begin(), v.end(), lambda)" are superior.

  Note that the C++11 range-based for-loop (which is not implemented in VC10; when it is implemented, it will not be vulnerable to the non-Standard "for each" extension's problems, because C++11 has carefully specified it) is best used as either "for (auto& e : v)" or "for (const auto& e : v)" which loops over elements in-place (and permits modification if you wish). "for (auto e : v)" will copy elements, and cannot modify elements in-place.

  I wonder if there will be room in the C++ snippets to generate the byref and byconstref patterns.  Picking a "default" pattern could be a very risky move...

  However, if I had to vote for a default, it would be for (const object & var : collection_to_loop) as it is the "safest" pattern.

  Also, I agree about std::for_each... Let the library do the hard thinking (and possibly optimization) for you.

• GoingNative 1: VC++ vNext, CRT, C++ and Beyond

  Aug 26, 2011 at 10:40 AM

  @Charles: Well technically (with the appropriate cajoling), you can call a destructor manually.  It's just typically a really bad idea.

  I've had to do it before in the case where we didn't want to link the to the CRT.  Unfortunately, the CRT handles calling constructors and destructors of global statics.  So, we had to hand-roll the code to call those guys ourselves.

• GoingNative 1: VC++ vNext, CRT, C++ and Beyond

  Aug 26, 2011 at 7:45 AM

  @Charles: Oh, and you are correct, clang is definitely behind gcc in terms of C++11 implementation.  However, the rate of adoption in clang has been much faster over the past 3-4 months than it ever was for gcc (of course gcc has most of it implemented now, so it has naturally slowed down.  gcc had the benefit of a few extra years of development before clang really got C++03 fully implemented.

  If you cannot tell, I'm a fan of clang (although I primarily work in VC++).

See more comments…