posted by MichaelPrice

posted by MichaelPrice

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?

posted by MichaelPrice

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

posted by MichaelPrice

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.posted by MichaelPrice

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?

posted by MichaelPrice

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).

posted by MichaelPrice

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.

posted by MichaelPrice

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.

posted by MichaelPrice

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

posted by MichaelPrice

As of revision 130953 committed on May 5, 2011, clang definitely claims to.  I haven't tried writing code against it though.

posted by MichaelPrice

for (object var : collection_to_loop) { }

instead of

for each (object var in collection_to_loop) { }

see http://en.wikipedia.org/wiki/C%2B%2B0x#Range-based_for-loop

Also, the one C&B attendees comment about lack of support for template aliasing in compilers.... Clang (at least top-of-tree) had it before the conference started.

posted by MichaelPrice

@Alex C:See theGoingDeep::Advanced_STL_1, its about shared_ptr, also the videos from introductory series are worth to be seen

I think that "Alex C" was reading "MyType ^ ptr0" instead of "MyType * ptr0".  The first is potentially valid if MyType was a CLR type and we were compiling with the C++/CLI switch (/clr).  Thus his use of the term "handle" and "plain C++ pointer".

posted by MichaelPrice

1 day ago

On the code example at 7min 22s, why are you using a handle to object instead of a plain C++ pointer?

The screen resolution makes the asterisk look like a caret.

posted by MichaelPrice