C++ Standard

RE: The View (or trip report) from the Mar 2009 C++ Standard meeting

Michael_Wong — Wed, 09 Sep 2009 19:24:41 GMT

Thanks Thomas for the question and your interest. I will try to get that up soon and let you know. Do you have an interest in some parts of the talk?

RE: The View (or trip report) from the Mar 2009 C++ Standard meeting

ThomasPetit — Tue, 08 Sep 2009 06:52:54 GMT

"While I am on BoostCon09, I did a 90 minute talk on the Overview of C++0x and compiler support.
...
The video of the talk will be online soon."

Any news ?

RE: Mysteries of Namespaces

Michael_Wong — Thu, 19 Feb 2009 07:08:09 GMT

Nice work!

So from the answer to MOM#2, we can see that a using directive is like using a sledge hammer to your namespace, while a using declaration can be evil in that it depends on the order of includes.

I think I defintely agree that function scope is probably the best way to use it. The same goes for not ever putting either of them in header files. In one case, they bring in all kinds of names. In the other case, we have order dependency problems.

As for the middle two choices, either before or after the include in your CU, I would say definitely never use either of them before the #include. This is agreed by some noted authors.

As for after the include, I can't really think of a reason to discourage their use as long as it makes sense for your use.

RE: Mysteries of Namespaces

Michael_Wong — Thu, 19 Feb 2009 06:48:46 GMT

Yes, that is correct. The using directive effectively makes the names available from the namespace, making them accessible without qualification. It also makes it as if they were declared at global scope, not at the scope of the using directive. So as a result, local names will hide the namespace names.
The names also remain in force until the end of the function body.

Using declaration is less forceful and provides a middle ground between explicit qualification, and bulldozing your namespace with all the names. A using declaration is an actual declaration, and any local names that are not the same type will lead to a redeclaration error. This is what you observed in the second code snippet.

From this discussion, it is pretty clear that a using-declaration requires that the name it declare must have already been seen. This makes a using-declaration order dependent when using names from a namespace split across a group of header files. This is potentially bad. The order of header inclusion relative to where the using-declaration appears is important and can change. Of course, the std namespace is one such namespace that is split across multiple headers.

So here is another difference with a using directive. Unlike a using-declaration, a using directive brings in names declared in namespaces both before and after the using directive. The name's declaration has to be still seen for it to be used, of course. This also makes using-directive powerful, and deadly in a different way then a using-declaration.

RE: Mysteries of Namespaces

JiChao — Wed, 18 Feb 2009 15:36:35 GMT

For mystery #3, I am not aware of any problem puting using declaration/directive in function scope. It is not a good iead to put them in the file scope of a header file though. Adding them in the header file will potentially pollute the declarative scope of any files including the header file. Puting them in header file ahead of include can cause more problem because the names brought in are now visible in all included files, which might cause conflict or change the semantics. It's generally better to use qualified name such as std::vector in header files.

RE: Mysteries of Namespaces

JiChao — Wed, 18 Feb 2009 15:29:12 GMT

For mystery #2, using declaration introduces the name to the current scope while using directive makes the name visible in the current scope.

So for the first code snippet, the definition of the integer vector hides the definition of vector in std. For the second code snippet, using declaration brings the name vector in to the local scope and the definition of the integer vector causes a conflict.

RE: Mysteries of Namespaces

Michael_Wong — Tue, 10 Feb 2009 15:51:34 GMT

Yes, you are right. I am guessing there were just too much legacy associated with these to move them into another namespace.

RE: Mysteries of Namespaces

hstong — Tue, 10 Feb 2009 15:26:28 GMT

For mystery #1, aside from the C standard library macros, the operators new and delete in <new> come to mind.

RE: C++0x delegating constructors

Michael_Wong — Fri, 12 Dec 2008 04:23:49 GMT

I think I have to give it to you for the many cases you described. What I was looking for is not that far from what you were describing. It is that now in Mystery #2, we have an imbalance in the number of constructor and destructors, which is always a sign that something bad will happen. May be not immediately, but likely when you add any more complexity to the class (such as more members).

Just counting the construction of X, you will see that there are 2 constructor calls, and only one destructor call. This, as you said, is the worst solution. Well done.

RE: C++0x delegating constructors

hstong — Fri, 05 Dec 2008 00:19:24 GMT

I think that the standard is a bit vague on what constitutes a "reuse" of storage. This makes it hard for me to tackle the issue with object lifetimes directly. Anyhow, another case where the placement new solution above will not work is when the object of type X is actually a base class subobject itself.

RE: C++0x delegating constructors

Michael_Wong — Thu, 04 Dec 2008 14:14:23 GMT

Not bad, and you are definitely dancing around the whole issue of object life times which is where the answer lies.

My response to this is that there is indeed a memory leak, but it need not be from any dynamic memory allocation of subobjects (which I assume you mean embedded members Y and Z).

RE: C++0x delegating constructors

hstong — Thu, 04 Dec 2008 00:38:39 GMT

The subobjects did not have their destructors called. There can be a memory leak if a subobject allocated memory dynamically.

RE: C++0x delegating constructors

Michael_Wong — Wed, 03 Dec 2008 21:38:58 GMT

Even if an exception is not thrown, this code has problems ...
But you are right in that an exception would be even more problematic.

RE: C++0x delegating constructors

hstong — Wed, 03 Dec 2008 20:49:06 GMT

Mystery #2:
Among other things, destructors for the members of X will be called twice if init() throws an exception.
This is the worst solution because it has undefined behaviour.

RE: C++0x delegating constructors

Michael_Wong — Wed, 03 Dec 2008 20:22:30 GMT

Good work!. You are right. The temporary will get created, and destroyed at the end of scope. No delegation.

RE: C++0x delegating constructors

hstong — Wed, 03 Dec 2008 20:09:01 GMT

Mystery #1:
In

X( int i ) : y_( i ),z_(1.23) { X(); }

you are constructing a temporary and not delegating to the default constructor (as intended).

RE: The Dawn of a new Standard

Michael_Wong — Thu, 20 Nov 2008 17:12:54 GMT

Thanks, Bjarne for visiting our blog. IBM, like other compilers, are in the process of implementing many C++0x features. Some of which are already released in xlC V10.1 for AIX and Linux.

http://www-01.ibm.com/software/awdtools/xlcpp/aix/
http://www-01.ibm.com/software/awdtools/xlcpp/linux/

In that release, we have implemented C++0x long long and C99 synchronization.The way to access it is to use the option -qlanglvl=extended0x

There is a free trial download as well.

The order of implementation and release will be dictated by many priorities, including not necessarily in any order, customer requests, feature completeness in the standard, dependencies on other features, etc.

Of course, the opinion and specific request of the inventor of C++ will take a certain priority in this overall list
And if others would like to have input into the order, please discuss here or in the forum.

We wish to thank-you for the leadership you have shown in leading the Evolution Group of the C++ Standard towards C++0x.

RE: The Dawn of a new Standard

xxxxxxxxxxx — Tue, 18 Nov 2008 20:58:29 GMT

Yes, there are lots of new features. We hope they'll fit together like a set of Lego blocks to support more powerful styles. Let's hope x in C++0x becomes 9.

When will IBM start "dribbling out" C++0x features. I'd like to see "auto" and uniform initialization soon. I guess you'd like to see attributes and user-defined literals

--- Bjarne; http://www.research.att.com/~bs