Name-Clashes caused by #includes
Jack
I'm having a few problems with regarding to name-clashes caused by
#include'ing a file that #include's others (and so on) that eventually leads
to a symbol-name-collision error.
Conceptually I know WHY it's happening, and I know (in hindsight) what I
could have done to start with, but I have a lot of code now that I don't
want to risk breaking by introducing major changes (adding namespaces,
renaming variables etc...).
I'm really hoping that someone can give me some hints as to how I can manage
this using local/minor changes. (or, if you really have to, tell me its
plain not possible!).
Anyway, here are the details:
In a large game project, I have an engine class - 'CGraphics', its
definition is in CGraphics.h and implementation in CGraphics.cpp. Many
(perhaps 50+) other translation units use the basic functionality provided
by the CGraphics class... All of these units #include "CGraphics.h".
Now, in order to add movie playback to the graphics core, I had to include a
header - "streams.h" which has the necessary
prototypes/interfaces/declarations.
I also need to declare private instances of these variables in 'CGraphics'
(so that PlayMove(), LoadMovie() etc... can access the same data). I define
these variables in the class declaration - CGraphics.h.
So far so good, hopefully no surprises there - I've been writing code like
that for years...
Now, the fun starts...
The aforementioned "streams.h" is a complicated header - has lots of other
#include's... and somewhere in there is a definition of "CBaseWindow" class.
I don't know what it is, or what it does - but it's in there. My project
also has a 'CBaseWindow' class.
I have upwards of 50 sub-classes of CBaseWindow, along with the basic
functionality itself... (i.e. its important). Almost all of these use some
functionality from 'CGraphics'... and by including both the graphics core
and the base window, I get the name-clash.
I really don't know how to solve this one. I've read through my copies of
Scott Meyers Books, and Bjarne Stroustrup's - and I can't find an obvious
answer... Is there anyway I can get around this? Or will I just have to
abandon this particular library?
Any help is very greatly appreciated,
Cheers,
Jack Hoxley
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
Ulrich Eckhardt
> In a large game project, I have an engine class - 'CGraphics',
Bad idea. Traditionally, classes prefixed with 'C' are mainly used by MFC
and related classes (yes, I know that some people didn't use their brain
and adopted that habit). In C++, you better put all your stuff into a C++
namespace. In particular, you messed up by using a totally common name like
'Graphics' with a common(yes, sadly) prefix like 'C'.
[ OP's CBaseWindow clashes with an external lib's CBaseWindow ]
> I have upwards of 50 sub-classes of CBaseWindow, along with the basic
> functionality itself... (i.e. its important). Almost all of these use some
> functionality from 'CGraphics'... and by including both the graphics core
> and the base window, I get the name-clash.
>
> I really don't know how to solve this one. I've read through my copies of
> Scott Meyers Books, and Bjarne Stroustrup's - and I can't find an obvious
> answer... Is there anyway I can get around this? Or will I just have to
> abandon this particular library?
I believe namespaces _are_ explained in both books and also their use. Maybe
their importance needs to be stressed...
However: the only thing you need to do is wrap all declarations in your
headers in a namespace and add a 'using namespace foo;' to your
sourcefiles. That in itself should not change anything yet(except if you
remove the IMO stupid 'C' prefix), so for the code that uses the clashing
symbols you will not be able to use the 'using ..' but have to explicitly
use either ::CBaseWindow or ::YourProject::CBaseWindow.
Oh, and file a bug-report on the other lib that shamelessly pollutes the
global namespace with such non-specific names as 'CBaseWindow' while you're
at it.
Uli
--
FAQ: http://parashift.com/c++-faq-lite/
/* bittersweet C++ */
default: break;
Jack
Thanks for your reply... answers inline below:
"Ulrich Eckhardt" <doom...@knuut.de> wrote in message
news:2jam9fF...@uni-berlin.de...
> Jack wrote:
> > In a large game project, I have an engine class - 'CGraphics',
>
> Bad idea. Traditionally, classes prefixed with 'C' are mainly used by MFC
> and related classes (yes, I know that some people didn't use their brain
> and adopted that habit). In C++, you better put all your stuff into a C++
> namespace. In particular, you messed up by using a totally common name
like
> 'Graphics' with a common(yes, sadly) prefix like 'C'.
I picked up the prefix-"C" notation from a couple of the first books I read
when learning C++ (about 3yrs ago)... kinda stuck. Given this problem, I'll
probably avoid it in the future :-)
>
> [ OP's CBaseWindow clashes with an external lib's CBaseWindow ]
>
> > I have upwards of 50 sub-classes of CBaseWindow, along with the basic
> > functionality itself... (i.e. its important). Almost all of these use
some
> > functionality from 'CGraphics'... and by including both the graphics
core
> > and the base window, I get the name-clash.
> >
> > I really don't know how to solve this one. I've read through my copies
of
> > Scott Meyers Books, and Bjarne Stroustrup's - and I can't find an
obvious
> > answer... Is there anyway I can get around this? Or will I just have to
> > abandon this particular library?
>
> I believe namespaces _are_ explained in both books and also their use.
Maybe
> their importance needs to be stressed...
Yeah, they're both explained... but for whatever reason, it didn't click
that it was a REQUIREMENT, rather I got the emphasis as it was just USEFUL..
Look like the best solution I can get now is to bite-the-bullet and
partition my game into namespaces.
>
> However: the only thing you need to do is wrap all declarations in your
> headers in a namespace and add a 'using namespace foo;' to your
> sourcefiles. That in itself should not change anything yet(except if you
> remove the IMO stupid 'C' prefix), so for the code that uses the clashing
> symbols you will not be able to use the 'using ..' but have to explicitly
> use either ::CBaseWindow or ::YourProject::CBaseWindow.
>
> Oh, and file a bug-report on the other lib that shamelessly pollutes the
> global namespace with such non-specific names as 'CBaseWindow' while
you're
> at it.
Already done that ;-)
"streams.h" is part of the Microsoft DirectShow library - could well be that
"CBaseWindow" is some obscure reference back to MFC.
>
> Uli
>
> --
> FAQ: http://parashift.com/c++-faq-lite/
> /* bittersweet C++ */
> default: break;
Cheers,
Jack
Robert Kindred
"Jack" <jack....@ntlworld.com> wrote in message
news:MvMzc.645$h44...@newsfe1-gui.server.ntli.net...
> Hello,
>
> I'm having a few problems with regarding to name-clashes caused by
> #include'ing a file that #include's others (and so on) that eventually
leads
> to a symbol-name-collision error.
>
I probably shouldn't admit that we are having these same problems, but it is
the truth. Some of the things that we do are:
Move private #include's from the header file to the source file.
If a header file only needs to know a class exists, but not internal
workings, then just make a forward reference in the client header file, such
as:
class CGraphics;
Then pointers to this class can be contained in the classes of the current
header file.
Finally, when you are backed against the wall, the bridge pattern, explained
in the Design Patterns book by the Gang of Four shows you how to make the
internal workings of your class opaque, which eliminates circular include
problems, and also hides everything about the class. I especially like to
use the bridge pattern on anything that includes the horrible windows.h.
Then the clients of your class do not need to include windows.h.
Hope this helps,
Robert Kindred
<snip>
Dave Harris
> > In a large game project, I have an engine class - 'CGraphics',
>
> Bad idea. Traditionally, classes prefixed with 'C' are mainly used by
> MFC and related classes (yes, I know that some people didn't use
> their brain and adopted that habit). In C++, you better put all
> your stuff into a C++ namespace.
The "C" stands for "class", not "MFC". A naming convention to distinguish
between classes and other things - especially non-types - can be useful.
Namespaces aren't a good tool for making that distinction.
-- Dave Harris, Nottingham, UK
ka...@gabi-soft.fr
news:<memo.20040616234525.3616A@brangdon.m>...
> doom...@knuut.de (Ulrich Eckhardt) wrote (abridged):
> > > In a large game project, I have an engine class - 'CGraphics',
> > Bad idea. Traditionally, classes prefixed with 'C' are mainly used
> > by MFC and related classes (yes, I know that some people didn't use
> > their brain and adopted that habit). In C++, you better put all
> > your stuff into a C++ namespace.
> The "C" stands for "class", not "MFC". A naming convention to
> distinguish between classes and other things - especially non-types -
> can be useful. Namespaces aren't a good tool for making that
> distinction.
A naming convention to distinguish between types and other symbols is,
IMHO, almost essention. Both (types and other things) are so
omnipresent, however, that something as heavy as a prefix seems
overdoing it; if I wanted something that heavy, I would have gone with
the already established _t suffix..
In my own code, I've generally followed the convention that type names
start with a capital, other symbols with a small letter. But I also use
camel case, and I'm sure that there are many other acceptable
conventions.
What I don't quite see as useful, in fact, what I would consider
counter-productive, is using something like CReturnCode if it is a
class, and just ReturnCode if it is a typedef to int (since as the code
evolves, the typedef to int might become a class, or vice versa).
--
James Kanze GABI Software
Conseils en informatique orient�e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S�mard, 78210 St.-Cyr-l'�cole, France, +33 (0)1 30 23 00 34
David Abrahams
> doom...@knuut.de (Ulrich Eckhardt) wrote (abridged):
> > > In a large game project, I have an engine class - 'CGraphics',
> >
> > Bad idea. Traditionally, classes prefixed with 'C' are mainly used by
> > MFC and related classes (yes, I know that some people didn't use
> > their brain and adopted that habit). In C++, you better put all
> > your stuff into a C++ namespace.
>
> The "C" stands for "class", not "MFC". A naming convention to distinguish
> between classes and other things - especially non-types - can be
> useful.
For what?
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
Glen Low
> Maybe
> > their importance needs to be stressed...
>
> Yeah, they're both explained... but for whatever reason, it didn't click
> that it was a REQUIREMENT, rather I got the emphasis as it was just USEFUL..
>
> Look like the best solution I can get now is to bite-the-bullet and
> partition my game into namespaces.
The Guru hisself has some good advice about this:
http://www.gotw.ca/gotw/053.htm
Cheers,
Glen Low, Pixelglow Software
www.pixelglow.com
Gabriel Dos Reis
[...]
| What I don't quite see as useful, in fact, what I would consider
| counter-productive, is using something like CReturnCode if it is a
| class, and just ReturnCode if it is a typedef to int (since as the code
| evolves, the typedef to int might become a class, or vice versa).
Then you change ReturnCode to TReturnCode -- "T" for typedef.
--
Gabriel Dos Reis
g...@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
Seungbeom Kim
>
> In my own code, I've generally followed the convention that type names
> start with a capital, other symbols with a small letter. But I also use
> camel case, and I'm sure that there are many other acceptable
> conventions.
It seems that many people follow the convention of "Type names start
with a capital," however, the type names from the Holy Standard start
with lowercase letters. It's one of the nasty problems when you mix
get_time (from std) an GetCurrentTime (from Win32). :(
--
Seungbeom Kim
Gabriel Dos Reis
| ka...@gabi-soft.fr wrote:
| >
| > In my own code, I've generally followed the convention that type names
| > start with a capital, other symbols with a small letter. But I also use
| > camel case, and I'm sure that there are many other acceptable
| > conventions.
|
| It seems that many people follow the convention of "Type names start
| with a capital," however, the type names from the Holy Standard start
| with lowercase letters. It's one of the nasty problems when you mix
| get_time (from std) an GetCurrentTime (from Win32). :(
Well, personnally I don't really see the need to distinguish between
types and non types -- that distinction is good for the programmed
parser but for most cases, I don't feel a necessity for it. Probably
because I tend to write simple instructions and use many types as
surrogates for for involved computations.
--
Gabriel Dos Reis
g...@cs.tamu.edu
Texas A&M University -- Computer Science Department
301, Bright Building -- College Station, TX 77843-3112
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Francis Glassborow
ka...@gabi-soft.fr writes
>A naming convention to distinguish between types and other symbols is,
>IMHO, almost essention. Both (types and other things) are so
>omnipresent, however, that something as heavy as a prefix seems
>overdoing it; if I wanted something that heavy, I would have gone with
>the already established _t suffix..
But until C++ broke the idiom by making wchar_t a built-in type, the _t
suffix was used to identify a typename as one provided by a typedef (i.e. it
was just a name for an already existing type, rather like a reference
variable being a name for an already existing object)
I do not think that _t carries the message you want it to.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project
ideas and contributions: http://www.spellen.org/youcandoit/projects
David Abrahams
> A naming convention to distinguish between types and other symbols is,
> IMHO, almost essention
I think you mean "essential", but why? I never have trouble telling types
from other entities when reading code written in all_lower_case.
Programmers love to classify, organize, and categorize things, but I'm not
sure we know how to discern which classifications are actually helpful.
It's time to challenge the existing orthodoxy to justify itself. ;-)
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Dave Harris
> > A naming convention to distinguish between classes and other things
>
> For what?
For reading code. For looking at a statement and figuring out what kind of
thing is going on; whether it is a declaration or a function call, for
instance. Or whether it contains some user-defined cleverness which might
need to be looked up in the documentation, rather then standard built-in
behaviour.
I don't claim a C-prefix is best or that everyone should use it. My point
was more that if you are writing code to go with MFC, using a C-prefix is
not breaking their rules. It is not a prefix reserved for MFC code only.
It is intended to mark user-defined classes in any code which follows the
MFC conventions.
-- Dave Harris, Nottingham, UK
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Francis Glassborow
<bran...@cix.co.uk> writes
>da...@boost-consulting.com (David Abrahams) wrote (abridged):
>> > A naming convention to distinguish between classes and other things
>> > especially non-types - can be useful.
>>
>> For what?
>
>For reading code. For looking at a statement and figuring out what kind of
>thing is going on; whether it is a declaration or a function call, for
>instance. Or whether it contains some user-defined cleverness which might
>need to be looked up in the documentation, rather then standard built-in
>behaviour.
Sorry, but I must be plain stupid because AFAICS the syntax always
identifies whether something is a type or not. Would you please provide
a statement where an ambiguity exists. Yes there are nasty things like
finding you have written a function declaration when you intended
writing an object declaration/definition but cannot see how, without
deliberate deception, a declaration can appear to be something else, and
once you know something is a declaration then type-names stand out.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Dave Harris
> Sorry, but I must be plain stupid because AFAICS the syntax always
> identifies whether something is a type or not.
The syntax always does, and that's enough for a machine. Humans could
sometimes use a few additional clues. Compare with "Obfuscated C", which
the compiler can understand but we humans find difficult. Production code
should not be obfuscated. It should be readily understandable by humans as
well as by machines. Getting the syntax right is not always sufficient.
It's a judgement call. The C-prefix is redundant. Redundancy can make
comprehension easier: it means there are two routes to understanding, so
the reader can use whichever route is best for them and then use the other
route as a check. But the redundancy also has drawbacks, such as making it
harder to make changes. Arguably the way to fix a statement in which the
types are unclear is to refactor it into several simpler statements, not
to rename the types. And of course the MFC convention does not sit well
with the STD conventions.
So there are arguments on both sides. And there is path-dependency, too.
If you are working with existing code that follows MFC conventions, you
might want to stick with those conventions even if you would do it
differently if you were starting from scratch.
-- Dave Harris, Nottingham, UK
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
John Nagle
> Sorry, but I must be plain stupid because AFAICS the syntax always
> identifies whether something is a type or not.
If only it were so. If it were, parsing C++ would be
far simpler. C++ has a context-dependent grammar.
Without seeing all the definitions, you cannot always tell if
a symbol is a type or not.
John Nagle
Animats
Francis Glassborow
Nagle <na...@animats.com> writes
>Francis Glassborow wrote:
>> Sorry, but I must be plain stupid because AFAICS the syntax always
>> identifies whether something is a type or not.
>
> If only it were so. If it were, parsing C++ would be
>far simpler. C++ has a context-dependent grammar.
>Without seeing all the definitions, you cannot always tell if
>a symbol is a type or not.
That is true, but the only cases I can come up with where the difficulty
can manifest are:
1) sizeof(x)
2) preprocessor macros
3) explicitly 'calling' a ctor
In general I find that adding symbols to help readers does exactly the
reverse; it makes code less readable rather than more so. One reason for
the Standard C++ Library naming style is exactly because after a great
deal of debate we concluded that the many existing styles actually added
nothing useful. That said, I do wish that we had been consistent in our
use of the underscore. Having getline() without and push_back() with
just adds to the memory burden.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
ka...@gabi-soft.fr
news:<+8EQRKRq...@robinton.demon.co.uk>...
> In article <memo.20040619160915.1676A@brangdon.m>, Dave Harris
> <bran...@cix.co.uk> writes
> >da...@boost-consulting.com (David Abrahams) wrote (abridged):
> >> > A naming convention to distinguish between classes and other
> >> > things especially non-types - can be useful.
> >> For what?
> >For reading code. For looking at a statement and figuring out what
> >kind of thing is going on; whether it is a declaration or a function
> >call, for instance. Or whether it contains some user-defined
> >cleverness which might need to be looked up in the documentation,
> >rather then standard built-in behaviour.
> Sorry, but I must be plain stupid because AFAICS the syntax always
> identifies whether something is a type or not.
You've got it backwards. Whether something is a typename or not often
determines syntax.
In practice, of course, the real advantage comes when scanning code
rapidly. If the first token in a statement is a keyword, that
determines the type of statement. Otherwise, if the first word is a
typename, the statement is a declaration, if not, an expression
statement executed for side effects. (I know that there are exceptions
to this, but I've never seen them in real code.)
In my own code, in declarations I align what is being declared 20 spaces
to the right of the current margin, e.g.:
int i ;
MyClass c ;
std::map< std::string, MyClass >
m ;
This tends to make the declaration easily visible, as well as making it
easy to find what is being declared, so the need for a convention is
probably less. Still, it doesn't hurt, and using case is simple and
unintrusive. (I find a C prefix too intrusive, but if it were a
systematic convention for all user defined type names, it would be
defensable. When I see it next to things like LPTR or DWORD, however, I
have my doubts.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
ka...@gabi-soft.fr
news:<uzn6z1...@boost-consulting.com>...
> ka...@gabi-soft.fr writes:
> > A naming convention to distinguish between types and other symbols is,
> > IMHO, almost essention
> I think you mean "essential", but why?
That's what I mean. I don't know what my fingers were thinking.
As for why: you need to know whether a name is a type or not in order to
correctly parse C++.
> I never have trouble telling types from other entities when reading
> code written in all_lower_case.
A lot depends on other conventions as well. I can always manage, and
usually, I need to know more than just whether the name is a type or
not. "Essential" is probably too strong a word, but if you are going to
categorize, then the first division should be between types and
non-types. (Actually, the first division is between macros and the
rest. But I think there is almost a consensus about that.)
If you're using camel case, the distinction between upper and lower case
of the first character is simple, and the added information is useful.
For all lower case, I can't think of a reasonable convention. It
certainly shouldn't be too intrusive -- as you say, it's not a
fundamental necessity.
> Programmers love to classify, organize, and categorize things, but I'm
> not sure we know how to discern which classifications are actually
> helpful. It's time to challenge the existing orthodoxy to justify
> itself. ;-)
The question here isn't whether you have to classify typename vs. other
name; you do, because it affects how you parse C++. You also obviously
need other classifications as well: applying the () operator to an int
isn't a particularly good idea either. The question is whether you need
to manifest this classification (or any other particular convention)
through some special (extra-linguistic) convention. With a perfect
naming convention, it shouldn't be necessary; not just whether something
is a type, but a lot of other things about it, should be immediately
obvious from the name. In practice, naming conventions are rarely
perfect, however, and IF you can transmit additional information WITHOUT
masking in some way the basic naming (i.e. without using Hungarian
notation), then it is worth considering.
FWIW: I don't see any equivalently simple solution for all lower case,
so if called on to use all lower case, I would probably forego this
distinction. Also, my personal preference is for using a _ between
words, rather than playing with case. But it is a very weak preference,
and I've worked mainly for customers and in domains where camel case has
predominated. So that's what I use.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
ka...@gabi-soft.fr
> In article <d6652001.04061...@posting.google.com>,
> ka...@gabi-soft.fr writes
> >A naming convention to distinguish between types and other symbols
> >is, IMHO, almost essention. Both (types and other things) are so
> >omnipresent, however, that something as heavy as a prefix seems
> >overdoing it; if I wanted something that heavy, I would have gone
> >with the already established _t suffix..
> But until C++ broke the idiom by making wchar_t a built-in type, the
> _t suffix was used to identify a typename as one provided by a typedef
> (i.e. it was just a name for an already existing type, rather like a
> reference variable being a name for an already existing object)
You mean like div_t and company?
The _t suffix comes from the C community, where the only way to define a
type is with a typedef. Historically, it has been used in this
community as a signal that the name in question is a user defined type
name.
> I do not think that _t carries the message you want it to.
Well, I won't insist on it. I can't say that I particularly like it
myself. It's just the only rule that comes to mind concerning
identifying types when using all lower case.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bill Wade
> fra...@robinton.demon.co.uk (Francis Glassborow) wrote (abridged):
> > Sorry, but I must be plain stupid because AFAICS the syntax always
> > identifies whether something is a type or not.
>
> The syntax always does
Only within the context of the entire TU. Even ignoring the
possibility of macros
a<b>c;
d(e);
'a' could be a template name or an object name. If 'a' is a template,
then 'b' could be a type or an ICE.
'd' might name a function, class, or object.
Of course a real problem is that knowing the type of the identifiers
isn't enough to know what the program is doing, or is intended to do.
But it can help detect logic errors.
Trace("MyBlock");
may be reasonable code if Trace is a function (or functor), however if
it is a class, it is likely that the correct code is
Trace tracer("MyBlock");
which causes the ~Tracer() to execute at a different point.
Allan W
> > I never have trouble telling types from other entities when reading
> > code written in all_lower_case.
ka...@gabi-soft.fr wrote
> FWIW: I don't see any equivalently simple solution for all lower case,
> so if called on to use all lower case, I would probably forego this
> distinction. Also, my personal preference is for using a _ between
> words, rather than playing with case. But it is a very weak preference,
> and I've worked mainly for customers and in domains where camel case has
> predominated. So that's what I use.
A noun (i.e. employee) is a type name.
A noun phrase (i.e. current_employee or nextemployee) is a non-type.
Personally I used capital letters for my own class names.
I like the fact that this differs from the standard library.
Fraction<long> is mine; complex<double> is standard.
Less important when you're using namespaces fully.
Allan W
> I don't claim a C-prefix is best or that everyone should use it. My point
> was more that if you are writing code to go with MFC, using a C-prefix is
> not breaking their rules. It is not a prefix reserved for MFC code only.
> It is intended to mark user-defined classes in any code which follows the
> MFC conventions.
I remember that when the MFC was new, Microsoft C++ recommended that
coders should start all class names with a capital C: CEmployee,
CCustomer, and so on.
I hope they don't do that anymore! AFAIK, MFC still doesn't use it's own
namespace, so you somehow have to know not to name your class CMenu
(restaurant), CWindow or CPane (building contractor), or CButton (clothing).
Francis Glassborow
<all...@my-dejanews.com> writes
>A noun (i.e. employee) is a type name.
>A noun phrase (i.e. current_employee or nextemployee) is a non-type.
>
>Personally I used capital letters for my own class names.
>I like the fact that this differs from the standard library.
>Fraction<long> is mine; complex<double> is standard.
>Less important when you're using namespaces fully.
Do you also apply that to function names? It would be an interesting
coding guideline to require that all names with external linkage that
are not part of the Standard C++ Library should contain at least one
uppercase letter.
However, somehow I do not think it will catch on.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Allan W
> >A noun (i.e. employee) is a type name.
> >A noun phrase (i.e. current_employee or nextemployee) is a non-type.
> >
> >Personally I used capital letters for my own class names.
> >I like the fact that this differs from the standard library.
> >Fraction<long> is mine; complex<double> is standard.
> >Less important when you're using namespaces fully.
Francis Glassborow <fra...@robinton.demon.co.uk> wrote
> Do you also apply that to function names?
No, functions use verbs or verb phrases (i.e. save or printCheck).
> It would be an interesting
> coding guideline to require that all names with external linkage that
> are not part of the Standard C++ Library should contain at least one
> uppercase letter.
Interesting? Yes.
> However, somehow I do not think it will catch on.
I doubt it too.
Francis Glassborow
>> Do you also apply that to function names?
>
>No, functions use verbs or verb phrases (i.e. save or printCheck).
But that does not prevent name clash issues. In all the many years that
I have been using C++ the worst that has ever happened to me through a
clash of a typename is some form of compile time diagnostic. Maybe I
have been lucky. OTOH clashes of function names have caused me serious
problems particularly where the clash has been with a function template
name. The compiler has more than once selected the template as a best
match and then complained that it could not instantiate it. That at
least was a noisy failure. It is the quiet overloading that can be
vicious.
If we need a naming convention to prevent problems of clashes with the
Standard Library, functions are where it would buy most.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Alan Griffiths
>
> But that does not prevent name clash issues. In all the many years that
> I have been using C++ the worst that has ever happened to me through a
> clash of a typename is some form of compile time diagnostic. Maybe I
> have been lucky. OTOH clashes of function names have caused me serious
> problems particularly where the clash has been with a function template
> name. The compiler has more than once selected the template as a best
> match and then complained that it could not instantiate it. That at
> least was a noisy failure. It is the quiet overloading that can be
> vicious.
Name clashes can be more subtle than that. A few years ago the team I
was working for supplied a library to several other teams who
incorporated it into their applications. All was well until a team
investigated using the library and rejected it on the grounds that the
library headers didn't even compile.
At that time the library and tests were working for us (and at least
one other team).
Once we got past the usual accusations of incompetence I finally got
to see the error messages reported by their compiler. It was
complaining about references to a name "RegisterClassA" - which didn't
appear in our code. This was weird! Only after a bit of spelunking
through their test code did I find the culprit: they were using a
third party library that contained "#define RegisterClass
RegisterClassA" in defiance of the widely adopted practice of using
uppercase for macros.
> If we need a naming convention to prevent problems of clashes with the
> Standard Library, functions are where it would buy most.
That is a big "if" - I don't remember a single name clash with the
standard library (despite my preference for that naming style). Other
library authors are a different story. (Types named "Object" were
once very fashonable - although evolution seems to have dealt with
them now.)
--
Alan Griffiths
http://www.octopull.demon.co.uk/
Allan W
> >> Do you also apply [capital first letter] to function names?
> Allan W <all...@my-dejanews.com> writes
> >No, functions use verbs or verb phrases (i.e. save or printCheck).
Francis Glassborow <fra...@robinton.demon.co.uk> wrote
> But that does not prevent name clash issues. In all the many years that
> I have been using C++ the worst that has ever happened to me through a
> clash of a typename is some form of compile time diagnostic. Maybe I
> have been lucky.
I'd say so.
> OTOH clashes of function names have caused me serious
> problems particularly where the clash has been with a function template
> name. The compiler has more than once selected the template as a best
> match and then complained that it could not instantiate it. That at
> least was a noisy failure. It is the quiet overloading that can be
> vicious.
>
> If we need a naming convention to prevent problems of clashes with the
> Standard Library, functions are where it would buy most.
Would you suggest a convention, then?
Randy Maddox
[snip]
>
> If we need a naming convention to prevent problems of clashes with the
> Standard Library, functions are where it would buy most.
But isn't this what namespaces are for? I've never had a function
name clash with any Standard Library function because I don't name my
functions std::xxx.
This sounds more like a reason to not use using directives.
Randy.
ka...@gabi-soft.fr
news:<7f2735a5.04062...@posting.google.com>...
> > David Abrahams <da...@boost-consulting.com> wrote
> > > I never have trouble telling types from other entities when reading
> > > code written in all_lower_case.
> ka...@gabi-soft.fr wrote
> > FWIW: I don't see any equivalently simple solution for all lower
> > case, so if called on to use all lower case, I would probably
> > forego this distinction. Also, my personal preference is for using
> > a _ between words, rather than playing with case. But it is a very
> > weak preference, and I've worked mainly for customers and in
> > domains where camel case has predominated. So that's what I use.
> A noun (i.e. employee) is a type name.
> A noun phrase (i.e. current_employee or nextemployee) is a non-type.
I agree with you in general, but is board_status a variable of type
status, or a type for storing the status of boards? It's not always
clear whether something is a compound noun (and thus a type name) or a
noun phrase (and so a variable).
Functions are, of course, verbs or verb phrases.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Francis Glassborow
Maddox <rma...@isicns.com> writes
>Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message news:<LWf9rEPw...@robinton.demon.co.uk>...
>
>[snip]
>
> >
> > If we need a naming convention to prevent problems of clashes with the
> > Standard Library, functions are where it would buy most.
>
>But isn't this what namespaces are for? I've never had a function
>name clash with any Standard Library function because I don't name my
>functions std::xxx.
>
>This sounds more like a reason to not use using directives.
In the case of the Standard Library you could argue that (and I probably
would for commercial quality code) but not all third party libraries are
in namespaces.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Francis Glassborow
> > But that does not prevent name clash issues. In all the many years that
> > I have been using C++ the worst that has ever happened to me through a
> > clash of a typename is some form of compile time diagnostic. Maybe I
> > have been lucky.
>
>I'd say so.
Would you give an example where type names can clash silently?
>
> > OTOH clashes of function names have caused me serious
> > problems particularly where the clash has been with a function template
> > name. The compiler has more than once selected the template as a best
> > match and then complained that it could not instantiate it. That at
> > least was a noisy failure. It is the quiet overloading that can be
> > vicious.
> >
> > If we need a naming convention to prevent problems of clashes with the
> > Standard Library, functions are where it would buy most.
>
>Would you suggest a convention, then?
As I do not believe that we need one, no.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Motti Lanzkron
>In article <7f2735a5.04062...@posting.google.com>, Allan W
><all...@my-dejanews.com> writes
>>Francis Glassborow <fra...@robinton.demon.co.uk> wrote
>> > But that does not prevent name clash issues. In all the many years that
>> > I have been using C++ the worst that has ever happened to me through a
>> > clash of a typename is some form of compile time diagnostic. Maybe I
>> > have been lucky.
>>
>>I'd say so.
>
>Would you give an example where type names can clash silently?
Does violating ODR count?
I once had two functor with the same name in two different translation
units. For some reason one of my algorithms gave unexpected results.
I've been much stricter about using anonymous namespaces since then.
Francis Glassborow
<mlan...@yahoo.co.uk> writes
> >Would you give an example where type names can clash silently?
>
>Does violating ODR count?
>
>I once had two functor with the same name in two different translation
>units. For some reason one of my algorithms gave unexpected results.
>
>I've been much stricter about using anonymous namespaces since then.
The current discussion was about using naming conventions to avoid
clashes, mainly those between the Standard Library and user written
code. While violations of the ODR would be an example of a potentially
silent clash between type names, naming conventions per se would not
help. OTOH I regularly highlight the value of unnamed namespaces exactly
because they enable purely file context names for such things as types.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Randy Maddox
> In article <8c8b368d.04062...@posting.google.com>, Randy
> Maddox <rma...@isicns.com> writes
> >Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message news:<LWf9rEPw...@robinton.demon.co.uk>...
> >
> >[snip]
> >
> > >
> > > If we need a naming convention to prevent problems of clashes with the
> > > Standard Library, functions are where it would buy most.
> >
> >But isn't this what namespaces are for? I've never had a function
> >name clash with any Standard Library function because I don't name my
> >functions std::xxx.
> >
> >This sounds more like a reason to not use using directives.
>
> In the case of the Standard Library you could argue that (and I probably
> would for commercial quality code) but not all third party libraries are
> in namespaces.
In which case I would argue that a 3rd party library not in its own
namespace is not of commercial quality.
Randy.
ka...@gabi-soft.fr
news:<8c8b368d.0407...@posting.google.com>...
> Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> news:<nNQGdPUO...@robinton.demon.co.uk>...
> > In article <8c8b368d.04062...@posting.google.com>, Randy
> > Maddox <rma...@isicns.com> writes
> > >Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> > > news:<LWf9rEPw...@robinton.demon.co.uk>...
> > >[snip]
> > > > If we need a naming convention to prevent problems of clashes
> > > > with the Standard Library, functions are where it would buy
> > > > most.
> > >But isn't this what namespaces are for? I've never had a function
> > >name clash with any Standard Library function because I don't name
> > >my functions std::xxx.
> > >This sounds more like a reason to not use using directives.
> > In the case of the Standard Library you could argue that (and I
> > probably would for commercial quality code) but not all third party
> > libraries are in namespaces.
> In which case I would argue that a 3rd party library not in its own
> namespace is not of commercial quality.
It depends on what the 3rd party library is targetting. Most of the 3rd
party libraries I use have all names declares `extern "C"'.
And I find it a bit pretentious (and exceedingly unrealistic) to pretend
that the libraries for Oracle or SyBase, for example, aren't of
commercial quality.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
Randy Maddox
> rma...@isicns.com (Randy Maddox) wrote in message
> news:<8c8b368d.0407...@posting.google.com>...
> > Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> > news:<nNQGdPUO...@robinton.demon.co.uk>...
> > > In article <8c8b368d.04062...@posting.google.com>, Randy
> > > Maddox <rma...@isicns.com> writes
> > > >Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
> > > > news:<LWf9rEPw...@robinton.demon.co.uk>...
>
> > > >[snip]
>
> > > > > If we need a naming convention to prevent problems of clashes
> > > > > with the Standard Library, functions are where it would buy
> > > > > most.
>
> > > >But isn't this what namespaces are for? I've never had a function
> > > >name clash with any Standard Library function because I don't name
> > > >my functions std::xxx.
>
> > > >This sounds more like a reason to not use using directives.
>
> > > In the case of the Standard Library you could argue that (and I
> > > probably would for commercial quality code) but not all third party
> > > libraries are in namespaces.
>
> > In which case I would argue that a 3rd party library not in its own
> > namespace is not of commercial quality.
>
> It depends on what the 3rd party library is targetting. Most of the 3rd
> party libraries I use have all names declares `extern "C"'.
Yes, but 'extern "C"' and namespaces are not mutually exclusive.
>
> And I find it a bit pretentious (and exceedingly unrealistic) to pretend
> that the libraries for Oracle or SyBase, for example, aren't of
> commercial quality.
On the one hand I do agree with you. Those are well-known and widely
used libraries and thus almost by definition of commercial quality.
On the other hand, would those libraries not be even easier to use,
and thus in some sense of higher quality, if they used namespaces?
Of course, C libraries are perfectly usable from C++, but even there a
bit of conditional compilation could include/exclude namespace
declarations as appropriate.
It just seems to me that namespaces are a very poweful and extremely
useful way to partition names within a program. The larger the
program, and the more libraries involved, the more benefit is gained
from using namespaces appropriately.
Randy.