At the latest SD in San Francisco, Dan Saks and I stayed together as usual. On our final night there, a secret cabal met in our hotel room. There we hatched a diabolical plot to take over the world from the moon, unless we were paid...One Mil-li-on Dollars.
But then Scott Meyers decided that was below his dog’s customary honorarium, so we dropped the idea.
Instead, we came up with a Plan B: hold a C++ seminar in stunning Lake Oswego, Oregon, the center of the known C++ universe. This seminar would be taught by top experts in that universe, who would present classes together, hobnob with attendees, and spar on panels. It would be like SD without the booth babes.
After much dithering, we came up with a name: The C++ Seminar — 3 Days With 5 Experts. Those experts (in the order listed on their website [1]) are Scott Meyers, Herb Sutter, Dan Saks, Steve Dewhurst, and Andrei Alexandrescu. All of these guys have written, or currently write, for CUJ.
The seminar dates are September 17-19, 2001. And yes, the venue really is Lake Oswego, near Portland.
I expect to be there, but only to watch, kibitz, and quote the Standard [2]. Trust me, I get no kickback for mentioning this seminar. I’m plugging it here because I think the 3 Days will be an unmitigated blast. I highly encourage you to consider going — but register soon, because the start date is just a few weeks away from when you see this.
2-for-1 Special
Q
Dear Sir:
I have a question regarding smart pointers. In my example, how does the compiler transform one -> into two ->?
Thanks for your help.
Sincerely — Jason Ou
A
I’ve recast your example as
struct X
{
int m;
};
class Ptr
{
public:
Ptr(X *);
X *operator->();
};
Ptr p = new X;
p->m = 7;
// OK, same as
// (p.operator->())->m = 7
The compiler transforms
p->m
into
(p.operator->())->m
because the C++ Standard says so. From Subclause 13.5.6:
operator-> shall be a non-static member function taking no parameters. It implements class member access using ->
postfix-expression -> id-expression
An expression x->m is interpreted as (x.operator->())->m for a class object x of type T if T::operator->() exists and if the operator is selected as the best match function by the overload resolution mechanism.
Why does the Standard have this rule? Because such a transformation makes the most sense.
p may not be a pointer, but it is supposed to act like one. Users probably expect that the expression p->m nets out to the m member referenced by p, regardless of whether p is a real pointer or a fake/smart pointer. For this to work, the subexpression p-> must result in something that can be dereferenced to get member m.
While the designers of Standard C++ had several choices here, they settled on the one I find most direct and consistent: the subexpression
p->
is interpreted as
(p.operator->())->
For this interpretation to work, (p.operator->()) must suffice as an operand to ->. And indeed, if you look at the declaration of function p.operator->, you’ll see that it returns X *, which can serve as the operand of ->.
This way, regardless of whether p is a real pointer or not, the subexpression p-> has the same interpretation: get a pointer (smart or otherwise) to a class object, and then dereference that pointer to get to the class member that follows.
Variation #1: p-> could yield an object of some unrelated type that happens to have an m member:
struct X
{
int m;
};
struct Z // no relation to X
{
long m;
};
class Ptr
{
public:
Ptr(X *);
Z *operator->();
//
// ^ change
//
};
Ptr p = new X;
p->m = 7;
//
// OK but misleading — the m is
// a member of type Z, not type X
Such a change would destroy the symmetry between p and a real pointer.
Variation #2: The second -> in (p.operator->())-> could itself be interpreted as another operator-> call:
struct X
{
int m;
};
struct Z
{
X *operator->(); // inserted
/* int m; */ // deleted
};
class Ptr
{
public:
Ptr(X *);
Z operator->();
//
// ^
// change — note that operator-> now
// returns an object, not a pointer
//
};
Ptr p = new X;
p->m = 7;
// OK, same as
// ((p.operator->()).operator->())->m = 7
I explored the possibility of cascading operator-> calls in my December 1998 item “Russian Dolls” and April 1999 follow-up item “Mars and Venus.”
Namespace Madness
Q
Dear CUJ,
How do you control the scope of using namespace within header files? Suppose a header file contains:
class Foo
{
public:
string name();
private:
vector<int> _array;
};
string and vector are both defined within the std namespace. When converting to ANSI C++, I find myself typing
class Foo
{
public:
std::string name();
private:
std::vector<int> _array;
};
which gets tedious and difficult to modify. And the following is bad form
using namespace std; class Foo // ...
since this using directive has global scope and will be imposed on every file that includes the header file.
What I’d really like to do is limit the scope of the directive as follows:
class Foo
{
using namespace std;
public:
string name();
private:
vector<int> _array;
};
but my Sun Workshop 6 compiler doesn’t allow it (although it makes sense to me).
Any solutions? — Stewart Trickett
A
Yes, but all are approximations of what you really want. I’ll let you decide which — if any — suits your needs.
But before that, I must mention two lapses of Uncaught Exceptions etiquette:
- No More Foos! For the rest of this answer, I will call your class Oof.
- No leading underscores in names, unless you are implementing a standard library [3]. I will therefore substitute array_ for _array.
The column’s karmic balance now restored, let’s get to your question...
Solution #1: Substitute using declarations for a using directive at global scope:
using std::string;
using std::vector;
class Oof
{
public:
string name();
private:
vector<int> array_;
};
Because only the specifically-declared names appear to be at global scope, you’ve vastly reduced the chance of name collision and accidental misuse. This reduction comes at a maintenance cost: you must add a new using declaration for each std member you want to introduce this way.
Solution #2: Declare Oof in a named namespace, and put the using directive there:
namespace N
{
using namespace std;
class Oof
{
public:
string name();
private:
vector<int> array_;
};
}
Since you’re back to the using directive, all std names are brought in, and your maintenance cost goes down. And because the using directive appears in the scope of N, std entities appear global only within the context of N.
Drawbacks:
- std entities appear to the outside world as if they were declared in N. As an example, users can declare N::list<int> x successfully.
- Oof, which used to be at global scope, is now within the scope of N. Your users must either refer to Oof as N:Oof or introduce the name into another scope by (you guessed it) using namespace N or using N::Oof.
Solution #3: Combine the first two solutions, with using declarations instead of a using directive within N:
namespace N
{
using std::string;
using std::vector;
class Oof
{
public:
string name();
private:
vector<int> array_;
};
}
This has the same net effect as Solution #2, with one difference: only the specifically-declared std names are introduced, not the whole lot.
Solution #4: Create private aliases within Oof for the std entities of interest:
class Oof
{
private:
typedef std::string string;
typedef std::vector<int> vector_int;
public:
string name();
private:
vector_int array_;
};
Now you can put Oof back into the global namespace. You also have no std names appearing at other scopes.
But as with the using declarations earlier, you must explicitly list out the std entities you want, with an added limitation: you can’t alias a template name. That’s why I have a typedef for the specialization std::vector<int> and not for the general template std::vector.
There are other ideas you can try — nested namespaces, namespace aliases, macros — but I think what I’ve shown should give you a good start.
Which do I recommend? That depends on several factors, including how many std entities you’re talking about, how likely you are to modify the header over time, and how often you reference the header’s declarations. In a knowledge vacuum, my bias is toward Solution #4, but only for the most commonly-used or awkwardly-named std entities; otherwise I’d just spell out the std:: prefix.
Erratica
Regarding my June 2001 column item “Oh Say Can You C,” which concerns C programs calling C++ functions, Diligent Reader Phil Brooks asks:
“Doesn’t extern "C" generally work so that one can call a [C++] function declared extern "C" from a straight C program? If that is the case, I think your user can get what he is looking for simply by declaring the extern "C" function in a C header file.”
Both Phil and Diligent Reader Jon Young sent small code examples implementing this assumption. Jon says the code works in Visual C++, although I’d expect the general technique to work with most compilers that accept both languages.
Yes guys, this technique may work, but it’s not guaranteed by the C++ Standard [4]. From Subclause 7.5/3:
Every implementation shall provide for linkage to functions written in the C programming language, "C"...
As this passage implies, extern "C" intentionally describes the source language of the implementing code, not the source language of the calling code. It’s specifically meant to let a C++ program link to C functions, not the other way around. I’m guessing the original motivation was to turn off a C++ compiler’s expectation that C functions would have mangled names.
The C++ Standard can dictate only the behavior of C++. It can’t make assumptions of, or impose restrictions on, other languages and their compilers. For extern "C" to work the way you want in a Standard-sanctioned way, the Standard would effectively be describing how C and a C compiler must work. The languages are close, but they aren’t that close.
Now a particular C++ implementation may let you define a C++ function as extern "C" such that the function behaves as if written in that implementation’s C. And very likely, a given implementation will let you freely intermingle C and C++ code it compiles. But the behavior is not guaranteed by the Standard and goes against my read of the intent behind extern "C".
As I outlined in my original answer, cross-language calls require the caller and callee to jibe in their assumptions of data structure and call mechanics. I refer you back to the Standard passage I cited in that June column (Subclause 7.5/9):
Linkage from C++ to objects defined in other languages and to objects defined in C++ from other languages is implementation-defined and language-dependent. Only where the object layout strategies of two language implementations are similar enough can such linkage be achieved.
If you are calling between C and C++, and all source is compiled by the same compiler, then you should be okay. But if you call across code built by different compilers, then the risk of malfunction increases. About the best you can hope for is that some real or de-facto industry standard for code/data layout exists, and that all of your compilers target this standard.
(I don’t know that the original reader’s old C++ and new C were built with the same compiler. I assume they weren’t; but even if they were, the Standard-based advice I’ve given him stands.)
In that same June column, I listed some reasons you might want to use C over C++. Diligent Reader Brooks adds a reason I neglected, one that dovetails nicely with the above discussion: by choosing a C implementation, library writers allow multiple C++ environments to call into their library via extern "C".
Notes
[1] <http://www.gotw.ca/cpp_seminar/>
[2] And also to scurry off with Scott’s bride Nancy, a woman of impeccable and discerning taste who wants to dump Scott and marry me instead. No, really.
[3] For Ye Language Lawyers: yes, this rule is overly strict. It’s also easy to remember and follow.
[4] As I mentioned in that June column, the C Standard — which really has jurisdiction here — is utterly silent on the topic of cross-language function calls.
Although Bobby Schmidt makes most of his living as a writer and content strategist for the Microsoft Developer Network (MSDN), he runs only Apple Macintoshes at home. In previous career incarnations, Bobby has been a pool hall operator, radio DJ, private investigator, and astronomer. You may summon him on the Internet via [email protected].
