Naming convention for variables using underscore inside class declaration??
Al Dev
Is using under-score character (_) allowed by ANSI C++ standard??
For example I want to use under-score to mark protected and private
variables as in:
class SomeFunName
{
public:
int ZimboniMacho;
float *pArrayNumbers;
int HandleError();
protected:
float _BonyBox;
int *_pBonyHands;
char *_pHandsFull();
private:
float __JustDoIt;
int *__pTotalValue;
char *__pSubmitBars();
int _main;
};
I read in some coding standard doc which says -
"The use of two underscores (`__') in identifiers is reserved for the
compiler's internal use according to the ANSI-C
standard. Underscores (`_') are often used in names of library functions
(such as " _main" and
"_exit"). "
It says ANSI -C and does it mean can use on C++??
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Stan Brown
Al Dev <ala...@yahoo.com> wrote in comp.lang.c++.moderated:
>Is using under-score character (_) allowed by ANSI C++ standard??
>For example I want to use under-score to mark protected and private
>variables as in:
>
>class SomeFunName
>{
> public:
> int ZimboniMacho;
> protected:
> float _BonyBox;
> private:
> float __JustDoIt;
>};
Single underscore plus lower case is technically legal, but a bad
idea because some implementations in fact use names of that form for
their own purposes (though they shouldn't).
Single underscore plus upper case, and double underscore, are both
illegal in user-defined identifiers.
You may find this page of mine helpful:
http://oakroadsystems.com/tech/cppredef.htm
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm
Derekasaurus Rex
>
> Hello:
>
> Is using under-score character (_) allowed by ANSI C++ standard??
No.
17.4.3.1.2 Global names
Certain sets of names and function signatures are
always reserved to the implementation:
— Each name that contains a double underscore (_ _) or
begins with an underscore followed by an upper-case
letter (2.11) is reserved to the implementation for
any use.
— Each name that begins with an underscore is reserved
to the implementation for use as a name in the global
namespace.
Peter N Roth
Herb Sutter recommends a trailing underscore_ for members
and i think it's microsoft that recommends a preceding m_ to
indicate members, a la int m_x;
--
Grace + Peace
Peter N Roth
Engineering Objects International
http://EngineeringObjects.com
"Al Dev" <alavoor...@yahoo.com> wrote in message
news:3A3CEF3A...@yahoo.com...
> Hello:
>
> Is using under-score character (_) allowed by ANSI C++ standard??
Googlemon
Derekasaurus Rex <Dereka...@Excite.Com> wrote:
>
> Certain sets of names and function signatures are
> always reserved to the implementation:
>
> — Each name that contains a double underscore (_ _) or
> begins with an underscore followed by an upper-case
> letter (2.11) is reserved to the implementation for
> any use.
Is that *any* name containing a double score *anywhere* in the name?
> — Each name that begins with an underscore is reserved
> to the implementation for use as a name in the global
> namespace.
Is that *any* name, regardless of the case of the first letter?
- Peter.
Sent via Deja.com
http://www.deja.com/
James Kanze
> Al Dev <ala...@yahoo.com> wrote in comp.lang.c++.moderated:
> >Is using under-score character (_) allowed by ANSI C++ standard??
> >For example I want to use under-score to mark protected and private
> >variables as in:
> >class SomeFunName
> >{
> > public:
> > int ZimboniMacho;
> > protected:
> > float _BonyBox;
> > private:
> > float __JustDoIt;
> >};
> Single underscore plus lower case is technically legal, but a bad
> idea because some implementations in fact use names of that form for
> their own purposes (though they shouldn't).
> Single underscore plus upper case, and double underscore, are both
> illegal in user-defined identifiers.
Single underscore is both legal and fully usable everywhere but in the
initial position. The restrictions you give apply to an initial
underscore only. Double underscore is illegal anywhere.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Derekasaurus Rex
>
> In article <3A3E6898...@Excite.Com>,
> Derekasaurus Rex <Dereka...@Excite.Com> wrote:
> >
> > Certain sets of names and function signatures are
> > always reserved to the implementation:
> >
> > — Each name that contains a double underscore (_ _) or
> > begins with an underscore followed by an upper-case
> > letter (2.11) is reserved to the implementation for
> > any use.
>
> Is that *any* name containing a double score *anywhere* in the name?
I think this has already been answered, but yes, double underscores are
not permitted anywhere in the name.
> > — Each name that begins with an underscore is reserved
> > to the implementation for use as a name in the global
> > namespace.
>
> Is that *any* name, regardless of the case of the first letter?
That is correcet, a single underscore in the leading position is not
allowed regardless of case.
Jim Cobban
"Derekasaurus Rex" <Dereka...@Excite.Com> wrote in message
news:3A3E6898...@Excite.Com...
> Al Dev wrote:
> >
> > Hello:
> >
> > Is using under-score character (_) allowed by ANSI C++ standard??
>
> No.
>
> 17.4.3.1.2 Global names
>
> Certain sets of names and function signatures are
> always reserved to the implementation:
>
> begins with an underscore followed by an upper-case
> letter (2.11) is reserved to the implementation for
> any use.
>
> to the implementation for use as a name in the global
> namespace.
If you read the two restrictions strictly they say that names beginning with
an underscore and a lower case letter are permitted anywhere EXCEPT in the
global namespace. Therefore they are technically permitted as member names,
or as names of objects in a namespace. However I do strongly agree that it
is safer to just avoid the use of an initial underscore rather than trust
the letter of the law.
Francis Glassborow
<refusi...@mycompany.com> writes
>If you're looking for a convention...
>
>Herb Sutter recommends a trailing underscore_ for members
>
>and i think it's microsoft that recommends a preceding m_ to
>indicate members, a la int m_x;
prefixes are invasive and break the 'need to know' principle. If
correctly named, the 'unadorned' name is what every programmers needs to
see first. Suffixes should help where you really feel the need to adorn
a name with type or scope information. Furthermore, consider making such
adornment lower case because there really is no need to shout about it
(just one more thing I hate about MS naming conventions)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
John
Peter N Roth wrote in message <91m4tk$91i$1...@autumn.news.rcn.net>...
>If you're looking for a convention...
>
>Herb Sutter recommends a trailing underscore_ for members
>
>and i think it's microsoft that recommends a preceding m_ to
>indicate members, a la int m_x;
>
>"Al Dev" <alavoor...@yahoo.com> wrote in message
>news:3A3CEF3A...@yahoo.com...
Stan Brown
>That is correcet, a single underscore in the leading position is not
>allowed regardless of case.
A leading underscore followed by lower case _is_ allowed, except not
in the global namespace or std. Reference: 17.4.3.1.2/1
[lib.global.names]
However, as has been posted here numerous times, some
implementations get this wrong, so it's not prudent to use a leading
underscore even where it is technically legal.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> If you're looking for a convention...
You've come to the right place. I'm sure that with all of the readers
here, we can come up with any number of conventions:-).
> Herb Sutter recommends a trailing underscore_ for members
> and i think it's microsoft that recommends a preceding m_ to
> indicate members, a la int m_x;
My own (current) use is "my" for normal members, "our" for static
members, e.g.:
class X
{
private:
int myInt ;
static int ourInt ;
} ;
I've also seen "the", e.g. "theInt".
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> In article <3A3E6898...@Excite.Com>,
> Derekasaurus Rex <Dereka...@Excite.Com> wrote:
> > Certain sets of names and function signatures are
> > always reserved to the implementation:
> > — Each name that contains a double underscore (_ _) or
> > begins with an underscore followed by an upper-case
> > letter (2.11) is reserved to the implementation for
> > any use.
> Is that *any* name containing a double score *anywhere* in the name?
Yes.
> > — Each name that begins with an underscore is reserved
> > to the implementation for use as a name in the global
> > namespace.
> Is that *any* name, regardless of the case of the first letter?
Yes. But only at global scope.
That's for the standard. In practice, almost all compilers seem to
have a violation of the last rule, typically a macro which starts with
an underscore followed by a lower case letter.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Jonathan Thornburg
James Kanze <James...@dresdner-bank.com> wrote:
>Single underscore is both legal and fully usable everywhere but in the
>initial position. The restrictions you give apply to an initial
>underscore only. Double underscore is illegal anywhere.
I'd like to make sure I understand this. Are you indeed saying that
class foo
{
public:
void doit_now(int x);
void doit_now__alpha(int x);
void doit_now__beta(int x);
};
is illegal, due to the double-underscores in the member function names?
This is hardly a conclusive argument, but I note that my usual "gcc with
reasonable warnings enabled", g++ 2.95.2 with
g++ -Wall -W -Wno-unused -Wshadow -Winline -Wpointer-arith \
-Wbad-function-cast -Wcast-align -Wstrict-prototypes \
-Wmissing-prototypes -Wmissing-declarations -Woverloaded-virtual \
-Wsynth -ffor-scope
has no complaints about this class.
--
-- Jonathan Thornburg <jth...@thp.univie.ac.at>
http://www.thp.univie.ac.at/~jthorn/home.html
Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
"There's a new language called C+++. The only problem is every time
you try to compile your modem disconnects." - Richard Beigel
Ron Natalie
James Kanze wrote:
>
> > Is that *any* name containing a double score *anywhere* in the name?
>
> Yes.
Yep, leading ones are typically used for funny predefined processor
macros. Double underbars in the middle are frequently delimeters for
separating the name mangling parts.
>
> > > — Each name that begins with an underscore is reserved
> > > to the implementation for use as a name in the global
> > > namespace.
>
> > Is that *any* name, regardless of the case of the first letter?
>
> Yes. But only at global scope.
_ followed by uppercase is reserved for the stanard unconditionally. You
can cause most of the standard templates a lot of hearburn because it uses
this convention for it's internal indentifers. For fun, start using variables
like _A, and _Ty in the same file as the use of a vector template.
> That's for the standard. In practice, almost all compilers seem to
> have a violation of the last rule, typically a macro which starts with
> an underscore followed by a lower case letter.
>
Really? most use double underscores. Of course, in order to do any
significant programming you often must load include files that polute
the namespace with funny macros. However, any compiler that took the
C89 spec seriously cleaned out the other ones out of the standard headers.
Mark Wilden
news:MPG.14a9db8c9...@news.mindspring.com...
>
> However, as has been posted here numerous times, some
> implementations get this wrong, so it's not prudent to use a leading
> underscore even where it is technically legal.
This doesn't make sense to me. If I'm writing a Windows program using Visual C++
(which is probably what most C++ programmers are in fact doing) why is following
the standard with regard to prefixing member names with underscores "imprudent"?
But let's say I do decide to convert thousands of lines of MFC to another
windowing system and another compiler. I (or my boss) is an idiot, but there you
go. Let's go one farther and say that the new compiler didn't support the
standard in this respect. What would that mean? That it would disallow my member
names? Hardly likely.
In sum, there's no need to be afraid to use underscores in front of member
names, if that wets your whistle. Admonitions to the contrary are similar to
those on the subject of 'using namespace'. Programming is a logical activity. We
don't need to be afraid.
Carl Daniel
"Ron Natalie" <r...@sensor.com> wrote in message
news:3A40EE1A...@sensor.com...
> James Kanze wrote:
> _ followed by uppercase is reserved for the stanard unconditionally. You
> can cause most of the standard templates a lot of hearburn because it uses
> this convention for it's internal indentifers. For fun, start using
variables
> like _A, and _Ty in the same file as the use of a vector template.
>
> > That's for the standard. In practice, almost all compilers seem to
> > have a violation of the last rule, typically a macro which starts with
> > an underscore followed by a lower case letter.
> >
>
Maybe I'm missing something here... but doesn't that make virtually every
implementation of the standard library which isn't "built-in" to the
compiler non-conforming to the standard? In practice, STLPort 4.0 is
nothing more than a bunch of user code which happens to implement classes
which conform to the standard, but in general, it's not part of "the
implementation" of the language.
On a related subject - can anyone give a good explanation WHY STL
implementations (e.g. Dinkumware, STLPort, SGI) use obnoxious names like _Ty
for their template parameters/member names/local variables? These names are
all appearing outside the global namespace, so why not give them nice
readable names instead of all the gobbledygook?
-cd
Stan Brown
Mark Wilden <ma...@pagm.com> wrote in comp.lang.c++.moderated:
>"Stan Brown" <bra...@mindspring.com> wrote in message
>news:MPG.14a9db8c9...@news.mindspring.com...
>>
>> However, as has been posted here numerous times, some
>> implementations get this wrong, so it's not prudent to use a leading
>> underscore even where it is technically legal.
>
>This doesn't make sense to me. If I'm writing a Windows program using Visual
C++
>(which is probably what most C++ programmers are in fact doing) why is
following
>the standard with regard to prefixing member names with underscores
"imprudent"?
I won't speak about Brand M in particular. Though I believe it has
this problem, I could be mistaken.
Many implementations use macro names that begin with an underscore
and a lower-case letter. That means that one or more of your member
names may be silently changed to something entirely different, if
you have marked them with leading underscores. Even worse, it may
happen in some of your compilation units and not others, depending
on which implementation-supplied header files you include.
Yes, the standard forbids this. But that does you no good when your
code mysteriously fails (to compile, if you're lucky; to run
correctly, if you're not).
When many implementations have a bug, it is not prudent to write
code as though that bug did not exist. Even if you happen to be
writing code on an implementation that does not have that bug,
you're just creating a time bomb in case the code is later ported to
one that does.
--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
reserved C++ identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Michiel Salters
> In article <3A3F28A7...@dresdner-bank.com>,
> James Kanze <James...@dresdner-bank.com> wrote:
> >Single underscore is both legal and fully usable everywhere but in the
> >initial position. The restrictions you give apply to an initial
> >underscore only. Double underscore is illegal anywhere.
> I'd like to make sure I understand this. Are you indeed saying that
> class foo {
> public:
> void doit_now(int x);
> void doit_now__alpha(int x);
> void doit_now__beta(int x);
> };
> is illegal, due to the double-underscores in the member function names?
Precisely.
It is acceptable for a compiler vendor to define macros named doit_now__alpha
etc.
Most won't, but that doesn't affect the legality. And the compiler most
certainly
won't complain about names with double underscores: standard macros generate
them
quite often.
--
Michiel Salters
Michiel...@cmg.nl
sal...@lucent.com
James Kanze
> In article <3A3F28A7...@dresdner-bank.com>,
> James Kanze <James...@dresdner-bank.com> wrote:
> >Single underscore is both legal and fully usable everywhere but in the
> >initial position. The restrictions you give apply to an initial
> >underscore only. Double underscore is illegal anywhere.
> I'd like to make sure I understand this. Are you indeed saying that
> class foo
> {
> public:
> void doit_now(int x);
> void doit_now__alpha(int x);
> void doit_now__beta(int x);
> };
> is illegal, due to the double-underscores in the member function names?
Yes. The program has undefined behavior. On the other hand, I doubt
there is a compiler where this particular case will cause a problem.
(The potential problem is that the compiler will use double underscore
in its name mangling, and you may end up with a conflict with a
mangled name.)
> This is hardly a conclusive argument, but I note that my usual "gcc
> with reasonable warnings enabled", g++ 2.95.2 with
> g++ -Wall -W -Wno-unused -Wshadow -Winline -Wpointer-arith \
> -Wbad-function-cast -Wcast-align -Wstrict-prototypes \
> -Wmissing-prototypes -Wmissing-declarations -Woverloaded-virtual \
> -Wsynth -ffor-scope
> has no complaints about this class.
It also have no complaints about modifying a variable twice without an
intervening sequence point. This is undefined behavior. Stepping on
the implementation name space is undefined behavior.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> Mark Wilden <ma...@pagm.com> wrote in comp.lang.c++.moderated:
> >"Stan Brown" <bra...@mindspring.com> wrote in message
> >news:MPG.14a9db8c9...@news.mindspring.com...
> >> However, as has been posted here numerous times, some
> >> implementations get this wrong, so it's not prudent to use a
> >> leading underscore even where it is technically legal.
> >This doesn't make sense to me. If I'm writing a Windows program
> >using Visual C++ (which is probably what most C++ programmers are
> >in fact doing) why is following the standard with regard to
> >prefixing member names with underscores "imprudent"?
> I won't speak about Brand M in particular. Though I believe it has
> this problem, I could be mistaken.
It does. Maybe not in conforming mode, but if you are in conforming
mode, you can't use MFC.
> Many implementations use macro names that begin with an underscore
> and a lower-case letter. That means that one or more of your member
> names may be silently changed to something entirely different, if
> you have marked them with leading underscores. Even worse, it may
> happen in some of your compilation units and not others, depending
> on which implementation-supplied header files you include.
> Yes, the standard forbids this. But that does you no good when your
> code mysteriously fails (to compile, if you're lucky; to run
> correctly, if you're not).
> When many implementations have a bug, it is not prudent to write
> code as though that bug did not exist. Even if you happen to be
> writing code on an implementation that does not have that bug,
> you're just creating a time bomb in case the code is later ported to
> one that does.
Note that some implementations do manage to avoid the problem in 100%
conforming mode. I think, for example, that Sun CC does. But I don't
know, because I've never actually tried to use the compiler in 100%
conforming mode. Somewhere in the application, I generally need
something from unistd.h, or a Posix extension, or ... (And I think
Posix adds the _[a-z].* names to the reserved everywhere category.)
In the end, I think that it is best to consider the problem as
general. The problem, of course, is that you can write an awful lot
of code without accidentally hitting one of the symbols actually
defined as a macro. So you get a real feeling of security.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> However, any compiler that took the C89 spec seriously cleaned out
> the other ones out of the standard headers.
Try the following program with g++ (2.95.2, Windows NT, Cygwin
environment):
#include <stdio.h>
struct X { int _stdin_r( int ) ; } ;
int
main()
{
printf( "Hello, world\n" ) ;
return 0 ;
}
I think you'll agree that it is perfectly legal, according to the
standard, and that any conforming implementation must accept it,
compile it correctly and the output must be "Hello, world". According
to g++:
conflict.cc:4: parse error before `int'
And I'm not trying to pick on g++. It just happens to be the compiler
I have handy. I think you can find similar programs for most
compilers. Unless you are using the strictest of ISO strict modes,
and no non standard includes, I'm sure that you can find them.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Steve Clamage
>
> "Stan Brown" <bra...@mindspring.com> wrote in message
> news:MPG.14a9db8c9...@news.mindspring.com...
> >
> > However, as has been posted here numerous times, some
> > implementations get this wrong, so it's not prudent to use a leading
> > underscore even where it is technically legal.
>
> This doesn't make sense to me. If I'm writing a Windows program using Visual C++
> (which is probably what most C++ programmers are in fact doing) why is following
> the standard with regard to prefixing member names with underscores "imprudent"?
Because implementations historically have stepped on what is now in
the user's namespace. In particular, what are nominally C and C++
header files are also header files for the OS.
For example, X/Open and POSIX require definitions in many of the C headers
that are in the C/C++ programmer's namespace, and therefore should not be
in a standard C header. But because the header both a C header and an OS
header, so you can't apply exclusively C/C++ naming rules to them.
Beyond what current standards require, OS's typically retain compatibility
with their earlier versions. The C and C++ standards grant to programmers
part of the namespace that earlier OS versions used -- such as leading
underscores in general. The OS vendor can choose to break existing
programs that rely on the historical names, or remove those names
so that new programs can use more of the programmer's name space.
The choice is pretty simple. If you are writing a new program, you
can avoid using the historical names, but it's often the case that
changing old application code is not an option.
Just like the pedestrian who proclaimed that he had the right of way
as he stepped in front of the bus, you can insist on your right to use
leading underscores in names. Or you can use a naming convention that
is less likely to collide with names in system headers.
--
Steve Clamage, stephen...@sun.com
James Kanze
> "Ron Natalie" <r...@sensor.com> wrote in message
> news:3A40EE1A...@sensor.com...
> > James Kanze wrote:
> > _ followed by uppercase is reserved for the stanard
> > unconditionally. You can cause most of the standard templates a
> > lot of hearburn because it uses this convention for it's internal
> > indentifers. For fun, start using > variables like _A, and _Ty in
> > the same file as the use of a vector template.
> > > That's for the standard. In practice, almost all compilers seem
> > > to have a violation of the last rule, typically a macro which
> > > starts with an underscore followed by a lower case letter.
> Maybe I'm missing something here... but doesn't that make virtually
> every implementation of the standard library which isn't "built-in"
> to the compiler non-conforming to the standard?
Yes. To begin with, they define things in std::, which is forbidden
by the standard.
Replacing parts of the standard library, except for operator
new/operator delete and a very few functions like terminate, is
undefined behavior. The implementation may allow it as an extension.
The current situation is that most (all?) current implementations
allow it, to an undocumented degree. (Replacing std::type_info with
something arbitrary is likely to get you in deep trouble with most
implementations, for example.)
> In practice,
> STLPort 4.0 is nothing more than a bunch of user code which happens
> to implement classes which conform to the standard, but in general,
> it's not part of "the implementation" of the language.
If you view it that way, then it is illegal C++, and you shouldn't use
it. Alternatively (and I think this is how the STLPort people view
it), by replacing the standard library delivered with the compiler
with STLPort, you have created a new implementation, and the STLPort
is part of that implementation. The authors of STLPort go to great
pains precisely so that their code will integrate as part of the
implementation.
> On a related subject - can anyone give a good explanation WHY STL
> implementations (e.g. Dinkumware, STLPort, SGI) use obnoxious names
> like _Ty for their template parameters/member names/local variables?
> These names are all appearing outside the global namespace, so why
> not give them nice readable names instead of all the gobbledygook?
To start with, you're legally allowed to write:
#define niceReadableName 1+2/3
before including the header.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> James Kanze wrote:
> > > Is that *any* name containing a double score *anywhere* in the name?
> > Yes.
> Yep, leading ones are typically used for funny predefined processor
> macros. Double underbars in the middle are frequently delimeters
> for separating the name mangling parts.
Some also use it for keywords for implementation specific extensions.
Microsoft is famous for this, but I've seen it in others.
> > > > — Each name that begins with an underscore is reserved
> > > > to the implementation for use as a name in the global
> > > > namespace.
> > > Is that *any* name, regardless of the case of the first letter?
> > Yes. But only at global scope.
> _ followed by uppercase is reserved for the stanard unconditionally.
> You can cause most of the standard templates a lot of hearburn
> because it uses this convention for it's internal indentifers. For
> fun, start using variables like _A, and _Ty in the same file as the
> use of a vector template.
Don't the internal identifiers generally have limited scope?
Globally, I suspect that such usage won't cause problems. Which will
make it all the more mysterious when it exceptionally does.
> > That's for the standard. In practice, almost all compilers seem
> > to have a violation of the last rule, typically a macro which
> > starts with an underscore followed by a lower case letter.
> Really? most use double underscores. Of course, in order to do any
> significant programming you often must load include files that
> polute the namespace with funny macros. However, any compiler that
> took the C89 spec seriously cleaned out the other ones out of the
> standard headers.
Yes. I wasn't talking so much about the standard libraries, as the
others you generally end up having to use. Just for fun, I tried the
following command on the two environments I have online at the moment,
Windows NT 4.0/CygWin/g++ 2.95.2 and AIX 4.1 :
find <include_base> -name '*.h' | xargs egrep '#define *_[a-z]' |
wc -l
The Windows g++ output 77, and the AIX 76. In both cases, one of the
files with such macros was stdio.h! (Under control of a conditional
compilation, so you don't get them all of the time, and presumably not
in 100% conformant mode.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Steve Clamage
>
> Maybe I'm missing something here... but doesn't that make virtually every
> implementation of the standard library which isn't "built-in" to the
> compiler non-conforming to the standard? In practice, STLPort 4.0 is
> nothing more than a bunch of user code which happens to implement classes
> which conform to the standard, but in general, it's not part of "the
> implementation" of the language.
Technically yes. The C++ standard considers the library a seamless part
of "the implemenation." The results of trying to replace portions of
the implementation (other than the designated replaceable portions)
are undefined.
But an implementation can choose to provide (or might by accident allow)
a way for users to replace the library. In that case, the replacement
becomes part of "the implementation."
>
> On a related subject - can anyone give a good explanation WHY STL
> implementations (e.g. Dinkumware, STLPort, SGI) use obnoxious names like _Ty
> for their template parameters/member names/local variables? These names are
> all appearing outside the global namespace, so why not give them nice
> readable names instead of all the gobbledygook?
Suppose the library headers used nice readable names like "size" or "count".
Since those names are in the programmer's namespace, a valid user program
can define a macro "size" or "count" before including the headers. The
valid C++ program won't compile or run according to the requirements of
the standard, meaning the implementation is non-conforming.
If instead all the non-reserved names in headers use spellings reserved to
the implementation, no such conflict can occur. That is, _Ty is safe in
a header, because user code is not allowed to define an identifier spelled
_Ty.
--
Steve Clamage, stephen...@sun.com
Pete Becker
>
> On a related subject - can anyone give a good explanation WHY STL
> implementations (e.g. Dinkumware, STLPort, SGI) use obnoxious names like _Ty
> for their template parameters/member names/local variables? These names are
> all appearing outside the global namespace, so why not give them nice
> readable names instead of all the gobbledygook?
>
The reason that those names are reserved to the implementation is so
that the implementation can use them. That way, if someone writes code
like this:
#define _Ty (x*y)
#include <vector>
we can tell them that they shouldn't do that.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
James Dennett
>
> "Ron Natalie" <r...@sensor.com> wrote in message
> news:3A40EE1A...@sensor.com...
> > James Kanze wrote:
> > _ followed by uppercase is reserved for the stanard unconditionally. You
> > can cause most of the standard templates a lot of hearburn because it uses
> > this convention for it's internal indentifers. For fun, start using
> variables
> > like _A, and _Ty in the same file as the use of a vector template.
> >
> > > That's for the standard. In practice, almost all compilers seem to
> > > have a violation of the last rule, typically a macro which starts with
> > > an underscore followed by a lower case letter.
> > >
> >
>
> Maybe I'm missing something here... but doesn't that make virtually every
> implementation of the standard library which isn't "built-in" to the
> compiler non-conforming to the standard? In practice, STLPort 4.0 is
> nothing more than a bunch of user code which happens to implement classes
> which conform to the standard, but in general, it's not part of "the
> implementation" of the language.
In the language of the C++ Standard, STLPort+Compiler+Linker+OtherStuff is
"the implementation". Portability of the STLPort code between different
compilers is not guaranteed by the C++ Standard, but rather by having an
excellent level of knowledge of what code works with different compilers.
The C++ Standard doesn't define a standard for compilers. It defines a
standard for complete implementations, which usually include compilers,
linkers, and an underlying OS. I'm not sure if the Standard would
consider the hardware to also form part of the implementation.
> On a related subject - can anyone give a good explanation WHY STL
> implementations (e.g. Dinkumware, STLPort, SGI) use obnoxious names like _Ty
> for their template parameters/member names/local variables? These names are
> all appearing outside the global namespace, so why not give them nice
> readable names instead of all the gobbledygook?
In case they collide with macros defined by users. We can legally write
code like
#define Ty y(
#include <vector>
so using Ty as a name in <vector> would be problematic. The Standard makes
it illegal (more accurately, undefined) for users to write the similar code
#define _Ty y(
#include <vector>
The rules on which identifiers can be used portably by users are there
precisely to give "implementations" (compilers and libraries etc.)
Ron Natalie
> Note that some implementations do manage to avoid the problem in 100%
> conforming mode. I think, for example, that Sun CC does. But I don't
> know, because I've never actually tried to use the compiler in 100%
> conforming mode. Somewhere in the application, I generally need
> something from unistd.h, or a Posix extension, or ... (And I think
> Posix adds the _[a-z].* names to the reserved everywhere category.)
The thing that sucks about VC++ is that it can't even compile the system
specific headers when you set it into Disable Extensions mode. There's
no particularly good reason for this other than the fact that Microsoft
is hosed up. It wouldn't take much work to fix the header files to work
right (who cares if the actual implementation of MFC is compiled that way
or not).
Ron Natalie
Carl Daniel wrote:
>
> Maybe I'm missing something here... but doesn't that make virtually every
> implementation of the standard library which isn't "built-in" to the
> compiler non-conforming to the standard?
YES...unless you consider the inclusion of the alternate STL to be a
new part of the base implementation it is technically invalid.
Essentially, it's up to you to determine that your inclusion of the
STLPORT (with it's use of reserved symbols) doesn't hose standards
expecting programs that you want to compile.
Ron Natalie
James Kanze wrote:
>
> Yes. The program has undefined behavior. On the other hand, I doubt
> there is a compiler where this particular case will cause a problem.
You're doubts are wrong. G++ won't resolve symbols at link time with
double underscores.
>
> > This is hardly a conclusive argument, but I note that my usual "gcc
> > with reasonable warnings enabled", g++ 2.95.2 with
>
> > g++ -Wall -W -Wno-unused -Wshadow -Winline -Wpointer-arith \
> > -Wbad-function-cast -Wcast-align -Wstrict-prototypes \
> > -Wmissing-prototypes -Wmissing-declarations -Woverloaded-virtual \
> > -Wsynth -ffor-scope
>
> > has no complaints about this class.
Yep, but try using more than one file with it. I bet you get undefined
references if they are referenced in a different file than they are defined in.
James Kanze
> The C++ Standard doesn't define a standard for compilers. It
> defines a standard for complete implementations, which usually
> include compilers, linkers, and an underlying OS. I'm not sure if
> the Standard would consider the hardware to also form part of the
> implementation.
I think even the local electric company is part of the implementation.
At least, I don't think that Sun support would treat seriously a
complain that Sun CC wasn't conform because it failed to compile my
program during a power outage.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Dennett
>
> Ron Natalie wrote:
>
> > However, any compiler that took the C89 spec seriously cleaned out
> > the other ones out of the standard headers.
>
> Try the following program with g++ (2.95.2, Windows NT, Cygwin
> environment):
>
> #include <stdio.h>
>
> struct X { int _stdin_r( int ) ; } ;
>
> int
> main()
> {
> printf( "Hello, world\n" ) ;
> return 0 ;
> }
>
> I think you'll agree that it is perfectly legal, according to the
> standard, and that any conforming implementation must accept it,
> compile it correctly and the output must be "Hello, world". According
> to g++:
>
> conflict.cc:4: parse error before `int'
>
> And I'm not trying to pick on g++. It just happens to be the compiler
> I have handy. I think you can find similar programs for most
> compilers. Unless you are using the strictest of ISO strict modes,
> and no non standard includes, I'm sure that you can find them.
For anyone who cares, a more recent development version of gcc 2.96
running on Linux does not have this problem in this specific example,
although it is quite possible that similar problems are lurking.
In fact, with "test.C" containing only the line "#include <stdio.h>",
running this through g++'s preprocessor to get a list of macros with
g++ --ansi -dM -o test.E test.C
shows that none of the macro names match "^_[a-z]".
I've not tested with other headers, but it does appear that g++ is
trying hard to conform in this area.
-- James Dennett <jden...@acm.org>
Mark Wilden
>
> Just like the pedestrian who proclaimed that he had the right of way
> as he stepped in front of the bus, you can insist on your right to use
> leading underscores in names.
If the consequences of making the wrong decision were similar to the bus situation, you'd have a point. But they're not, of course.
It's not a question of "insisting" on a "right". It's a question of using a (perfectly legal) practice until its disadvantages
outweigh its benefits. Since I've yet to come across a disadvantage, that makes it a pretty simple question to answer.
Now, if I ever create a member variable that conflicts with a macro in a nonconformant compiler, I'll revisit this approach. At 15
years and counting, though, I won't hold my breath...
Mark Wilden
>
> [cc'd to previous poster for speed; please follow up in newsgroup]
(Wish you wouldn't. Speed is hardly of the essence.)
> Many implementations use macro names that begin with an underscore
> and a lower-case letter. That means that one or more of your member
> names may be silently changed to something entirely different, if
> you have marked them with leading underscores. Even worse, it may
> happen in some of your compilation units and not others, depending
> on which implementation-supplied header files you include.
If my unit tests are not sufficient to ferret the macro-induced change of one piece of code to a completely different piece of code
because I used a leading underscore in a member name, then I should just be taken out an shot. :)
> When many implementations have a bug, it is not prudent to write
> code as though that bug did not exist
Depends on the bug. In this case, it's blindingly trivial to fix in the unlikely event that there's ever a problem.
> Even if you happen to be
> writing code on an implementation that does not have that bug,
> you're just creating a time bomb in case the code is later ported to
> one that does.
"Time bomb" is wayyyy too hyperbolistic a term to refer to this problem.
Pete Becker
>
> If my unit tests are not sufficient to ferret the macro-induced change of one piece of code to a completely different piece of code
> because I used a leading underscore in a member name, then I should just be taken out an shot. :)
Nope. Doing this gets you deep into a combinatorial explosion. To test
whether the header that defines your class runs into a problem here you
need to write a set of tests to check every possible sequence of
#include directives and every possible set of compiler switches. It's
much simpler to simply avoid the potential problem.
>
> > When many implementations have a bug, it is not prudent to write
> > code as though that bug did not exist
>
> Depends on the bug. In this case, it's blindingly trivial to fix in the unlikely event that there's ever a problem.
Most bugs are simple to fix. The hard part is figuring out what went
wrong, and a hidden change in the name of a function can be difficult to
track down.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Harald Luessen
On 21 Dec 2000 19:05:33 -0500, Steve Clamage <stephen...@sun.com>
wrote:
>Carl Daniel wrote:
>>
>> On a related subject - can anyone give a good explanation WHY STL
>> implementations (e.g. Dinkumware, STLPort, SGI) use obnoxious names like _Ty
>> for their template parameters/member names/local variables? These names are
>> all appearing outside the global namespace, so why not give them nice
>> readable names instead of all the gobbledygook?
>
>Suppose the library headers used nice readable names like "size" or "count".
>Since those names are in the programmer's namespace, a valid user program
>can define a macro "size" or "count" before including the headers. The
>valid C++ program won't compile or run according to the requirements of
>the standard, meaning the implementation is non-conforming.
>
>If instead all the non-reserved names in headers use spellings reserved to
>the implementation, no such conflict can occur. That is, _Ty is safe in
>a header, because user code is not allowed to define an identifier spelled
>_Ty.
If the _T is the important part or even the preceding underscore
why don't STL developers use readable names like _Tcount or _Tsize ?
Harald
Mark Wilden
>
> If the _T is the important part or even the preceding underscore
> why don't STL developers use readable names like _Tcount or _Tsize ?
Or just _Count and _Size.
I've thought that one reason for the virtually shrouded source of the VC++/Dinkumware STL code is to improve compilation time.
Mark Wilden
news:3A4B7393...@acm.org...
> Mark Wilden wrote:
> >
> > If my unit tests are not sufficient to ferret the macro-induced change of
one piece of code to a completely different piece of
code
> > because I used a leading underscore in a member name, then I should just
be taken out an shot. :)
>
> Nope. Doing this gets you deep into a combinatorial explosion. To test
> whether the header that defines your class runs into a problem here you
> need to write a set of tests to check every possible sequence of
> #include directives and every possible set of compiler switches.
I can't see why. I don't require the code to run under those circumstances, so
why would I test for it? All I care about is that the
code I do run works as advertised. Different for a libary vendor, of course
(like yourself), but then libary vendors always need to
be more circumspect than the rest of us.
> It's much simpler to simply avoid the potential problem.
For the last 15 years, it's been pretty damn simple. :)
> > > When many implementations have a bug, it is not prudent to write
> > > code as though that bug did not exist
> >
> > Depends on the bug. In this case, it's blindingly trivial to fix in the
unlikely event that there's ever a problem.
>
> Most bugs are simple to fix. The hard part is figuring out what went
> wrong, and a hidden change in the name of a function can be difficult to
> track down.
I was thinking about this today, and trying to imagine a scenario when the
kind of thing we're talking about would _not_ be
blindingly obvious. I'm sure there are contrived examples, but in the real
world...?
Dietmar Kuehl
Harald Luessen (harald....@gmx.de) wrote:
: If the _T is the important part or even the preceding underscore
: why don't STL developers use readable names like _Tcount or _Tsize ?
There is a pretty simple reason: The lines are normally not long enough
for the resulting expressions..! I'm using somewhat more descriptive
names than '_T', eg. '_CS_cT' for "character type" (the "CS" is the
beginning of all identifiers I'm using in the implementation of the C++
standard library saying, well, "c++ standard", as far as I remember :-)
or '_CS_InIt' for an "input iterator", but often this becomes a pain
because I'm normally running out of space and I consider expressions
being spread over multiple lines to be pretty unreadable. I prefer
shorter names to breaking expressions over multiple lines!
In addition, nobody is supposed to read this code anyway: It is part of
the implementation and not your business to look at. Using anything
from these headers for a different purpose than the standard C++
library they ship with would violate copyrights anyway. So, what is
your problem with these names in the first place?
--
<mailto:dietma...@yahoo.de> <http://www.dietmar-kuehl.de/~kuehl/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message
> news:3A4B7393...@acm.org...
> > Mark Wilden wrote:
> > >
> > > If my unit tests are not sufficient to ferret the macro-induced change
of
> one piece of code to a completely different piece of
> code
> > > because I used a leading underscore in a member name, then I should just
> be taken out an shot. :)
> >
> > Nope. Doing this gets you deep into a combinatorial explosion. To test
> > whether the header that defines your class runs into a problem here you
> > need to write a set of tests to check every possible sequence of
> > #include directives and every possible set of compiler switches.
>
> I can't see why. I don't require the code to run under those circumstances,
so
> why would I test for it? All I care about is that the
> code I do run works as advertised.
Please explain how you can be sure that a header that you wrote works in
all possible contexts where it could be used without testing all those
contexts.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
AllanW
> James Dennett wrote:
>
> > The C++ Standard doesn't define a standard for compilers. It
> > defines a standard for complete implementations, which usually
> > include compilers, linkers, and an underlying OS. I'm not sure if
> > the Standard would consider the hardware to also form part of the
> > implementation.
James Kanze <James...@dresdner-bank.com> wrote:
> I think even the local electric company is part of the implementation.
> At least, I don't think that Sun support would treat seriously a
> complain that Sun CC wasn't conform because it failed to compile my
> program during a power outage.
How far do you take this?
Are the keyboard and mouse part of the implementation? The
compiler won't work if I don't use the keyboard or mouse to
start the compiler running.
Is aluminium foil part of the implementation? The compiler
doesn't work right if I shove aluminium foil into the power
supply during a compile.
Is oxygen part of the implementation? If I suck all of the
air out of the room, the compile might finish anyway -- but
if nobody is alive to check the results, were there any?
Are the laws of physics part of the implementation? Etc...
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
Mark Wilden
> There is a pretty simple reason [for the terse identifiers in STL code]. The lines are normally not long
> enough for the resulting expressions..!
Whose lines? Are you trying to maintain an 80-char line length or something? I ask because my own line length is 220 characters.
> I prefer shorter names to breaking expressions over multiple lines!
Interesting. I'd definitely go the other way. Excessive identifier length is bad precisely for the reason you gave. But if I have to
choose between comprehensible identifiers and making everything fit on one line...well.
> In addition, nobody is supposed to read this code anyway: It is part of
> the implementation and not your business to look at.
That's an even more interesting remark, with which I heartily disagree, as well. I feel it's my business to look at any code on my
computer I want to.
Francis Glassborow
<ma...@pagm.com> writes
>For the last 15 years, it's been pretty damn simple. :)
But as code bases get ever larger, and we rely increasingly on libraries
(internal as well as external) it inevitably gets ever more complicated.
>
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
AllanW
> Harald Luessen (harald....@gmx.de) wrote:
> : If the _T is the important part or even the preceding underscore
> : why don't STL developers use readable names like _Tcount or _Tsize ?
dietma...@yahoo.com wrote:
[snip]
> In addition, nobody is supposed to read this code anyway: It
> is part of the implementation and not your business to look
> at. Using anything from these headers for a different purpose
> than the standard C++ library they ship with would violate
> copyrights anyway. So, what is your problem with these names
> in the first place?
Whoa, calm down, buddy. That isn't quite fair; I would hardly
expect a response like this from you!
First of all, we can care about the names even if we don't
want to read the code; they show up in error messages, when
we don't use the templates correctly. ("Error: cannot
implicitly convert _Ty from const char* to char *const" --
but you don't even HAVE a variable named _Ty!)
Secondly, there are reasons to read the code that do not
violate copyright rules:
* When documentation is unclear, go to the source
* When you need to do something similar, but not exactly
the same as a library function, you can look at how one
works and then do something similar
* When you already know that you used the template
incorrectly, but now you're trying to figure out why
it gave the particular incorrect results that it did
give
* If you believe that the code does not conform to the C++
standard, or at least your interpretation of it, and want
to find out exactly what it DOES do
* If you have reason (or paranoia) to suspect Trojan Horses
or other intentional problems in your library code -- in
other words, if you want to certify it yourself instead of
relying on the vendor
Your point is that the STL code has priorities that outweigh
the need to be readable, and that makes perfect sense. But
please don't tell me that the need to be readable isn't a
priority AT ALL?!?
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> Please explain how you can be sure that a header that you wrote works in
> all possible contexts where it could be used without testing all those
> contexts.
I won't explain that, since, as I already said, I don't require such assurance. All I require is that it works in the program(s) I'm
currently trying to ship. So far, the practice we're talking about (leading underscores in member variable names) works 100% for
that task.
If I were writing library code, it would be different, of course. In that case, I would indeed be more concerned about the supposed
buggy compilers out there that would cause problems with this practice.
Mark Wilden
>
> But as code bases get ever larger, and we rely increasingly on libraries
> (internal as well as external) it inevitably gets ever more complicated.
In the event, likely or unlikely, of one of my member variables with leading underscores conflicting with someone's
underscore-prepended macro, I'll be sure and take those several seconds to change the member name. At some point, however, this will
become a standards-conformance issue, and hopefully some compilers will.
Dietmar Kuehl
Mark Wilden (ma...@pagm.com) wrote:
: "Dietmar Kuehl" <ku...@ramsen.informatik.uni-konstanz.de> wrote in message
news:92ik38$a39$4...@news.BelWue.DE...
: > There is a pretty simple reason [for the terse identifiers in STL code].
The lines are normally not long
: > enough for the resulting expressions..!
: Whose lines?
Mine. That's all which matters to me when I'm doing development.
: Are you trying to maintain an 80-char line length or something?
... or something. I think my lines are somthing like 130 characters wide.
: I ask because my own line length is 220 characters.
Good for you. It would still be too few for certain expressions in the
standard library implementation but better than the 130 characters I
can fit on my screen. Sure, I could extend the lines and see only part
of it but this does not help me much: I need to see blocks of code. It
is, of course, just me an my style to development but this is what I
care about when coding things.
: > I prefer shorter names to breaking expressions over multiple lines!
: Interesting. I'd definitely go the other way. Excessive identifier
: length is bad precisely for the reason you gave. But if I have to
: choose between comprehensible identifiers and making everything fit
: on one line...well.
When coding I rarely read the identifiers. I see blocks of code and
their structure. I *know* what entities I'm manipulating and what they
are for. Thus, longer identifiers just distract my view. It is a
subtle thing and clearly a personal preference and approach to
development. However, I'm doing this since quite a while and found my
own style I'm feeling comfortable with. My style is, however, reflected
in the code I'm producing.
: > In addition, nobody is supposed to read this code anyway: It is part of
: > the implementation and not your business to look at.
: That's an even more interesting remark, with which I heartily
: disagree, as well. I feel it's my business to look at any code on my
: computer I want to.
You must be using a Linux system and depend on all those nice people
who give away their sources for free! I would never expect to get a
glimpse at the standard C library implementation beyond the headers.
The same should be true for the standard C++ library: It is just a flaw
of the compilers (lack of support for the 'export' stuff) which forces
the library writers to disclose their sources. Sorry, but if you happen
to read my sources of the standard C++ library you are getting at my
intellectual property! OK, I'm releasing them under very liberal terms
but this is not the case for all other implementations. ... and my
motivation for releasing the code for free is not necessarily that
people can learn from my code.
--
<mailto:dietma...@yahoo.de> <http://www.dietmar-kuehl.de/~kuehl/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Thomas Maeder
>
> In addition, nobody is supposed to read this code anyway: It is part of
> the implementation and not your business to look at. Using anything
> from these headers for a different purpose than the standard C++
> library they ship with would violate copyrights anyway. So, what is
> your problem with these names in the first place?
The STL part of the Standard C++ Library isn't just a library. It's also a
framework for extending it (e.g. adding a container type or an algorithm).
If I write an algorithm which offers functionality similar to a Standard
algorithm, looking at (and understanding) how that algorithm is implemented
is certainly a good idea. I don't think that this is likely to violate a
copyright.
Dietmar Kuehl
AllanW (all...@my-deja.com) wrote:
: dietma...@yahoo.com wrote:
: [snip]
: > In addition, nobody is supposed to read this code anyway: It
: > is part of the implementation and not your business to look
: > at. Using anything from these headers for a different purpose
: > than the standard C++ library they ship with would violate
: > copyrights anyway. So, what is your problem with these names
: > in the first place?
: Whoa, calm down, buddy. That isn't quite fair; I would hardly
: expect a response like this from you!
My sources are released under very liberal terms. However, my code is
still my intellectual property and I'm owning them! *Any use* of the
code not covered by the copyright. For example, taking code from my
headers, pasting it somewhere else and modifying it *without* putting
it under my copyright (plus potentially another copyright for the
changes) is illegal! ... and this is already a *very* liberal license!
You can use, modify, and distribute the code freely but you have to
maintain the copyright.
: First of all, we can care about the names even if we don't
: want to read the code; they show up in error messages, when
: we don't use the templates correctly. ("Error: cannot
: implicitly convert _Ty from const char* to char *const" --
: but you don't even HAVE a variable named _Ty!)
You should get used to determine the error from these error messages
because the source is likely to disappear if compilers start to
support the "export" and the stuff releated to it. No doubt, error
messages should improve to direct you better to the error but you
should not count on the source, in particular you should not count
on the source of the standard library functions.
: Secondly, there are reasons to read the code that do not
: violate copyright rules:
: * When documentation is unclear, go to the source
If the documentation is unclear, get a better one! There is plenty
of documentation of the standard C++ library available out there,
amoung others
- the standard itself, either the C++ or the C standard
- the Dinkumware online documentation (see <http://www.dinkumware.com>)
- "The C++ Standard Library", Nicolai Josuttis, Addison-Wesley
If it is unclear after reading this documentation, a defect report
is in order because the implementatio you happen to use is likely
to do the wrong thing anyway: If it is unclear from the standard,
the implementation chooses to do something which may or may not be
the thing other implementations choose to do. This is basically
what the recent C++ committee meetings were all about: Determining
what should be done in unclear or contradictory cases.
: * When you need to do something similar, but not exactly
: the same as a library function, you can look at how one
: works and then do something similar
This is illegal use of the code unless such use is explicitly allowed
in the license covering the library you are using. ... and even if it
is allowed, you should make sure to put the result under an appropriate
copyright! I'm actually pretty certain that for all interesting cases
you *don't* want to go down this road. In fact, in the early time of
the FSF they made sure that people working at certain project never
worked at similar commercial projects to make sure that they indeed had
the appropriate rights to create the software under a free license.
Just taking the code from a standard C++ library implementation and
adapting it to the needs of some project is certainly illegal unless
explicitly allowed! Personally I don't care too much about this but I
would probably consider legal steps if I would find code resembling
my code closely in a competitors implementation, at least if it is
covered by a stricter copyright than mine (basically, if cannot use my
own code).
: * When you already know that you used the template
: incorrectly, but now you're trying to figure out why
: it gave the particular incorrect results that it did
: give
That is what the documentation is for. If the 'export' stuff is
implemented you cannot go down this road anyway.
: * If you believe that the code does not conform to the C++
: standard, or at least your interpretation of it, and want
: to find out exactly what it DOES do
: * If you have reason (or paranoia) to suspect Trojan Horses
: or other intentional problems in your library code -- in
: other words, if you want to certify it yourself instead of
: relying on the vendor
Have you done this with the C library? Which implementation if you have
done it? Probably not glibc because this one is pretty hard to follow
and you will have an even harder time to determine whether it does the
right thing. ... and for most implementations you won't get the sources
anyway. So, how is this different to the standard C++ library?
If you have paranoia, you have to get an appropriate license with an
appropriate guarantee. My license/guarantee combination is appropriate
(because you are allowed to read the sources - you can do other more
intrusive things, too, as long as you maintain the copyright). I cannot
tell whether other licenses/guarantees are appropriate to investigate
or exclude Trojan Horses.
: Your point is that the STL code has priorities that outweigh
: the need to be readable, and that makes perfect sense. But
: please don't tell me that the need to be readable isn't a
: priority AT ALL?!?
I consider my implementation to be pretty readable: The only things I
consider to be unreadable are the '_CS_' prefixes but I consider them
as necessary (I'm using a '_CS_' prefix because this is very easily
changed to something else automatically unlike just capitalizing the
first character after an underscore: Such things occure eg. in system
headers, too, and you cannot be sure whether you can change it or not).
However, I got used to a lot of appreviation like 'cT' ("character
type"), 'Tr' ("traits"), 'InIt' ("Input Iterator"), etc.
>From your comments I conclude that obfuscation is actually a good thing
to protect you: If you can read my code, you would copy it and this
would be illegal! For my code there is an easy way out (you just have
to cover it with my copyright which would not affect anything you ship
in binary form, only stuff you ship in source form, because my
copyright is not the LGPL and you cannot be forced to give away the
source of changed code) but this is very different for other library
implementations eg. Dinkumware (you don't have the right to use their
code in your programs in a different from than the normal use as the
standard C++ library; see their license for details) or libstdc++ (you
have to provide the sources you changed). Just because you get the
sources, you cannot use them for anything else than what they are
intended for. In particular, you cannot use the sources to harvest
ideas! At least not trivially, ie. you have to add substantial stuff to
the source which are there. Changing a similar function to your needs
is not addition of substantial stuff.
Also, let me put the stuff I said above into some context: Creating
an efficient (whatever this means) implementation of the standard C++
library is a non-trivial task involving lots of work. I would hate that
this work is abused by someone grabbing a fortune and turning my work
into a commercial product competing with me. And I acknowledge that
others have invested even more into the creation of a standard C++
library. Just because we have to disclose our work due to technical
flaws of current C++ compilers does not allow anybody to use our
intellectual property for anything. The same applies, of course, to
other template libraries as well.
--
<mailto:dietma...@yahoo.de> <http://www.dietmar-kuehl.de/~kuehl/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message
news:3A4D0BD4...@acm.org...
> >
> > Please explain how you can be sure that a header that you wrote works in
> > all possible contexts where it could be used without testing all those
> > contexts.
>
> I won't explain that, since, as I already said, I don't require such
assurance. All I require is that it works in the program(s) I'm
> currently trying to ship. So far, the practice we're talking about (leading
underscores in member variable names) works 100% for
> that task.
>
I see. So you no longer claim that "If my unit tests are not sufficient
to ferret the macro-induced change of one piece of code to a completely
different piece of code because I used a leading underscore in a member
name, then I should just be taken out an shot."
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dennis Yelle
[...]
> Sorry, but if you happen
> to read my sources of the standard C++ library you are getting at my
> intellectual property!
I am sorry if you are just making a joke here, but there
seems to be some people who actually believe stuff like that.
If you did not learn to program by reading programs,
exactly how did you learn?
We are all standing on the shoulders of those we learned from.
I just don't see how anyone can claim that the source
code they ship to others should not be read.
These constant cries of "Mine! Mine!" over things that
used to be freely given away is starting to really bug me.
I used to think that only 3 year olds did that.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
P.J. Plauger
news:t4pneog...@news.supernews.com...
> > If the _T is the important part or even the preceding underscore
> > why don't STL developers use readable names like _Tcount or _Tsize ?
>
> Or just _Count and _Size.
>
> I've thought that one reason for the virtually shrouded source of the
VC++/Dinkumware STL code is to improve compilation time.
Once upon a time, that was true. Dinkumware's C code has been evolving since
1989
and its C++ code since 1993. In the early days, computers were slow enough that
the time required for the compiler to read a large header was quite apparent.
For
a nontrivial project rebuild, shorter headers could save minutes to hours.
Yet another reason for the terseness was my practice of publishing most of this
code in textbooks and magazine articles. Page width limitations argue for terse
names, and page number limitations to a minimum of white space.
But those reasons are mostly gone now. The latest version of the Dinkumware
libraries does indeed use names such as _Count and _Size. We have gone to a
wider
source line. In some cases, we are also spreading text across more lines, but
that
is more to avoid debugger problems than to improve readability.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Phil Edwards
Mark Wilden <ma...@pagm.com> wrote:
+ "Dietmar Kuehl" <ku...@ramsen.informatik.uni-konstanz.de> wrote in message news:92ik38$a39$4...@news.BelWue.DE...
+
+ > There is a pretty simple reason [for the terse identifiers in STL code]. The lines are normally not long
+ > enough for the resulting expressions..!
+
+ Whose lines? Are you trying to maintain an 80-char line length or something? I ask because my own line length is 220 characters.
Aye, we can tell. Reading your Usenet posts is a PITA because you don't
stay within the 80-character limit. I don't mind wide code in editors,
but trying to read English text is another matter.
(I thought the comp.lang.c++.moderated approval software handled that to
some extend, but this wouldn't be the first time I'm wrong. :-)
+ > In addition, nobody is supposed to read this code anyway: It is part of
+ > the implementation and not your business to look at.
+
+ That's an even more interesting remark, with which I heartily disagree, as well. I feel it's my business to look at any code on my
+ computer I want to.
+
I agree, but primarily for a different reason.
Leaving issues of "rights" and "property" aside, I need to be able to
read the code in order to step into it when debugging. One could say that
the libraries are supposed to be black boxes, and in a perfect world they
would be. But just a few months ago I found problems and never would have
solved them if I had not been able to go /inside/ malloc() by two more calls.
Luck++;
Phil
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.
ka...@gabi-soft.de
|> Dietmar Kuehl wrote:
|> [...]
|> > Sorry, but if you happen
|> > to read my sources of the standard C++ library you are getting at my
|> > intellectual property!
|> I am sorry if you are just making a joke here, but there
|> seems to be some people who actually believe stuff like that.
|> If you did not learn to program by reading programs,
|> exactly how did you learn?
You *should* be reading programs that were meant to be read, and not
just random code for which you happen to have the sources. I think that
Dietmar's point was that this particular code wasn't written with a
pedagogic purpose in mind, and wasn't appropriate for that purpose.
Also, although I started learning programming by reading other's code,
most of what I now know comes from reading books and articles, and not
code.
|> We are all standing on the shoulders of those we learned from.
True, but we didn't necessarily learn by reading their code.
|> I
|> just don't see how anyone can claim that the source code they ship
|> to others should not be read. These constant cries of "Mine!
|> Mine!" over things that used to be freely given away is starting to
|> really bug me. I used to think that only 3 year olds did that.
It's called artistic control. It's a recognized principle, even if it
has been subverted for commercial ends. And I've rarely if ever seen
software that didn't assert it: the GPL is perhaps the most flagrant
example, but almost all software authors exerce some sort of artistic
control over what you do with their "creation".
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
ka...@gabi-soft.de
|> That's an even more interesting remark, with which I heartily
|> disagree, as well. I feel it's my business to look at any code on my
|> computer I want to.
Good luck. I can't look at the sources to my C++ compiler (Sun CC). I
suppose that if I paid enough, and signed enough non-disclosure
agreements, I could. But what would it gain me? I do have access to
the sources of my other compiler (g++), but whenever I've suspected an
error or something, I've gone to g++ support (and in the one case of a
serious bug, I got the same treatment I'd have gotten from Sun: it will
be fixed in the next release:-).
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
ka...@gabi-soft.de
|> "Steve Clamage" <stephen...@sun.com> wrote in message news:3A425471...@sun.com...
|> >
|> > Just like the pedestrian who proclaimed that he had the right of way
|> > as he stepped in front of the bus, you can insist on your right to use
|> > leading underscores in names.
|> If the consequences of making the wrong decision were similar to the
|> bus situation, you'd have a point. But they're not, of course.
|> It's not a question of "insisting" on a "right". It's a question of
|> using a (perfectly legal) practice until its disadvantages outweigh
|> its benefits. Since I've yet to come across a disadvantage, that
|> makes it a pretty simple question to answer.
In the end, everything comes down to a question of benefits vs. costs.
There is a potential cost involved in using a leading underscore. It
may be small, but it is there. What is the benefit?
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dennis Yelle
>
> Dennis Yelle <denn...@jps.net> writes:
>
> |> Dietmar Kuehl wrote:
> |> [...]
> |> > Sorry, but if you happen
> |> > to read my sources of the standard C++ library you are getting at my
> |> > intellectual property!
>
> |> I am sorry if you are just making a joke here, but there
> |> seems to be some people who actually believe stuff like that.
> |> If you did not learn to program by reading programs,
> |> exactly how did you learn?
>
> You *should* be reading programs that were meant to be read, and not
> just random code for which you happen to have the sources. I think that
> Dietmar's point was that this particular code wasn't written with a
> pedagogic purpose in mind, and wasn't appropriate for that purpose.
My experience is that I learn much more by reading code that actually
works rather than by reading code designed for humans to read.
Most of the implementation of the STL in SGI's headers actually works,
for example, as opposed to, for example, the Desk Calculator example
in Chapter 6 of Stroustrup's TC++PL3rd, or the Minix source in Tanenbaum's
book OS:DandI, both of which don't. Stroustrup's response to one of the
bugs I reported to him was basically, "Well, I know, but to fix it would
make the code longer." What good does it do me to read code that simply
Does Not Work? We all know that code that has not been tested does not work,
and authors who write for humans as opposed to machines never seem to
test it enough to find the bugs. Or, to put it another way, the code
is not designed to run, only to demonstrate the points the author was
making in that particular chapter or article or book.
> Also, although I started learning programming by reading other's code,
> most of what I now know comes from reading books and articles, and not
> code.
>
> |> We are all standing on the shoulders of those we learned from.
>
> True, but we didn't necessarily learn by reading their code.
>
> |> I
> |> just don't see how anyone can claim that the source code they ship
> |> to others should not be read. These constant cries of "Mine!
> |> Mine!" over things that used to be freely given away is starting to
> |> really bug me. I used to think that only 3 year olds did that.
>
> It's called artistic control. It's a recognized principle, even if it
> has been subverted for commercial ends. And I've rarely if ever seen
> software that didn't assert it: the GPL is perhaps the most flagrant
> example, but almost all software authors exerce some sort of artistic
> control over what you do with their "creation".
The last time I read the GPL there was absolutely no restriction
on who could read the code. In fact, my interpretation of the GPL
is that its intent is to cause more source code to be available
for everyone to read and learn from. I don't know if it
actually succeeds at doing this.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> In the end, everything comes down to a question of benefits vs. costs.
> There is a potential cost involved in using a leading underscore. It
> may be small, but it is there. What is the benefit?
>
It makes the person who wrote it feel like an expert.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> You *should* be reading programs that were meant to be read, and not
> just random code for which you happen to have the sources.
I'm trying to imagine code that is not meant to be read... Apart from computer-generated code, I simply can't do it. Do you write
much write-only code?
> I think that
> Dietmar's point was that this particular code wasn't written with a
> pedagogic purpose in mind, and wasn't appropriate for that purpose.
Well, the Earth's fossil record wasn't created with any pedagogic purpose in mind, either, but it doesn't mean we can't learn from
it. :)
I'm still working on the concept that there is some code that is pedagogic and meant to be read, and other code that you can't learn
anything from and therefore you better not even try to read it.
Dinkumware's VC6 implementation does not fall into the latter category. It would just have been easier if they'd used more
descriptive identifiers.
> Also, although I started learning programming by reading other's code,
> most of what I now know comes from reading books and articles, and not
> code.
That's true for me, too. It's the neophyte who needs to read real-world code (which may not be pedagogic at all), and while I can
make some sense of Xstring.h, I doubt a newbie could.
> It's called artistic control. It's a recognized principle, even if it
> has been subverted for commercial ends. And I've rarely if ever seen
> software that didn't assert it: the GPL is perhaps the most flagrant
> example, but almost all software authors exerce some sort of artistic
> control over what you do with their "creation".
But it doesn't stop the artist's clients from disagreeing with their pocketbooks.
Mark Wilden
> Mark Wilden wrote:
> >
> I see. So you no longer claim that "If my unit tests are not sufficient
> to ferret the macro-induced change of one piece of code to a completely
> different piece of code because I used a leading underscore in a member
> name, then I should just be taken out an shot."
I do so claim.
You're trying to make a point, Pete, but I don't understand it. Could you be more clear?
Mark Wilden
>
> In the end, everything comes down to a question of benefits vs. costs.
> There is a potential cost involved in using a leading underscore.
I evaluate the real (as opposed to potential) cost at 0. Therefore, even the slightest benefit tips the scale.
> What is the benefit?
I do really like having member variables look different from other variables. I didn't like a trailing underscore as much. There may
be other benefits, but when there's no cost, it doesn't really matter.
Mark Wilden
> "Mark Wilden" <ma...@pagm.com> writes:
>
> |> That's an even more interesting remark, with which I heartily
> |> disagree, as well. I feel it's my business to look at any code on my
> |> computer I want to.
>
Sorry to be unclear. When I said "look at any code" I meant "look at any source code."
Dietmar Kuehl
Dennis Yelle (denn...@jps.net) wrote:
: The last time I read the GPL there was absolutely no restriction
: on who could read the code.
Correct. Actually, the same applies to my code. However, this does not
mean that you can read the code, write the same code, optionally
modify it slightly, and cover it under a different copyright than the
one present in the code which means that you are producing GPL code or
effectively code available at no cost (depending on whether you are
reading GPLed code or mine; with my code you can choose to keep the
sources private however, only the sources are covered by the copyright
- you don't have this choice with GPLed code). I'm somewhat implying
that this is not exactly what most people want to do...
What triggered my reaction was basically the statement that the STL
code is a great source for the basis of new functions: You just copy
the STL code and modify the tiny bits necessary to turn it into
something new. That is clearly illegal unless the tiny bits are a
major intellectual effort or if the rights provided with the sources
you got allows you to use the code. In the latter case (unless case one
applies) you have, of course, obey the restrictions imposed by the
copyright the sources are covered under. For GPLed code, this means you
are creating GPLed code. For my code, this means you are creating free
code. For other code normally all rights are reserved and my understand
is that you are not allowed to use this code for anything.
You may read the code and later produce new code. However, it the code
resembles the original code closely, I'm pretty sure that you can get
sued for copyright violations - at least if the original was a
non-trivial implementation. Now, you can claim that the STL
implementations are indeed just trivial code and at least partially you
are probably right. Still lots of the stuff contains nifty ideas to
speed up the code and just copying these ideas is a fair candidate of a
copyright violation. Of course, if the resulting code is covered by an
appropriate copyright as is spelled out in the license of the original
code, this is just fine...
--
<mailto:dietma...@yahoo.de> <http://www.dietmar-kuehl.de/~kuehl/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message news:3A4DF621...@acm.org...
> > Mark Wilden wrote:
> > >
> > I see. So you no longer claim that "If my unit tests are not sufficient
> > to ferret the macro-induced change of one piece of code to a completely
> > different piece of code because I used a leading underscore in a member
> > name, then I should just be taken out an shot."
>
> I do so claim.
>
> You're trying to make a point, Pete, but I don't understand it. Could you be more clear?
>
Yes, I've been a bit obscure. Sorry. Well-written test suites typically
execute about 60% of the code under test. If a test suite doesn't test
explicitly for a particular potential problem, then there is no basis
for asserting that that problem will be found by the suite.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> <ka...@gabi-soft.de> wrote in message news:86zoh99...@gabi-soft.de...
> > You *should* be reading programs that were meant to be read, and not
> > just random code for which you happen to have the sources.
> I'm trying to imagine code that is not meant to be read... Apart
> from computer-generated code, I simply can't do it. Do you write
> much write-only code?
Touché. I should have been clearer. There is code written for
pedagogical purposes, which you read to learn new principles. Most
code isn't, however, and you only read it to maintain it. The
requirements for readability are different.
> > I think that
> > Dietmar's point was that this particular code wasn't written with a
> > pedagogic purpose in mind, and wasn't appropriate for that purpose.
> Well, the Earth's fossil record wasn't created with any pedagogic
> purpose in mind, either, but it doesn't mean we can't learn from
> it. :)
True. But I imagine that most archeologists would be quite pleased if
there were an easier "text" available.
> I'm still working on the concept that there is some code that is
> pedagogic and meant to be read, and other code that you can't learn
> anything from and therefore you better not even try to read it.
Your carrying my premise too far. You can probably learn from any
code. (Reading bad code can make it clear what not to do.) If your
goal is to learn something specific, however, just reading random code
is definitely not the best way.
> Dinkumware's VC6 implementation does not fall into the latter
> category. It would just have been easier if they'd used more
> descriptive identifiers.
I've only glanced at Dinkumware's code once or twice. It certainly
wouldn't occur to me to read it (even with more readable names) to
understand the principles behind any of the standard algorithms, nor
how to implement a map, nor for any other particular reason. In fact,
I think Dinkumware's code is particularly bad for this, precisely
because the main author also writes books about the code, and the code
is (or was) designed to be read in conjunction with the text in the
book.
> > Also, although I started learning programming by reading other's
> > code, most of what I now know comes from reading books and
> > articles, and not code.
> That's true for me, too. It's the neophyte who needs to read
> real-world code (which may not be pedagogic at all), and while I can
> make some sense of Xstring.h, I doubt a newbie could.
No. I started learning programming by reading other's code because I
didn't know what books to read. The code I was reading was assembler,
and I was very lucky that some of the first code I read was by some
very good programmers -- programmers who would have been quite at home
with Knuth's literate programming. Never the less, it took me months
to learn things that I could have learned in days with a good book.
I can only think of one case where reading code has a very positive
pedagogic effect: after having read how to write good code, it is
useful to read some bad code, to see why the rules are important.
> > It's called artistic control. It's a recognized principle, even
> > if it has been subverted for commercial ends. And I've rarely if
> > ever seen software that didn't assert it: the GPL is perhaps the
> > most flagrant example, but almost all software authors exerce some
> > sort of artistic control over what you do with their "creation".
> But it doesn't stop the artist's clients from disagreeing with their
> pocketbooks.
Agreed. You generally don't have to use software if you don't agree
with the license, although commercial considerations often intervene.
(Most shops seem to want CV's in MS-Word format, so whether I agree
with the MS-Word license or not...)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Dean Roddey
base. I used _Xyz/_Xyz() for protected data and methods, and __Xyz/__Xyz()
for private data and methods. I really liked this scheme and I think it made
a lot of problems go away, such as for instance, what to name a protected
virtual method that provides the derived implementation after a public
method provides pre/post checking. Just name it the same but with an
underscore. And similar thing, such as you can name the ctor paramater the
same as the member, since the member is disambiguated by the __, blah blah
blah.
But, since its technically illegal, I just say fark it and dealt with it. It
was a huge PITA, because its probably 700+K lines of code, and every single
protected or private data member in the whole thing had to be touched. And
if that caused name clashes, I had to deal with that. Talk about 2 weeks of
mind numbing mods...
I ended up with using m_Xyz for data members, and no leading stuff for any
methods. Static class members are s_Xyz. All file scoped stuff was moved
into namespaces. I didn't do anonymous namespaces for now, since the stupid
VC++ debugger doesn't seem to want to let you see anything in an anonymous
namespace. So, for now, I named the namespace after the file its in, and
I'll go back and fix them for anon ns when that is better supported.
So I've put this whole mess behind me and I can move forward again.
Personally, I liked it better the other way, but say larvi, what can you do?
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
dro...@charmedquark.com
http://www.charmedquark.com
"It takes two buttocks to make friction"
- African Proverb
"Mark Wilden" <ma...@pagm.com> wrote in message
news:t56udej...@news.supernews.com...
James Kanze
> > It's called artistic control. It's a recognized principle, even
> > if it has been subverted for commercial ends. And I've rarely if
> > ever seen software that didn't assert it: the GPL is perhaps the
> > most flagrant example, but almost all software authors exerce some
> > sort of artistic control over what you do with their "creation".
> The last time I read the GPL there was absolutely no restriction on
> who could read the code. In fact, my interpretation of the GPL is
> that its intent is to cause more source code to be available for
> everyone to read and learn from. I don't know if it actually
> succeeds at doing this.
Nobody said you couldn't read it. GPL makes a lot of restrictions
with regards to what you can do with the code. The restrictions are
legal because copyright enforces the concept of "artistic control",
since it is normally concerned with artistic creations. If Dietmar
wants to say that you can use his code, but you don't have a right to
read it (he doesn't), then he is perfectly within his rights, and it
is no more outrageous than saying that if I use your code, I have to
make my code publicly available (GPL), or that I can only modify the
code if my name happens to be Donald Knuth (TeX). (I think the last
restriction is actually justifiable, since he also gives you the right
to modify it if you change the name of the program. This is really
the most basic meaning of artistic control: if you are using Donald
Knuth's TeX, then you are using Donald Knuth's creation, and not
Donald Knuth's creation modified in some subtle way by James Kanze.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Francis Glassborow
<James...@dresdner-bank.com> writes
>Touché. I should have been clearer. There is code written for
>pedagogical purposes, which you read to learn new principles.
Unfortunately most code in books is written for this purpose and many do
not seem to realise that and blindly copy it and the coding style.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
> If a test suite doesn't test
> explicitly for a particular potential problem, then there is no basis
> for asserting that that problem will be found by the suite.
Surely there's at least a basis for asserting that 60% of the problems will be
found? :)
My point was that I felt a good test suite would indeed ferret out problems
where someone defined a macro that had the same name as my member variable.
Frankly, I'd be rather astonished if the Mother of All Tests (the compiler)
didn't catch it.
Mark Wilden
news:3A544FB8...@dresdner-bank.com...
>
> There is code written for
> pedagogical purposes, which you read to learn new principles. Most
> code isn't, however, and you only read it to maintain it. The
> requirements for readability are different.
As someone else mentioned, there are other reasons for reading code than for
pedagogical purposes. I have no need to maintain the VC++ STL headers, but if
they followed standard coding conventions, it would make it easier to understand
what was going on when there are bugs in my own code.
> If your
> goal is to learn something specific, however, just reading random code
> is definitely not the best way.
But we're not talking about just randomly wading into some code and starting to
read. :)
> I've only glanced at Dinkumware's code once or twice. It certainly
> wouldn't occur to me to read it (even with more readable names) to
> understand the principles behind any of the standard algorithms, nor
> how to implement a map
I agree with your first point. But I can't think of a _better_ way to learn how
to implement a map than to read and understand a real-world implementation of
map.
>, nor for any other particular reason.
That's pretty categorical. :) I think most people's needs would be for
debugging.
> In fact,
> I think Dinkumware's code is particularly bad for this, precisely
> because the main author also writes books about the code, and the code
> is (or was) designed to be read in conjunction with the text in the
> book.
I didn't realize this. I find it difficult to believe that the code was designed
to be read in conjunction with anything.
> I can only think of one case where reading code has a very positive
> pedagogic effect: after having read how to write good code, it is
> useful to read some bad code, to see why the rules are important.
Occasionally, I'll pick up a technique I've never used before. C++ is a complex
language with more than one way to skin a particular cat.
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message
> news:3A53CF1C...@acm.org...
>
> > If a test suite doesn't test
> > explicitly for a particular potential problem, then there is no basis
> > for asserting that that problem will be found by the suite.
>
> Surely there's at least a basis for asserting that 60% of the problems will be
> found? :)
>
> My point was that I felt a good test suite would indeed ferret out problems
> where someone defined a macro that had the same name as my member variable.
If your definition of a "good" test suite is that it catches this
problem, then you're right. Otherwise, there's a substantial chance that
a good test suite won't catch this.
> Frankly, I'd be rather astonished if the Mother of All Tests (the compiler)
> didn't catch it.
>
void x();
void y();
#define x y
class C
{
public:
f() { x(); }
};
The compiler will not catch this.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
> Mark Wilden wrote:
>
> > Frankly, I'd be rather astonished if the Mother of All Tests (the compiler)
> > didn't catch it.
> >
>
> void x();
> void y();
>
> #define x y
>
> class C
> {
> public:
> f() { x(); }
> };
>
> The compiler will not catch this.
But my statement remains true. I _am_ astonished--in this case that anyone would
write code so dumb. I would be equally astonished if calling a completely
different function than was intended would not be detected in unit test.
The problem with standards-oriented thinking (as useful as it is in other
respects) is that it confuses the possible with the probable. Yes, it's
_possible_ to cause runtime errors with macros that have the same name as
members (as I've already said). I would say, however, that it's _improbable_ to
the point of extinction.
After all, we've been discussing leading underscores. But when it comes to
macros, no member variable is safe, leading underscore or no.
In any event, I do think this is a non-issue. Using leading underscores for
member variables
1) Is perfectly legal
2) Is supported by the compiler I have been and will be using
3) Makes my code easier for me to read
4) Seems "safe," judging by the utter lack of horror stories
Yup, it's _possible_ I'll run into a problem. You'll be the first to know when I
do. :)
Pete Becker
>
> I have no need to maintain the VC++ STL headers, but if
> they followed standard coding conventions, it would make it easier to understand
> what was going on when there are bugs in my own code.
>
They do follow standard coding conventions. The standard happens to be
different from yours.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Pete Becker
>
> "Pete Becker" <peteb...@acm.org> wrote in message
> news:3A54C25D...@acm.org...
> > Mark Wilden wrote:
> >
> > > Frankly, I'd be rather astonished if the Mother of All Tests (the
compiler)
> > > didn't catch it.
> > >
> >
> > void x();
> > void y();
> >
> > #define x y
> >
> > class C
> > {
> > public:
> > f() { x(); }
> > };
> >
> > The compiler will not catch this.
>
> But my statement remains true. I _am_ astonished--in this case that anyone
would
> write code so dumb.
Okay, end of discussion. You've just labeled your coding practice of
using names that are reserved to the implementaion as dumb.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
>
> Okay, end of discussion. You've just labeled your coding practice of
> using names that are reserved to the implementaion as dumb.
Member variable names beginning with underscores are not reserved to the
implementation, in my understanding.
Mark Wilden
> Mark Wilden wrote:
> >
> > I have no need to maintain the VC++ STL headers, but if
> > they followed standard coding conventions, it would make it easier to
understand
> > what was going on when there are bugs in my own code.
>
> They do follow standard coding conventions. The standard happens to be
> different from yours.
The standard I'm talking about says that identifiers should have meaningful
names. I didn't realize that was such an idiosyncratic concept. I'll call it the
Wilden Standard from now on, to avoid confusion.
Seriously, please give me the source of the "standard" for code like this:
for (_Ns = 0; 0 < _N; )
if (gptr() != 0 && 0 < (_M = egptr() - gptr()))
{if (_N < _M)
_M = _N;
_Tr::copy(_S, gptr(), _M);
_S += _M, _Ns += _M, _N -= _M, gbump(_M); }
else if (_Tr::eq_int_type(_Tr::eof(), _C = uflow()))
break;
else
*_S++ = _Tr::to_char_type(_C), ++_Ns, --_N;
I mean, forget about whether I should be able to read this or not (there are
some who feel I shouldn't). How could anyone work on code like this??
Dietmar Kuehl
Mark Wilden (ma...@pagm.com) wrote:
: for (_Ns = 0; 0 < _N; )
: if (gptr() != 0 && 0 < (_M = egptr() - gptr()))
: {if (_N < _M)
: _M = _N;
: _Tr::copy(_S, gptr(), _M);
: _S += _M, _Ns += _M, _N -= _M, gbump(_M); }
: else if (_Tr::eq_int_type(_Tr::eof(), _C = uflow()))
: break;
: else
: *_S++ = _Tr::to_char_type(_C), ++_Ns, --_N;
: I mean, forget about whether I should be able to read this or not (there are
: some who feel I shouldn't). How could anyone work on code like this??
I can't follow your complaint: The code is pretty much readable to me
and I'm not the author of this code. There are some nits like I would
use two characters for indentation, a newline after an open brace, and
I'm no fan of concatenating expressions using the comma operator to
save blocks but this is personal preference IMO. The code is still
readable enough to tell that it is from 'std::basic_streambuf',
probably part of the default implementation of 'xsgetn()'.
Actually, most of the complexity in this code stems from a very
different source than code layout: This stuff isn't easy to follow if
you are not used to! For example, if you are not fluent with the use of
character traits ('_Tr' is the character traits template argument to
the stream buffer class; it is used to deal with character specific
features like eg. the representation of "EOF", conversion between the
"char_type" and an "int_type" need to hold the additional "EOF" value,
and to shuffle characters around) you would have already a relatively
hard time - and I would bet that most people haven't used the character
traits type yet, at least not a lot. The next stumbling block are the
stream buffer functions: If you have no idea how the "get area" works,
you can't really follow this code. What is a stylistic problem (IMO) is
the use of the comma operator. The remainder is just a reasonable
implementation of the function! That is, off-hand I can't see any
improvement (well, except that the test whether 'gptr() != 0' is not
necessary: I haven't checked but I'm pretty sure that if 'gptr() == 0'
then 'egptr()' also has to be '0' and thus the second part of the
expression is sufficient...).
OK, I have implemented that stuff myself and thus I have an advantage
reading this code. However, this code is written to be readable by
people who have implemented this code! It is not tutorial code. It is
not intended to be used as a basis for someone else's code. ... and it
is supposed to be correct such that nobody has to debug into this
code. It has to be readable for library implementers and, although I
haven't implemented this particular code, I can easily read it.
--
<mailto:dietma...@yahoo.de> <http://www.dietmar-kuehl.de/~kuehl/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Chris Mullins
>
> Member variable names beginning with underscores are not reserved to the
> implementation, in my understanding.
>
I believe this has already been pointed out, but:
17.4.3.1.2 from the ANSI Spec says:
Each name that contains a double underscore (_ _) or begins with
an underscore followed by an uppercase letter (2.11) is reserved
to the implementation for any use.
Each name that begins with an underscore is reserved to the
implementation for use as a name in the global namespace.
This sure seems to indicate that using leading "_" for variable names is
a bad idea.
--
Chris Mullins
Pete Becker
>
> I mean, forget about whether I should be able to read this or not (there are
> some who feel I shouldn't). How could anyone work on code like this??
>
By looking at the definitions of the names, and not just their uses.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contributing Editor, C/C++ Users Journal (http://www.cuj.com)
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> > I've only glanced at Dinkumware's code once or twice. It certainly
> > wouldn't occur to me to read it (even with more readable names) to
> > understand the principles behind any of the standard algorithms, nor
> > how to implement a map
> I agree with your first point. But I can't think of a _better_ way
> to learn how to implement a map than to read and understand a
> real-world implementation of map.
And I can't think of a worse way. Dinkumware's implementation of a
map is a specific solution, designed to meet a number of external
constraints, not all of which have to do with maps. It is also
uncommented; the authors were certainly aware of the various
invariants involved when the wrote the code, but they didn't document
them in the code. Probably because they would be evident to anyone
who already knew how to write a map, but this means that if you don't
already know how to write a map, then the Dinkumware code will *not*
teach you.
About the only way such code could be useful in a pedagogical sense is
if you read about the basic algorithm, then implement it yourself, and
then compare your implementation with theirs, to see where they
differ. Once you fully understand the basic principles, you probably
can pick up minor tips by reading code written by experts.
In Plauger's books about the standard library, he doesn't just publish
code. He also very clearly explains, in very readable English, the
various constraints, the alternatives, and the motivation for his
choices. The published code is only the conclusion, and without the
preceding comments, would be totally uncomprehensible (unless, of
course, you already knew what he explains in the preceding text).
> >, nor for any other particular reason.
> That's pretty categorical. :) I think most people's needs would be
> for debugging.
I expect my tools to work. I'm paid to develop applications, not to
debug external tools.
> > In fact, I think Dinkumware's code is particularly bad for this,
> > precisely because the main author also writes books about the
> > code, and the code is (or was) designed to be read in conjunction
> > with the text in the book.
> I didn't realize this. I find it difficult to believe that the code
> was designed to be read in conjunction with anything.
I've read Plauger's books. When you've read the preceding text, the
code is exceptionally understandable.
> > I can only think of one case where reading code has a very
> > positive pedagogic effect: after having read how to write good
> > code, it is useful to read some bad code, to see why the rules are
> > important.
> Occasionally, I'll pick up a technique I've never used before. C++
> is a complex language with more than one way to skin a particular
> cat.
That's a lot weaker assertion than I thought you were making before.
If you fully understand the basics, then yes, you will occasionally
pick up a trick or two. Nothing essential, but why not? However, if
you fully understand the basics, you should have no problem reading
the Dinkumware code, either. (Admittedly, a bit of documentation
concerning the naming conventions would help, but in practice, the use
makes it pretty clear anyway.)
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
James Kanze
> In article <3A544FB8...@dresdner-bank.com>, James Kanze
> <James...@dresdner-bank.com> writes
> >Touché. I should have been clearer. There is code written for
> >pedagogical purposes, which you read to learn new principles.
> Unfortunately most code in books is written for this purpose and
> many do not seem to realise that and blindly copy it and the coding
> style.
Right. It's interesting in this regard to consider the evolution of
Knuth's literate programming. In many cases, the full formatting
information is dropped, because it is only noise when you are reading
the sources (and not the printed article it generates), and what is
left is only the elements which affect the source itself: reordering
to conform to human logic instead of language constraints, and a
default of comments, with special bracketing for the actual code
instead of the reverse, as in the actual programming language. So you
use the full cweb when preparing articles for publication, but a
simplified version (called noweb, I think) for actual production code.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Mark Wilden
> Mark Wilden wrote:
>
> > > I've only glanced at Dinkumware's code once or twice. It certainly
> > > wouldn't occur to me to read it (even with more readable names) to
> > > understand the principles behind any of the standard algorithms, nor
> > > how to implement a map
>
> > I agree with your first point. But I can't think of a _better_ way
> > to learn how to implement a map than to read and understand a
> > real-world implementation of map.
>
> And I can't think of a worse way.
C'mon, James. There are plenty of _worse_ ways. Sitting a thousand monkeys
down
in a room with a thousand typewriters has got to rank up there, for example.
> Dinkumware's implementation of a
> map is a specific solution, designed to meet a number of external
> constraints, not all of which have to do with maps. It is also
> uncommented; the authors were certainly aware of the various
> invariants involved when the wrote the code, but they didn't document
> them in the code. Probably because they would be evident to anyone
> who already knew how to write a map, but this means that if you don't
> already know how to write a map, then the Dinkumware code will *not*
> teach you.
Of course, this is my whole point. But in many other areas, if I want to learn
how to do something, I can indeed read code to find out. I already have
learned
from Dinkumware's STL, but it wouldn't have been hard to write that code so I
could've learned more. That's what gripes people about that code, I think. It
would have been _easy_ to make it readable, so why not?
I'm feeling like Alice in Wonderland, here. Black is white and white is black.
Code shouldn't be written to be read because I have no right to read it. It's
OK
to use single-character identifiers. It doesn't matter if code will not
compile
cleanly under its target environment's maximum warning setting (doesn't anyone
use lint anymore?). It's OK to publish code that appears to be formatted with
a
Weed Whacker. Everything I know is wrong. :)
> About the only way such code could be useful in a pedagogical sense is
> if you read about the basic algorithm, then implement it yourself, and
> then compare your implementation with theirs, to see where they
> differ. Once you fully understand the basic principles, you probably
> can pick up minor tips by reading code written by experts.
Each to his own, of course, but if I were to implement std::map, I'd make sure
I
understood Josuttis, then I'd dive into the best source for map I could find.
Only after that would I sit down and start coding.
> In Plauger's books
I'm only aware of one: the one with "Draft" inserted in the title (which I
just
gave away, in fact). Did he update it? At any rate, it may have been a great
book for understanding the code, but I think Josuttis is much better for
actually using the standard library (probably because it's more tutorial in
aspect).
> about the standard library, he doesn't just publish
> code. He also very clearly explains, in very readable English, the
> various constraints, the alternatives, and the motivation for his
> choices. The published code is only the conclusion, and without the
> preceding comments, would be totally uncomprehensible (unless, of
> course, you already knew what he explains in the preceding text).
I wonder how my customers would feel if they licensed some code from me, but
when they came to find it was unreadable, I told them they had to buy my book?
:)
> > That's pretty categorical. :) I think most people's needs would be
> > for debugging.
>
> I expect my tools to work. I'm paid to develop applications, not to
> debug external tools.
I already made the point that it can be helpful to step into library code to
find your own bugs.
> > Occasionally, I'll pick up a technique I've never used before. C++
> > is a complex language with more than one way to skin a particular
> > cat.
>
> That's a lot weaker assertion than I thought you were making before.
It's a separate assertion. :) There is more than one reason why a given
programmer might want to read a given piece of code. To recap, some of them
are:
to help debugging, to learn about the broad area covered, to learn about micro
techniques, to get better at reading code, or simply for fun. :)
> If you fully understand the basics, then yes, you will occasionally
> pick up a trick or two. Nothing essential, but why not? However, if
> you fully understand the basics, you should have no problem reading
> the Dinkumware code, either. (Admittedly, a bit of documentation
> concerning the naming conventions would help, but in practice, the use
> makes it pretty clear anyway.)
Let me just ask you this: Is your code written like that? Why not?
Francis Glassborow
<ma...@pagm.com> writes
>I mean, forget about whether I should be able to read this or not (there are
>some who feel I shouldn't). How could anyone work on code like this??
What makes you think they do? Code shrowders do much worse things to
human readable code.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
news:MPG.14bead96a...@news1.alterdial.uu.net...
> Mark Wilden says...
> >
> > Member variable names beginning with underscores are not reserved to the
> > implementation, in my understanding.
> >
>
> Each name that contains a double underscore (_ _) or begins with
> an underscore followed by an uppercase letter (2.11) is reserved
> to the implementation for any use.
>
> Each name that begins with an underscore is reserved to the
> implementation for use as a name in the global namespace.
Member variables are not in the global namespace.
> This sure seems to indicate that using leading "_" for variable names is
> a bad idea.
It may be a bad idea or it may not, but it has nothing to do with legality.
Francis Glassborow
<ma...@pagm.com> writes
>I wonder how my customers would feel if they licensed some code from me, but
>when they came to find it was unreadable, I told them they had to buy my book?
>:)
Well that rather depends on why you licensed it to them. Currently those
implementing libraries of templates have a problem in that they have to
provide you the source. In earlier days (actually even now) source code
was often provided in shrouded form if the customer had to have the
code. An excellent example, IIRC, is the general form of PCLint++ which
is provided at much higher cost in source code form so that it can be
compiled for other platforms. The code certainly used to be heavily
shrouded -- I do not know if it still is.
Actually providing code 'free' but you have to buy the book for an
explanation is quite common, and, I believe, that is entirely
acceptable.
Whilst I have strong reservations about patents and copyright applied to
some aspects of software, that does not mean that we should not respect
the rights of others. Using code and learning from it are distinct
activities, each with a market value.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
mst
> You may read the code and later produce new code. However, it the code
> resembles the original code closely, I'm pretty sure that you can get
> sued for copyright violations - at least if the original was a
> non-trivial implementation. Now, you can claim that the STL
> implementations are indeed just trivial code and at least partially you
> are probably right. Still lots of the stuff contains nifty ideas to
> speed up the code and just copying these ideas is a fair candidate of a
> copyright violation. Of course, if the resulting code is covered by an
> appropriate copyright as is spelled out in the license of the original
> code, this is just fine...
Sorry, IANAL, but I don't think you can copyright an idea: as far as I
am not copying your code verbatim the idea can not be protected by
copyright.
If you want to make an *idea* your IP, you must
- patent it
or
- restrict the use by making the user to agree to a specific license
agreement which restricts this use
Anyway, this is not going to work in most countries, is hardly
enforceable, and seems to have nothing to do with copyright violation
(patent/license agreement violation).
Morally, I disagree that restricting the use of your ideas can be
compared to "artistic license": art and science as we know it would
never exist if everyone would patent their ideas instead of publishing
them.
Copying code as is, is of course another issue - it is restricted by
copyright, and is naturally related to artists rights to his creation:
copying Mane using a machine and reselling is not OK, but trying to
patent the *idea* of expressionism?
Take care,
MST
Michiel Salters
> Hi,
> Harald Luessen (harald....@gmx.de) wrote:
> : If the _T is the important part or even the preceding underscore
> : why don't STL developers use readable names like _Tcount or _Tsize ?
> In addition, nobody is supposed to read this code anyway: It is part of
> the implementation and not your business to look at. Using anything
> from these headers for a different purpose than the standard C++
> library they ship with would violate copyrights anyway. So, what is
> your problem with these names in the first place?
One of the objections might be those modern IDEs which show you the/a
function declaration when you start typing the argument list of a function
call. It would be useful to see that for_each takes two input iterators and
a function object, instead of two _I's and an _F.
Since this feature is more intended for novices I fear they will judge the
quality of the Standard Library by this implementation. (aka consider it
"undocumented".)
--
Michiel Salters
Michiel...@cmg.nl
sal...@lucent.com
James Kanze
> "James Kanze" <James...@dresdner-bank.com> wrote in message
> news:3A55A40F...@dresdner-bank.com...
> > Mark Wilden wrote:
> > > > I've only glanced at Dinkumware's code once or twice. It
> > > > certainly wouldn't occur to me to read it (even with more
> > > > readable names) to understand the principles behind any of the
> > > > standard algorithms, nor how to implement a map
> > > I agree with your first point. But I can't think of a _better_
> > > way to learn how to implement a map than to read and understand
> > > a real-world implementation of map.
> > And I can't think of a worse way.
> C'mon, James. There are plenty of _worse_ ways. Sitting a thousand
> monkeys down in a room with a thousand typewriters has got to rank
> up there, for example.
Admitted, reading Dinkumware's implementation is probably better than
just reading some random implementation:-). But how much better? A
random implementation may actually get some of the border cases wrong
that the Dinkumware's implementation correctly handles. But without
the comments, etc., how do you know what those cases are, and what
part of the code is there to handle them (or more likely, that a
certain form of implementation was preferred over alternatives because
it handled them correctly implicitly)?
> > Dinkumware's implementation of a map is a specific solution,
> > designed to meet a number of external constraints, not all of
> > which have to do with maps. It is also uncommented; the authors
> > were certainly aware of the various invariants involved when the
> > wrote the code, but they didn't document them in the code.
> > Probably because they would be evident to anyone who already knew
> > how to write a map, but this means that if you don't already know
> > how to write a map, then the Dinkumware code will *not* teach you.
> Of course, this is my whole point. But in many other areas, if I
> want to learn how to do something, I can indeed read code to find
> out. I already have learned from Dinkumware's STL, but it wouldn't
> have been hard to write that code so I could've learned more. That's
> what gripes people about that code, I think. It would have been
> _easy_ to make it readable, so why not?
As Dietmar has already pointed out, it IS readable. At least to the
people who count: the people who have to maintain it.
> I'm feeling like Alice in Wonderland, here. Black is white and white
> is black. Code shouldn't be written to be read because I have no
> right to read it. It's OK to use single-character identifiers. It
> doesn't matter if code will not compile cleanly under its target
> environment's maximum warning setting (doesn't anyone use lint
> anymore?). It's OK to publish code that appears to be formatted with
> a Weed Whacker. Everything I know is wrong. :)
No. Code should be written to be readable to the people who should
read it. Dinkumware's code meets this standard, since both Plauger
and Becker can read it. Whether single-character identifiers are
acceptable depends on context. I use them for local variables and
in restricted cases for template parameters, and for nothing else.
But that is MY code convention; if Dinkumware uses a different
convention, it isn't necessarily wrong. In the end, the question is
whether the people who have to maintain the code can read it.
The same holds for formatting. And nobody has said anything in favor
of headers generating warnings.
> > About the only way such code could be useful in a pedagogical
> > sense is if you read about the basic algorithm, then implement it
> > yourself, and then compare your implementation with theirs, to see
> > where they differ. Once you fully understand the basic
> > principles, you probably can pick up minor tips by reading code
> > written by experts.
> Each to his own, of course, but if I were to implement std::map, I'd
> make sure I understood Josuttis, then I'd dive into the best source
> for map I could find. Only after that would I sit down and start
> coding.
But what do you mean by "the best source for map". The "code" I'd
probably look at is that in Sedgewick. Or Wirth, or Knuth. (I don't
consider the fact that the code I'm looking at isn't in C++ a
particular problem.)
> > In Plauger's books
> I'm only aware of one: the one with "Draft" inserted in the title
> (which I just gave away, in fact). Did he update it?
I have heard about an update, written in collaboration with Stepanov,
but I don't know the current status. Plauger's book on the C standard
library is THE reference for implementors. And despite its date, if I
were to teach programming to beginners, I'd design my course around
"Programming Tools in Pascal", regardless of the target language. (I
did this when I taught C, 15 years ago, with much success.)
> At any rate, it
> may have been a great book for understanding the code, but I think
> Josuttis is much better for actually using the standard library
> (probably because it's more tutorial in aspect).
> > about the standard library, he doesn't just publish code. He also
> > very clearly explains, in very readable English, the various
> > constraints, the alternatives, and the motivation for his choices.
> > The published code is only the conclusion, and without the
> > preceding comments, would be totally uncomprehensible (unless, of
> > course, you already knew what he explains in the preceding text).
> I wonder how my customers would feel if they licensed some code from
> me, but when they came to find it was unreadable, I told them they
> had to buy my book? :)
Most of the code I license is unreadable. Most of the code I license
is in binary format. And if I want to read it, they tell me that I
have to buy another license.
Even when I have access to the sources, the code isn't necessarily
"readable". I find the Dinkumware library more readable than the
sources to g++, for example, probably because I know exactly what each
function is supposed to do. (It's in the standard.)
> > > That's pretty categorical. :) I think most people's needs would
> > > be for debugging.
> > I expect my tools to work. I'm paid to develop applications, not
> > to debug external tools.
> I already made the point that it can be helpful to step into library
> code to find your own bugs.
As I said, I'm paid to develop applications. I've never found a case
where I've wanted to step into anything. (I think I've used a
debugger twice in fifteen years, and both times, it was a bug in the
compiler.)
> > > Occasionally, I'll pick up a technique I've never used
> > > before. C++ is a complex language with more than one way to skin
> > > a particular cat.
> > That's a lot weaker assertion than I thought you were making before.
> It's a separate assertion. :) There is more than one reason why a
> given programmer might want to read a given piece of code. To recap,
> some of them are: to help debugging, to learn about the broad area
> covered, to learn about micro techniques, to get better at reading
> code, or simply for fun. :)
> > If you fully understand the basics, then yes, you will
> > occasionally pick up a trick or two. Nothing essential, but why
> > not? However, if you fully understand the basics, you should have
> > no problem reading the Dinkumware code, either. (Admittedly, a
> > bit of documentation concerning the naming conventions would help,
> > but in practice, the use makes it pretty clear anyway.)
> Let me just ask you this: Is your code written like that? Why not?
Because the companies I work for have different coding conventions.
In my own work (for fun), I use different conventions, because it
isn't professional code, and one of the goals is that I might some day
publish it, and that it can be used to show others some of my ideas.
Still, the only fundamental difference is that my header files contain
a detailed specification of the classes and functions. Because I'm
not writing a standard library, you can't get the detailed
specification from the standard, and that seemed like the most
convenient place to put it.
In the end: it is just a convention. And the quality of the
convention can only be measured against the goals it attempts to
meet. The ability of a casual reader to be able to browse the code is
not one of the goals, and that is apparently what is bothering you.
To which the only answer is: how did you acquire the code? Was it
sold as a source to be browsed? Or is it part of the implementation
of a compiler, meant to be used, but not to be looked at by you? In
the first case, you have a justifiable complain. In the second, the
fact that you have trouble reading it is not a valid complaint.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Francis Glassborow
<sal...@lucent.com> writes
>One of the objections might be those modern IDEs which show you the/a
>function declaration when you start typing the argument list of a function
>call. It would be useful to see that for_each takes two input iterators and
>a function object, instead of two _I's and an _F.
But the names of parameters in function declarations have their own
scope and have nothing to do with the names used in the complete
definitions. I would be quite happy to encourage descriptive names in
pure declarations, but definitions are the domain of implementors, and
names there should be what they find useful.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Mark Wilden
news:rTYvIRBw...@ntlworld.com...
> In article <t59u8u4...@news.supernews.com>, Mark Wilden
> <ma...@pagm.com> writes
> >I mean, forget about whether I should be able to read this or not (there are
> >some who feel I shouldn't). How could anyone work on code like this??
>
> What makes you think they do? Code shrowders do much worse things to
> human readable code.
It was my understanding that the Dinkumware code was not shrouded. Do you know
differently?
Mark Wilden
>
> But the names of parameters in function declarations have their own
> scope and have nothing to do with the names used in the complete
> definitions. I would be quite happy to encourage descriptive names in
> pure declarations, but definitions are the domain of implementors, and
> names there should be what they find useful.
Isn't it a little weird to suggest that there are groups of programmers who
_don't_ find descriptive names useful? (I really can't believe we're arguing
about this!:)
In the code under discussion, the declarations are the definitions, so Michiel's
point is valid.
Mark Wilden
>
> As Dietmar has already pointed out, it IS readable. At least to the
> people who count: the people who have to maintain it.
So if I write code like that, and my boss notices the numerous deviations from
commonly-accepted style guidelines, I'll just tell him that it's fine, because
I'm the only one who _has_ to read it.
> In the end, the question is
> whether the people who have to maintain the code can read it.
This works in the present tense, but not the future. The reason why meaningful
identifier names, consistent formatting, and at least some use of white space
are parts of (what I used to think was) an almost universally accepted style.
They cost nothing, and make code easier to read for _everyone_--including the
maintainer you just hired yesterday.
I find it highly ironic to see the name of the coauthor of "The Elements of
Programming Style" at the bottom of those headers.
> The same holds for formatting. And nobody has said anything in favor
> of headers generating warnings.
I don't get your point. Is it good or bad for standard library headers to
generate compiler warnings?
> > Each to his own, of course, but if I were to implement std::map, I'd
> > make sure I understood Josuttis, then I'd dive into the best source
> > for map I could find. Only after that would I sit down and start
> > coding.
>
> But what do you mean by "the best source for map". The "code" I'd
> probably look at is that in Sedgewick. Or Wirth, or Knuth. (I don't
> consider the fact that the code I'm looking at isn't in C++ a
> particular problem.)
Well, I just like reading code to understand things, sometimes. After all, no
matter what Sedgewick, Knuth, or Wirth say, Dinkumware's code is real-world. It
works. That can't always be said of "pedagogical" code in books.
> And despite its date, if I
> were to teach programming to beginners, I'd design my course around
> "Programming Tools in Pascal", regardless of the target language. (I
> did this when I taught C, 15 years ago, with much success.)
Especially when you realize that that book is all about converting Pascal to C.
:)
"Programming Tools in Pascal" and "Algorithms + Data Structures = Programs" were
the two most important books in my early education.
> > I already made the point that it can be helpful to step into library
> > code to find your own bugs.
>
> As I said, I'm paid to develop applications. I've never found a case
> where I've wanted to step into anything. (I think I've used a
> debugger twice in fifteen years, and both times, it was a bug in the
> compiler.)
Most of us use debuggers, though, James. :) If you've found a way to program
without ever needing to examine the values of variables in someone else's code,
that's great. But I don't think your experience is universally applicable.
> In the end: it is just a convention.
I can't agree. Using meaningful names for variables (allowing for idioms like i
and j) is not just a convention where I come from.
Mark Wilden
>
>Currently those
> implementing libraries of templates have a problem in that they have to
> provide you the source.
_All_ libraries have to provide _some_ source.
> In earlier days (actually even now) source code
> was often provided in shrouded form if the customer had to have the
> code. An excellent example, IIRC, is the general form of PCLint++ which
> is provided at much higher cost in source code form so that it can be
> compiled for other platforms. The code certainly used to be heavily
> shrouded -- I do not know if it still is.
Yup. It's called FlexeLint, and it's still shrouded.
> Actually providing code 'free' but you have to buy the book for an
> explanation is quite common, and, I believe, that is entirely
> acceptable.
Dinkumware does not provide its code 'free'.
Mark Wilden
news:t5k0voj...@news.supernews.com...
>
> Dinkumware's code is real-world. It works.
I just wanted to emphasize this. I criticize the code for its formatting and
other style issues. However, it works fine, and that's the most important thing.
AllanW
> Suppose the library headers used nice readable names like
> "size" or "count". Since those names are in the
> programmer's namespace, a valid user program can define a
> macro "size" or "count" before including the headers. The
> valid C++ program won't compile or run according to the
> requirements of the standard, meaning the implementation
> is non-conforming.
Won't this be an issue anyway, because of documented class
member names?
#define size 1000
#define count (size/100)
#define cout count
#define endl bendel
#include <iostream>
#include <vector>
// ...
#undef size
#undef count
#undef cout
#undef endl
void f(std::vector<int> &v) {
std::cout << "Size is " << v.size()
<< " and count is " << v.count()
<< std::endl;
}
Will this do anything useful?
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
AllanW
> Using leading underscores for member variables
>
> 1) Is perfectly legal
> 2) Is supported by the compiler I have been and will be using
> 3) Makes my code easier for me to read
> 4) Seems "safe," judging by the utter lack of horror stories
In the newsgroup for encryption, occasionally someone posts
an encrypted message and challenges anyone reading the group
to try to decrypt it. Almost universally, the response is the
same: Nobody is interested in trying to break the code on a
volunteer basis. The original poster then very often proclaims
his encryption algorithm "unbreakable" based on the utter lack
of anybody to break his code.
Those posters are wrong. And so are you.
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Dennett
>
> "James Kanze" <James...@dresdner-bank.com> wrote in message
> news:3A599156...@dresdner-bank.com...
> >
> > As Dietmar has already pointed out, it IS readable. At least to the
> > people who count: the people who have to maintain it.
>
> So if I write code like that, and my boss notices the numerous deviations from
> commonly-accepted style guidelines, I'll just tell him that it's fine, because
> I'm the only one who _has_ to read it.
<joke>
Your boss will, presumably, prove you wrong by terminating your
contract,
and seeking someone else to maintain (and hence, have to read) your
code.
</joke>
>
> > In the end, the question is
> > whether the people who have to maintain the code can read it.
>
> This works in the present tense, but not the future. The reason why meaningful
> identifier names, consistent formatting, and at least some use of white space
> are parts of (what I used to think was) an almost universally accepted style.
> They cost nothing, and make code easier to read for _everyone_--including the
> maintainer you just hired yesterday.
Maintainers for implementation of the C++ Standard Library are going to
have to be strange creatures anyway. They'll be able to read code in
any given style with a little practice. The code is written such that a
suitable maintainer will be able to read it.
>
> I find it highly ironic to see the name of the coauthor of "The Elements of
> Programming Style" at the bottom of those headers.
>
> > The same holds for formatting. And nobody has said anything in favor
> > of headers generating warnings.
>
> I don't get your point. Is it good or bad for standard library headers to
> generate compiler warnings?
Oh, it's bad. Very bad. :)
-- James Dennett <jden...@acm.org>
AllanW
> My sources are released under very liberal terms. However, my code is
> still my intellectual property and I'm owning them! *Any use* of the
> code not covered by the copyright. For example, taking code from my
> headers, pasting it somewhere else and modifying it *without* putting
> it under my copyright (plus potentially another copyright for the
> changes)
...and then publishing it...?
> is illegal!
Yes it is (with the change I made), and it should be.
> ... and this is already a *very* liberal license!
I haven't read it, but from what you say I'd have to agree.
> You can use, modify, and distribute the code freely but you have to
> maintain the copyright.
More than fair. I don't believe that anything I ever said would
contradict that.
> AllanW (all...@my-deja.com) wrote:
> : First of all, we can care about the names even if we don't
> : want to read the code; they show up in error messages, when
> : we don't use the templates correctly. ("Error: cannot
> : implicitly convert _Ty from const char* to char *const" --
> : but you don't even HAVE a variable named _Ty!)
>
> You should get used to determine the error from these error messages
> because the source is likely to disappear if compilers start to
> support the "export" and the stuff releated to it. No doubt, error
> messages should improve to direct you better to the error but you
> should not count on the source, in particular you should not count
> on the source of the standard library functions.
This is my point exactly. Right now if I don't understand an
error message, I can go to the source and figure out at least
which parameter is being complained about, and find the expression
that uses it. But once libraries are distributed as exported
objects, I'll have fewer alternatives. The problem of meaningless
error messages will get even worse, unless the short names currently
used are also translated into more meaningful names.
> : Secondly, there are reasons to read the code that do not
> : violate copyright rules:
> : * When documentation is unclear, go to the source
>
> If the documentation is unclear, get a better one!
Sound advice.
> : * When you need to do something similar, but not exactly
> : the same as a library function, you can look at how one
> : works and then do something similar
>
> This is illegal use of the code unless such use is explicitly allowed
> in the license covering the library you are using. ... and even if it
> is allowed, you should make sure to put the result under an
appropriate
> copyright! I'm actually pretty certain that for all interesting cases
> you *don't* want to go down this road. In fact, in the early time of
> the FSF they made sure that people working at certain project never
> worked at similar commercial projects to make sure that they indeed
had
> the appropriate rights to create the software under a free license.
I don't think we're talking about the same thing here! I'm not talking
about taking the source to one of your library functions, modifying it,
and then publishing it as my own work without any copyright notice.
> Just taking the code from a standard C++ library implementation and
> adapting it to the needs of some project is certainly illegal unless
> explicitly allowed!
Is this really what you meant to say?
Consider this hypothetical case: I use Microsoft Visual C++, which
includes the Dinkum library. One day I decide that I don't like the
way that std::find_if works. I dig through the header files until I
find it, then copy that one function to my own header file, giving
it the name nonstd::find_if. I modify the copy and then use it in my
project, IN CONJUNCTION with the Dinkum library. I do NOT publish the
source to my program! Nobody ever sees this modified function except
for the programmers that maintain my program.
This isn't wise, this isn't maintainable, yadda yadda -- but this
discussion isn't about the technical merits, so ignore that. I'm
just talking about my right to do it. Nothing in the Microsoft
copyright statement explicitly allows me to make copies of STL
routines and modify the copies. Was this illegal?
If you say yes, I think you're traveling down a road that *you* don't
want to go down. For a moment, let's ignore issues of user education
or violation detection. (Both of these would be BIG problems!) Let's
assume that I knew (or should have known) that this was illegal, and
yet I did it anyway, and somehow you found out about it and decide to
sue me. Would you expect to win your case?
> Personally I don't care too much about this but I
> would probably consider legal steps if I would find code resembling
> my code closely in a competitors implementation, at least if it is
> covered by a stricter copyright than mine (basically, if cannot use my
> own code).
Again, we are NOT talking about distributing your source code,
either with or without modifications.
As for copyrights, in my hypothetical example I wouldn't publish
a modified copyright for the Dinkum library for the same reasons
that I wouldn't publish a copyright for Microsoft. I *WOULD* put
a comment string next to the definition of nonstd::find_if, as
a maintenance note explaining how I managed to create the
function. Also, I'm assuming that there's a copyright string in
the executable, somewhere, if that helps (but I haven't verified
this).
> : * When you already know that you used the template
> : incorrectly, but now you're trying to figure out why
> : it gave the particular incorrect results that it did
> : give
>
> That is what the documentation is for.
Agreed. But sometimes the documentation I'm expected to use
is inferior. I bring my own books sometimes, but not always.
> If the 'export' stuff is
> implemented you cannot go down this road anyway.
Which will make my life slightly more difficult.
> : * If you believe that the code does not conform to the C++
> : standard, or at least your interpretation of it, and want
> : to find out exactly what it DOES do
> : * If you have reason (or paranoia) to suspect Trojan Horses
> : or other intentional problems in your library code -- in
> : other words, if you want to certify it yourself instead of
> : relying on the vendor
>
> Have you done this with the C library? Which implementation if you
have
> done it? Probably not glibc because this one is pretty hard to follow
> and you will have an even harder time to determine whether it does the
> right thing. ... and for most implementations you won't get the
sources
> anyway. So, how is this different to the standard C++ library?
>
> If you have paranoia, you have to get an appropriate license with an
> appropriate guarantee. My license/guarantee combination is appropriate
> (because you are allowed to read the sources - you can do other more
> intrusive things, too, as long as you maintain the copyright). I
cannot
> tell whether other licenses/guarantees are appropriate to investigate
> or exclude Trojan Horses.
I was speaking hypothetically. I'm not saying that I have examined
every line of source code; I'm just saying that reasonable people
might wish to do so.
For what it's worth, I haven't made copies of STL routines and
modified them, either.
> : Your point is that the STL code has priorities that outweigh
> : the need to be readable, and that makes perfect sense. But
> : please don't tell me that the need to be readable isn't a
> : priority AT ALL?!?
>
> I consider my implementation to be pretty readable: The only things I
> consider to be unreadable are the '_CS_' prefixes but I consider them
> as necessary (I'm using a '_CS_' prefix because this is very easily
> changed to something else automatically unlike just capitalizing the
> first character after an underscore: Such things occure eg. in system
> headers, too, and you cannot be sure whether you can change it or
not).
> However, I got used to a lot of appreviation like 'cT' ("character
> type"), 'Tr' ("traits"), 'InIt' ("Input Iterator"), etc.
>
> >From your comments I conclude that obfuscation is actually a good
thing
> to protect you: If you can read my code, you would copy it and this
> would be illegal! For my code there is an easy way out (you just have
> to cover it with my copyright which would not affect anything you ship
> in binary form, only stuff you ship in source form, because my
> copyright is not the LGPL and you cannot be forced to give away the
> source of changed code) but this is very different for other library
> implementations eg. Dinkumware (you don't have the right to use their
> code in your programs in a different from than the normal use as the
> standard C++ library; see their license for details) or libstdc++ (you
> have to provide the sources you changed). Just because you get the
> sources, you cannot use them for anything else than what they are
> intended for. In particular, you cannot use the sources to harvest
> ideas! At least not trivially, ie. you have to add substantial stuff
to
> the source which are there. Changing a similar function to your needs
> is not addition of substantial stuff.
Not every instance of code copying is a copyright infraction.
> Also, let me put the stuff I said above into some context: Creating
> an efficient (whatever this means) implementation of the standard C++
> library is a non-trivial task involving lots of work. I would hate
that
> this work is abused by someone grabbing a fortune and turning my work
> into a commercial product competing with me.
Again, I never meant to cover the case of someone publishing
code created by you, either with or without changes. I
acknowledge that computer programs of any sort are an
intellectual property, and that the ability to make copies
does not grant the right to make such copies. I think that
anyone paid to write computer programs ought to agree with this.
> And I acknowledge that
> others have invested even more into the creation of a standard C++
> library. Just because we have to disclose our work due to technical
> flaws of current C++ compilers does not allow anybody to use our
> intellectual property for anything. The same applies, of course, to
> other template libraries as well.
I totally agree. But isn't there some room to examine the
source code, without abusing either the letter or the spirit
of the license? Or do you claim that EVERY case where someone
has typed
EDIT vector
to examine your code, is illegal?
--
All...@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.
Sent via Deja.com
http://www.deja.com/
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kanze
> "Francis Glassborow" <francis.g...@ntlworld.com> wrote in message
> news:2zBoQjAX...@ntlworld.com...
> >Currently those implementing libraries of templates have a problem
> >in that they have to provide you the source.
> _All_ libraries have to provide _some_ source.
Only because of weaknesses in the current implementations although
given the way the preprocessor and includes are designed to work, I
expect to see these weaknesses remain.
And there has been at least one exception: the Rogue Wave library
delivered with the basic Sun CC does not (or did not, at least with
Sun CC 4.2) include sources; you needed a separate license to access
the sources. The technicque used by the compiler was very primitive;
the necessary "sources" (most of the library, in fact, since it was
template code) were there, but were encrypted.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627