James Kuyper wrote in message <37513591.7DA02D0A@wizard.net>...
>> [ Is C9X putting nice floating point numbers (like e and pi) into a
header as
>>   constants? ]
>
>No it isn't. And it's already reached the phase where such changes would
>no longer be considered. We'll have to wait another decade or so for the
>next round of standardization.

Or start the next language.  exp(C++) anyone?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote:
: John Potter wrote:
: > double const PI(4*atan(1));
: > double const E(exp(1));
: >
: > If those aren't good enough, nothing else will work anyway.

: The point is, why should each application have it's own e and it's own
: pi? Aren't they generic enough to be part of the standard math library?
: M_PI is a popular extension (is it POSIX?). Why shouldn't it be part of
: the C++ standard library? This is even less of a problem than it would
: be in C, because it can be put in the 'std' namespace.

Sounds like an "If you give a mouse a cookie" problem to me.  Here is a
bit of my math.h.  Are there any others that you would like to see in
the C++ standard?  I love the last two.

None is easy, some is a big debate :)
John

/*
 *      Useful mathmatical constants:
 *
 * M_E          -- e
 * M_LOG2E      -- log2(e)
 * M_LOG10E     -- log10(e)
 * M_LN2        -- ln(2)
 * M_PI         -- pi
 * M_PI_2       -- pi/2
 * M_PI_4       -- pi/4
 * M_1_PI       -- 1/pi
 * M_2_PI       -- 2/pi
 * M_2_SQRTPI   -- 2/(sqrt(pi))
 * M_SQRT2      -- sqrt(2)
 * M_SQRT1_2    -- 1/sqrt(2)
 *
 * These constants are provided to more significant digits
 * than is necessary for a 64-bit double precision number; they
 * may be used for other purposes where the extra precision
 * is necessary or useful.
 */

#define M_E         2.71828182845904523536028747135266250
#define M_LOG2E     1.44269504088896340735992468100189214
#define M_LOG10E    0.434294481903251827651128918916605082
#define M_LN2       0.693147180559945309417232121458176568
#define M_LN10      2.30258509299404568401799145468436421
#define M_PI        3.14159265358979323846264338327950288
#define M_PI_2      1.57079632679489661923132169163975144
#define M_PI_4      0.785398163397448309615660845819875721
#define M_1_PI      0.318309886183790671537767526745028724
#define M_2_PI      0.636619772367581343075535053490057448
#define M_2_SQRTPI  1.12837916709551257389615890312154517
#define M_SQRT2     1.41421356237309504880168872420969808
#define M_SQRT1_2   0.707106781186547524400844362104849039

/*
 *      Useful mathmatical constants:
 *
 * HUGE         - +infinity
 * M_2PI        - 2*pi
 *
 */

#define HUGE       HUGE_VAL
#define M_2PI      6.2831853071795862320E0  /*Hex  2^ 2 *
1.921FB54442D18 */

/* This is the nearest number to the cube root of MAXDOUBLE that   */
/*      doesn't cause the cube of it to overflow.                  */
/* In double precision hex this constant is: 554428a2 f98d728a     */

#define CUBRTHUGE      5.6438030941223618e102
#define INV_CUBRTHUGE  1.7718548704178434e-103
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

John Potter wrote:
>
> Ross Smith <ross.s@ihug.co.nz> wrote:
>
> : John Potter wrote:
> : >
> : > double const PI(4*atan(1));
> : > double const E(exp(1));
> : >
> : > If those aren't good enough, nothing else will work anyway.
>
> : But you can't actually do it like that. Floating point constants can't
> : be initialised in a header file, so the actual values have to go in a
> : separate source module.
>
> What am I missing here?  Constants have internal linkage in C++.

I never knew that. Thanks, that's useful.

> : This causes two problems: first, lost
> : optimisations because the compiler doesn't know the values (in other
> : modules that use the constants) until link time;
>
> What am I missing here?  The compiler is not required to work with
> floating point values.  Cross-compilers.  The values may not be known
> until run time.

But those are pathological cases. Typically, you're compiling on the
same system you're running on, and a good compiler can precompute FP
arithmetic when constants are known at compile time. High-speed FP code
relies on this sort of optimisation. Just because a particular
optimisation can't be done in *all* cases is no reason for making it
impossible in *any* case.

> : inline double pi() { return 3.14159; }
> : inline double e() { return 2.71828; }
>
> : For obvious reasons you can't use calls to the likes of atan() in this
> : approach.
>
> I don't understand.  Education?

You wouldn't want the overhead of a call to atan() everywhere you use
pi. But since it turns out I was wrong and you can safely put explicit
constants in a header, the point is academic.

> : I agree with David Tribble and James Kuyper that some of the basic
> : mathematical constants -- certainly pi, probably e, maybe a few other
> : commonly used ones like sqrt(2) -- should have been put in a standard
> : header.
>
> I can't disagree with that.  Since <cmath> is mostly C and C9X is in
> work now, it seems that efforts would be more productive in
> comp.std.c than here.

I suspect it's too late.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  I know you're desperate, I really sympathise
  I see the morbid horror flicker in your eyes
  But rest assured I'm gonna help to ease your pain
  I'm gonna put a thousand tiny implants in your brain     [Motorhead]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith wrote in message <374DBE78.A133628C@ihug.co.nz>...
>
>John Potter wrote:
>>
>> double const PI(4*atan(1));
>> double const E(exp(1));
>>
>> If those aren't good enough, nothing else will work anyway.
>
>But you can't actually do it like that. Floating point constants can't
>be initialised in a header file

Sure they can.  Remember that const objects not explicitly extern have
internal (static) linkage.  Each c++ file will see PI with a different
address, but you should probably treat PI as an rvalue anyway.

>so the actual values have to go in a
>separate source module. This causes two problems: first, lost
>optimisations because the compiler doesn't know the values (in other
>modules that use the constants) until link time; second, the good old
>static order of initialisation problem.


None of this should be a problem for local variables.

>The optimisation problem is a major issue for a lot of FP code. The only
>way to make the values available at compile time is to put them in a
>header as inline functions:
>
>inline double pi() { return 3.14159; }
>inline double e() { return 2.71828; }


/* static */ const double pi = 3.14159;

also makes the value available at compile time.

>(The real ones would have more decimal places, those are just all I
>could remember on the spur of the moment.)
>
>For obvious reasons you can't use calls to the likes of atan() in this
>approach.


Assuming atan(1) has no side effects (a potential issue if you are raising
signals when inexact floating point occurs) the call may occur at compile
time.  In cases where there is a side effect, but the function result is
computable at compile time, the standard allows the value to be computed at
compile time with the side effect occuring at run time.  For instance for

  extern const double d1;
  double d2 = d1;
  extern const double d1 = sqrt(2);

a compiler is allowed to initialize d2 with either zero or sqrt(2) (for
instance by initializing d1 at compile time and d2 at run time).  On a
system where the result of sqrt(2) can very from run to run (some systems
allow a user-defined function to change the result) this optimization would
be incorrect.

>I agree with David Tribble and James Kuyper that some of the basic
>mathematical constants -- certainly pi, probably e, maybe a few other
>commonly used ones like sqrt(2) -- should have been put in a standard
>header.


Me too.  Perhaps C9X is doing something along these lines?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Bill Wade wrote:
....
> >I agree with David Tribble and James Kuyper that some of the basic
> >mathematical constants -- certainly pi, probably e, maybe a few other
> >commonly used ones like sqrt(2) -- should have been put in a standard
> >header.
>
> Me too.  Perhaps C9X is doing something along these lines?

No it isn't. And it's already reached the phase where such changes would
no longer be considered. We'll have to wait another decade or so for the
next round of standardization.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Discussing case-sensitive names...

James.Kanze@dresdner-bank.com wrote:
>
> "Matt Seitz" <mseitz@meridian-data.com> wrote:
>> I remember Dr. Niklaus Wirth discussing this issue in PROGRAMMING IN
>> MODULA-2.  He decided to have case-sensitive identifiers in Modula-2
>> so that one would find all the occurrences of an identifier when one
>> used a text search that was case sensitive.  Dr. Wirth did allow
>> case-insensitive identifiers in his previous language, Pascal, and
>> found that Pascal programmers sometimes missed finding uses of
>> identifiers when using case-sensitive text search tools.
>
> This sounds more like an argument for better tools.
[...]
>
> More generally, I can't remember ever having worked on a system where
> the search program didn't have a switch for case insensitivity.

Same here.  Heck, even MS-Windows Notepad has a search option for
case matching, and it's got to be one of the lamest editors around.
Bear in mind that Wirth was talking circa 1985, when these kinds of
tools weren't that prevalent.

On the other hand, case-insensitive filenames make more sense
than case-sensitive filenames...

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> wrote:

[snip mostly agreement]

I think there is a case for the two in binary search being spelled 2.

: I'm even of the opinion that <cmath> (and <math.h>) should contain
: definitions of some of the more common mathematical constants,
: such as pi and e.  Since these would be in the 'std' namespace,
: portable code could be written with the guarantee that the exact
: value was implemented for each target platform, e.g, std::PI would
: be the exact proper value of pi (within precision limitations) on
: every implementation.  Presently, this isn't the case.

double const PI(4*atan(1));
double const E(exp(1));

If those aren't good enough, nothing else will work anyway.

John
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

John Potter wrote:
>
> David R Tribble <dtribble@technologist.com> wrote:
>
> [snip mostly agreement]
>
> I think there is a case for the two in binary search being spelled 2.
>
> : I'm even of the opinion that <cmath> (and <math.h>) should contain
> : definitions of some of the more common mathematical constants,
> : such as pi and e.  Since these would be in the 'std' namespace,
> : portable code could be written with the guarantee that the exact
> : value was implemented for each target platform, e.g, std::PI would
> : be the exact proper value of pi (within precision limitations) on
> : every implementation.  Presently, this isn't the case.
>
> double const PI(4*atan(1));
> double const E(exp(1));
>
> If those aren't good enough, nothing else will work anyway.

The point is, why should each application have it's own e and it's own
pi? Aren't they generic enough to be part of the standard math library?
M_PI is a popular extension (is it POSIX?). Why shouldn't it be part of
the C++ standard library? This is even less of a problem than it would
be in C, because it can be put in the 'std' namespace.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

John Potter wrote:
>
> double const PI(4*atan(1));
> double const E(exp(1));
>
> If those aren't good enough, nothing else will work anyway.

But you can't actually do it like that. Floating point constants can't
be initialised in a header file, so the actual values have to go in a
separate source module. This causes two problems: first, lost
optimisations because the compiler doesn't know the values (in other
modules that use the constants) until link time; second, the good old
static order of initialisation problem.

The optimisation problem is a major issue for a lot of FP code. The only
way to make the values available at compile time is to put them in a
header as inline functions:

inline double pi() { return 3.14159; }
inline double e() { return 2.71828; }

(The real ones would have more decimal places, those are just all I
could remember on the spur of the moment.)

For obvious reasons you can't use calls to the likes of atan() in this
approach.

I agree with David Tribble and James Kuyper that some of the basic
mathematical constants -- certainly pi, probably e, maybe a few other
commonly used ones like sqrt(2) -- should have been put in a standard
header.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  I know you're desperate, I really sympathise
  I see the morbid horror flicker in your eyes
  But rest assured I'm gonna help to ease your pain
  I'm gonna put a thousand tiny implants in your brain     [Motorhead]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith <ross.s@ihug.co.nz> writes:

>John Potter wrote:
>>
>> double const PI(4*atan(1));
>> double const E(exp(1));
>>
>> If those aren't good enough, nothing else will work anyway.

>But you can't actually do it like that. Floating point constants can't
>be initialised in a header file, so the actual values have to go in a
>separate source module.

Yes you can. Objects declared const have internal linkage (in effect
declared static), so you get a separate copy in each translation
unit. If you want an extern object PI or E you can't do it this
way, of course.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith <ross.s@ihug.co.nz> wrote:

: John Potter wrote:
: >
: > double const PI(4*atan(1));
: > double const E(exp(1));
: >
: > If those aren't good enough, nothing else will work anyway.

: But you can't actually do it like that. Floating point constants can't
: be initialised in a header file, so the actual values have to go in a
: separate source module.

What am I missing here?  Constants have internal linkage in C++.

: This causes two problems: first, lost
: optimisations because the compiler doesn't know the values (in other
: modules that use the constants) until link time;

What am I missing here?  The compiler is not required to work with
floating point values.  Cross-compilers.  The values may not be known
until run time.

: second, the good old
: static order of initialisation problem.

That's gone if the above internal linkage is correct.

: The optimisation problem is a major issue for a lot of FP code. The only
: way to make the values available at compile time is to put them in a
: header as inline functions:

: inline double pi() { return 3.14159; }
: inline double e() { return 2.71828; }

: For obvious reasons you can't use calls to the likes of atan() in this
: approach.

I don't understand.  Education?

: I agree with David Tribble and James Kuyper that some of the basic
: mathematical constants -- certainly pi, probably e, maybe a few other
: commonly used ones like sqrt(2) -- should have been put in a standard
: header.

I can't disagree with that.  Since <cmath> is mostly C and C9X is in
work now, it seems that efforts would be more productive in
comp.std.c than here.

John



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW wrote:
>
> James.Kanze@dresdner-bank.com wrote:
>> To quote Alan Perlis: "One man's constant is another man's variable."
>> Although it certainly isn't universal, I've noticed that in practice,
>> there are always a few constants that cease to be constant with time.
>> Typically, for example, what was once a compile time constant ends up
>> being read from a configuration file.  I used to want to maintain
>> constants in a separate namespace, but have given up on it.
>
> Yes, yes, of course. This is the very reason to use named constants
> instead of "magic numbers."
>
> For simple numbers that are truly constant in the mathematical
> sense -- there is no chance that they will ever change -- there
> is no reason to name the constant.
>
>     // Unrealistically simple example
>     double SurfaceAreaOfCube(double lengthOfSide)
>         { return 6.0 * lengthOfSide * lengthOfSide; }
>
> If I knew someone that replaced the 6.0 in this example with
> a named constant, no matter how well named, I would be forced
> to kill them. And that's a real pity, because I really dislike
> killing, but there would be no real choice.
>
> I would make exceptions to this principle for irrational numbers or
> any other number difficult to remember or write. After all, if some
> programmers used 3.14 or even 3.1416 instead of PI, the quality of
> the program would suffer somewhat. But there is no way that
>     const double FacesOnCube = 6.0;
> is ever going to be helpful.
>
> On the other hand, numbers that represent policy are best
> treated as constant, even if they are subject to eventual change.
> In the United States it's illegal to buy alcoholic beverages if
> your age is less than 18 years. But if I had a program that
> checked for conditions of scale, I would use
>
>     const long minAgeToBuyBooze = 18;
>
> precisely because this value -- which hasn't changed in a very
> long time -- isn't a true constant in the mathematical sense.

You're essentially arguing that integer constants should not be
given symbolic names, while irrational constants should.  Perhaps
this is just because of the examples you chose, but at any rate,
I disagree with this.

Any constant should be given a symbolic name when it makes the
meaning clearer.  Your example of spelling the constant 6 as 6
is on equal footing to spelling it as FACES_PER_CUBE, but only
because it is so "obvious".  (Worse, you chose to use 6.0 instead
of just 6, which confuses the meaning a bit.)  Quick, how many sides
are there in a heptadecagon?  Numbers used for "policy" are an
extreme example of numbers begging for a symbolic name, regardless
of their frequency of change.  Changeable constants (which is not an
oxymoron), by their nature, serve their use better when given
meaningful symbolic names, e.g., minAgeToBuyBooze.

One should use the principle of "How clear is the meaning of the
constant?"; if it's not "obvious", give it a name.  If nothing else,
one can apply the principle of "How do I find and change all the
occurrences of a constant that needs to be changed in all of my
code?"; names are easier to find than the multiple spellings of
numeric constants (e.g., 6, 6., 6.0, 6.00, 6e0, 6.0e+00, etc.).

I'm even of the opinion that <cmath> (and <math.h>) should contain
definitions of some of the more common mathematical constants,
such as pi and e.  Since these would be in the 'std' namespace,
portable code could be written with the guarantee that the exact
value was implemented for each target platform, e.g, std::PI would
be the exact proper value of pi (within precision limitations) on
every implementation.  Presently, this isn't the case.

-- David R. Tribble, dtribble@technologist.com --
   A little government and a little luck are necessary in life,
   but only a fool trusts either of them.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

 In article <HuX%2.77$0D.6381@ultra>,
  "Matt Seitz" <mseitz@meridian-data.com> wrote:
> AllanW <allan_w@my-dejanews.com> wrote in message
> news:7h7m65$n3q$1@nnrp1.deja.com...
> > Why does C have case-sensitive identifiers?
> > If we read isAName the same way we read ISANAME, then why does
> > the language differentiate?
>
> I remember Dr. Niklaus Wirth discussing this issue in PROGRAMMING IN
> MODULA-2.  He decided to have case-sensitive identifiers in Modula-2 so that
> one would find all the occurrences of an identifier when one used a text
> search that was case sensitive.  Dr. Wirth did allow case-insensitive
> identifiers in his previous language, Pascal, and found that Pascal
> programmers sometimes missed finding uses of identifiers when using
> case-sensitive text search tools.

This sounds more like an argument for better tools.  At one point, I
worked in PL/M, an Intel language which was not only case insensitive,
but allowed $-characters without meaning in a symbol.  It took me less
than half a day to write a search program that found all instances of a
symbol, regardless of case, and with or without $.

More generally, I can't remember ever having worked on a system where
the search program didn't have a switch for case insensitivity.

--
James Kanze                         mailto:
James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                        Beratung in objekt orientierter
Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86
27


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7gu7v8$mv0$1@nnrp1.deja.com>,
  James.Kanze@dresdner-bank.com wrote:
> To quote Alan Perlis: "One man's constant is another man's variable."
> Although it certainly isn't universal, I've noticed that in practice,
> there are always a few constants that cease to be constant with time.
> Typically, for example, what was once a compile time constant ends up
> being read from a configuration file.  I used to want to maintain
> constants in a separate namespace, but have given up on it.

Yes, yes, of course. This is the very reason to use named constants
instead of "magic numbers."

For simple numbers that are truly constant in the mathematical
sense -- there is no chance that they will ever change -- there
is no reason to name the constant.

    // Unrealistically simple example
    double SurfaceAreaOfCube(double lengthOfSide)
        { return 6.0 * lengthOfSide * lengthOfSide; }

If I knew someone that replaced the 6.0 in this example with
a named constant, no matter how well named, I would be forced
to kill them. And that's a real pity, because I really dislike
killing, but there would be no real choice.

I would make exceptions to this principle for irrational numbers or
any other number difficult to remember or write. After all, if some
programmers used 3.14 or even 3.1416 instead of PI, the quality of
the program would suffer somewhat. But there is no way that
    const double FacesOnCube = 6.0;
is ever going to be helpful.

On the other hand, numbers that represent policy are best
treated as constant, even if they are subject to eventual change.
In the United States it's illegal to buy alcoholic beverages if
your age is less than 18 years. But if I had a program that
checked for conditions of scale, I would use

    const long minAgeToBuyBooze = 18;

precisely because this value -- which hasn't changed in a very
long time -- isn't a true constant in the mathematical sense.

----
Allan_W@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW <allan_w@my-dejanews.com> wrote in message
news:7h7m65$n3q$1@nnrp1.deja.com...
> Why does C have case-sensitive identifiers?
> If we read isAName the same way we read ISANAME, then why does
> the language differentiate?

I remember Dr. Niklaus Wirth discussing this issue in PROGRAMMING IN
MODULA-2.  He decided to have case-sensitive identifiers in Modula-2 so that
one would find all the occurrences of an identifier when one used a text
search that was case sensitive.  Dr. Wirth did allow case-insensitive
identifiers in his previous language, Pascal, and found that Pascal
programmers sometimes missed finding uses of identifiers when using
case-sensitive text search tools.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow <francis@robinton.demon.co.uk> wrote in message
news:hT8tIYAC+AN3EwIv@robinton.demon.co.uk...
>
> The problem arises because programmers fail to purge all the previous
> uses so we get (after file inclusion but before other pre-processing)
>
> #define DEF 12
> int const DEF= 12;
>
> and that line becomes (after preprocessing)
> int const 12 = 12;

This sounds like an argument *for* using the same case for constants and
macros.  If such a situation were to occur, it would be beneficial to have
the compiler flag it as an error.  The alternative is to have DEF and Def
defined simultaneously.  If all is "well" and they contain the same values
(always an issue any time data is replicated), then you may end up with code
accessing the same constant via two different names.  This leads to a
headache if you ever want to clean up the code and get back to having just
one constant.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37322437.721EE6FD@technologist.com>,
  David R Tribble <dtribble@technologist.com> wrote:
> The same thing happens in C/C++ programs, too, because of the
> many-to-one mapping of upper and lowercase letters into their
> pronounceable forms:
>
>     is_a_name
>     IS_A_NAME
>     is_a_Name
>     IsAName
>     isAName

The reason that C++ has case-sensitive identifiers is to be
compatible with C.

Why does C have case-sensitive identifiers? I don't think that
there was any precedent for this. Perhaps APL, but that
language is the antithesis of C (it's made for math researchers,
always interpreted, emphasis on flexibility over speed, etc.)

If we read isAName the same way we read ISANAME, then why does
the language differentiate?

----
Allan_W@my-dejanews.com is a "Spam Magnet" --
never read.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

| The reason that C++ has case-sensitive identifiers is to be
| compatible with C.
|
| Why does C have case-sensitive identifiers? I don't think that
| there was any precedent for this. Perhaps APL, but that
| language is the antithesis of C (it's made for math researchers,
| always interpreted, emphasis on flexibility over speed, etc.)

Just about every one of these statements about APL is wrong...  not that
it's greatly relevant.

(For the record:  The standard APL typeface had only upper-case letters.
On the usual APL keyboards, most unshifted produce (upper-case) letters;
the shifted versions were special APL symbols.   If I remember right,
APL *did* allow you to underline any letter by overstriking; the result
was another letter, logically distinct from the original.  Underlined
letters were sometimes used more or less as you might use a lower-case
letter - well, better, the *non*-underscored versions were used as today
you'd probably use a lower-case letter, while the underscored versions
were used as we would use an upper-case letter.  However, in general, it
was rare to use underscored letters at all.  APL compilers did, and do,
exist.  I'm not sure what valid speed comparisons would be, since the
intended domains for which APL and C were aimed are so very different.)

C was one of the first languages - certainly, one of the first to see
widespread use - that assumed the availability of user I/O equipment
that supported upper and lower-case letters (plus such special symbols
as '}').  The previous generations of languages grew up on machines that
used cards or old teletypes for input; these often supported only upper
case letters.  (Looking at DEC's products:  The VT05 - its first video
terminal - supported only upper case.  The VT52 - which came out in
about 1975 - supported both; but there was a cheaper variant - the VT50?
- that was still upper-case only.  Up until the 1980 or so, you'd still
find many line printers and terminals that were upper case only.)

When upper- and lower-case letters became available, existing compilers
had to be modified.  Some (SNOBOL4 is one example) simply classified
lower-case letters as letters in their lexers, and did nothing else.
This implicitly made "a" and "A" distinct.  Others (FORTRAN commonly did
this, though not universally until it was standardized; the same for
LISP, which generally considers upper- and lower-case to be identical
even as it permits just about every other character in its names)
accepted the lower case letters as synonyms for the traditional upper
case letters.  The first of these "solutions" essentially ignores the
issue - it was rarely through through.  Note that once you have both
upper and lower case letters, on most equipment, the latter is easier to
type, so will likely predominate.  In SNOBOL4, this lead to programs
that were all lower-case - except when they used built-in functions,
whose names would only be recognized in upper case.  The FORTRAN
approach, on the other hand, tried to "level things out":  You could
type whichever was easier on your equipment - mixes of older and new
equipment for common for quite some time - and everything would work.

BTW, you can see similar things in file naming:  Many systems that live
on to this day descend from designs done for upper-case only equipment,
and chose to deal with lower-case letters by simple case folding.

Since C started out assuming the availability of both cases of letters,
its choice was deliberate.  Perhaps Dennis Ritchie - who sometimes posts
here - has some memory of what the original C designers and users had in
mind at the time, and will comment.  My guess is that they did this (a)
because they could; (b) because they had a few examples and conventions
in mind (e.g., all upper-case for macros which wouldn't conflict with
lower- or mixed-case for other things) that needed the distinction.

People love to draw analogies between programming languages on the one
side, and natural languages or mathematics on the other.  These don't
actually lead you to any particular resolution of the "casefulness"
debate.  In most natural languages - certainly in English - case carries
very special, and limited, semantic information.  There's a difference
between "Catholic" and "catholic", and I suppose even between "English"
(the language) and "english" (that you put on a cue ball), but changing
all the letters in just about any text to all upper- or all lower-case
leaves it perfectly comprehensible.  Mathematical notation, on the other
hand, generally uses case to encode various semantic information.
Actually, mathematical notion goes much further, encoding essential
semantic information in case, bold/italic/sans/Roman distinctions,
different fonts, and so on - sometimes in broadly agreed-upon ways (the
special double-bar R symbol is always the reals, for example), sometimes
in ways specific to a particular paper.  However, it's relatively rare
in mathematical notion to use multi-letter names - the ones that are
used are often universally agreed upon (sin, log, and such).  Off hand,
I can't think of any multi-letter names that aren't rendered all
lower-case Roman, though I'm sure examples exist.

If FORTRAN was for doing mathematics, and mathematicians use case
distinctions, why doesn't FORTRAN maintain case distinctions?  (Answer:
If the equipment had supported it at the time, I'm sure FORTRAN would
have used upper- and lower-case and maintained case distinctions.  It
didn't, so a new standard for *computational* mathematics came into
being.  To this day, papers about mathematical algorithms will write the
formulas out using one-letter names in upper- and lower-case, then give
a FORTRAN example with longer names all in upper case.

Chance plays a big part in evolution....
       -- Jerry
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ed Brey wrote:

>Could you please post your keyboard mapping that provides the unshifted
>underscore?  ;-)

Sorry that was mistakable, on my german keyboard the underscore requires the
shift key.  I had one word names in mind, where `size' would save a shift
compared to `Size'.

Even though I'm a German (as you may know, all nowns and names in German are
upper case), I would like to vote for lower case class names.  It is exactly
for this reason why I find English visually more pleasant to read than my
native language.

Right, I'm taking Nathan's advice to turn to real problems and stop haggling
about conventions; it was worth the week's break though.  I will go on my
way and take the curses =)

    Philip
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Chinese does have a Romanized alphabetic written language called
> PinYin.  For example, the name "David" becomes "da wei" in PinYin
> (with appropriate accent marks, which I forget at the moment),
> corresponding to the Unicode characters U+5927 and U+5FAB.
>
> On the other hand, a given PinYin word (syllable) such as "wei"
> has many homonyms, corresponding to several ideographs.  So the
> use of an all-alphabetic written form doesn't solve the problem
> for Chinese, because there is a many-to-one mapping of ideographs
> to syllables/PinYin.

I know all this, but as I said, I think it's irrelevent.

> The same thing happens in C/C++ programs, too, because of the
> many-to-one mapping of upper and lowercase letters into their
> pronounceable forms:

This is the crux of the argument.  I have never seen this problem in
real life.  I have been working with computers and programming languages
since the 60's.  It really looks like a solution in search of a problem.

On the other hand, many seem to have had other experience.  I'm trying
to
understand just exactly what that experience is and why it's so
different
from my own.

Now I talked with Nathan about this in person (yes, using meat :-) and I
still don't understand.  We are planning further talks.  The strongest
difference in our experiences so far seems to be that he has worked
primarily on libraries and I have worked primarily on large
applications.

>     is_a_name
>     IS_A_NAME
>     is_a_Name
>     IsAName
>     isAName

And in my world, using such a variety of almost homonyms is strictly
forbidden, so there is no need to distinguish them.

> Some of this is resolved by using verbs for things like functions
> and nouns and adjective for things like variables and constants,
> which effectively separates the language elements into meta-grammatic
> namespaces.  But it doesn't solve the problem completely, because
> type names, which are generally nouns and adjectives, can still be
> confused with variables and constants.

Again, how?  Somehow I just never get confused.  Neither do most of
the programmers I work with.

> But not completely.  In the given fragment, can you tell which
> variables are members of *this and which aren't?:
>
>     int Foo::func(char *name, Type typ)
>     {
>         items++;
>         index = vectors.registerName(name, typ);
>         return (index);
>     }

No, but that's a function of scoping, not of naming conventions.
Normally, when working on a class, I have the members (which are always
few) very well in mind.  If the class is large enough for this to be
confusing, look at the design again.

> Arnold the Aardvark <aardvark@foxholly.demon.co.uk> wrote:
> > An interesting metaphor. However, Chinese is written the way
> > it is not because of hidebound primitive tradition, but because
> > this is most appropriate to its morphology. Likewise the Japanese
> > syllabary and the Russian alphabet. My point is that no human
> > language can serve as a model for C++.
> >
> > Why must code read as either literature or mathematics? Surely a
> > programmer should read as code in the same way that a musician
> > reads music?
>
> Exactly.  We aren't talking about English, we're talking about C++,
> which only borrows a few words and constructs from English.  C++
> is more of a mathematical notation than a literary notation.

Well, we will just have to disagree about this.  On of the best
mathematitions I know has argued strongly for "literary programming",
and I most thoroughly agree with him.  Perhaps my math is out of date,
but I don't remember very many 1000 page proofs, or even 100 page proofs.
I have read novels that long with ease.  In other words, the relevent
experience, to me, seems to come from literature, not from mathematics.

-Mike Ball-


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>> The pride of Chinese calligraphy's adherents is well-justified,
>> yet given a chance to start fresh I would advise teaching an
>> alphabet first, and using that to conduct business.

Michael Ball wrote:
> Have you ever studied Chinese?  Have you ever looked at the number
> of homonyms in the language?  An alphabet doesn't really seem
> that suitable.  Caveat:  I have taken exactly one course in
> Chinese, but what I say here is based on the opinion of those
> who have studied it much more than I.  All that aside, it
> seems almost totally unrelated to this issue.

Chinese does have a Romanized alphabetic written language called
PinYin.  For example, the name "David" becomes "da wei" in PinYin
(with appropriate accent marks, which I forget at the moment),
corresponding to the Unicode characters U+5927 and U+5FAB.

On the other hand, a given PinYin word (syllable) such as "wei"
has many homonyms, corresponding to several ideographs.  So the
use of an all-alphabetic written form doesn't solve the problem
for Chinese, because there is a many-to-one mapping of ideographs
to syllables/PinYin.

The same thing happens in C/C++ programs, too, because of the
many-to-one mapping of upper and lowercase letters into their
pronounceable forms:

    is_a_name
    IS_A_NAME
    is_a_Name
    IsAName
    isAName

Some of this is resolved by using verbs for things like functions
and nouns and adjective for things like variables and constants,
which effectively separates the language elements into meta-grammatic
namespaces.  But it doesn't solve the problem completely, because
type names, which are generally nouns and adjectives, can still be
confused with variables and constants.

Hence the need for some kind of naming style to further distinguish
types from variables from functions.  This usually takes the form of
some kind of uppercase/lowercase rules.

> Names seldom occur in isolation, and context has almost always been
> sufficient to make the usage quite clear.

But not completely.  In the given fragment, can you tell which
variables are members of *this and which aren't?:

    int Foo::func(char *name, Type typ)
    {
        items++;
        index = vectors.registerName(name, typ);
        return (index);
    }

I generally add an 'm_' prefix to member variables and an 's_' prefix
to static member variables to make the distinction clearer (which is
especially useful during debugging):

    int Foo::func(char *name, Type typ)
    {
        s_items++;
        m_index = s_vectors.registerName(name, typ);
        return (m_index);
    }

Arnold the Aardvark <aardvark@foxholly.demon.co.uk> wrote:
> An interesting metaphor. However, Chinese is written the way
> it is not because of hidebound primitive tradition, but because
> this is most appropriate to its morphology. Likewise the Japanese
> syllabary and the Russian alphabet. My point is that no human
> language can serve as a model for C++.
>
> Why must code read as either literature or mathematics? Surely a
> programmer should read as code in the same way that a musician
> reads music?

Exactly.  We aren't talking about English, we're talking about C++,
which only borrows a few words and constructs from English.  C++
is more of a mathematical notation than a literary notation.

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

dtribble@technologist.com says...
>> I would go one step further and make all constants be written in
>> all upper case, thus splitting the names into three spaces
>> (mixed case beginning with lowercase, mixed case beginning with
>> uppercase, and all uppercase).  Thus the last part of your example
>> becomes:
>>
>> % You can have a macro constant
>> %
>> %         #define DEF 1
>> %
>> % and replace it with a constant
>> %
>> %         unsigned const DEF = 1;

Francis Glassborow wrote:
> remembering to #undef DEF first which is where the problem with such
> naming schemes start.  The above suggestion is a recipe for obscure
> error messages.

Please explain, I don't understand how changing DEF from a macro
constant to a variable constant leads to obscure errors.  My point
was that the fact that such a name is all uppercase makes it obvious
that it's a constant (and not a variable).  Please explain how your
scheme does this.

Or did you mean that all-uppercase names should be used only for
preprocessor macros (so that they look different from "real"
constants)?

Michael Lee Finney wrote:
> The problem with that it that it introduces an update anomaly, similar
> to the problem with database tables not being in third normal form.
> If the consonant is subsequently changed to a variable (surely a
> common code transformation!), then instead of only changing the
> definition all of the source code has to be updated.  Since the source
> code does not need to be updated in C or C++ under that code
> transformation from a syntactical point of view, the convention of all
> upper case for constants (even of wide spread) is, to me, a very bad
> thing.  This was the point of my argument about the interaction of
> legal code transformations and naming conventions.

So you're saying that it's a superior method to have both variables
and constants be lowercase?  Sorry, but I disagree; constants are
fundamentally different from variables and deserve to be placed in
their own naming space.  I certainly don't see the harm.

    deg = 180/pi * rad;  // yours
    deg = 180/PI * rad;  // mine

    mode = stream.in;    // yours (and ISO's)
    fp = stream.inp;

    mode = stream.IN;    // mine
    fp = stream.inp;

I have probably had to change a constant into a variable less than
a dozen times in my entire 15 years of programming in C, but then
again I might simply have been more lucky than you.  I don't think
a naming scheme should be obscure in order to cater to the less than
1% chance of any constant being changed into a variable.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <373345E3.C6AC27AC@technologist.com>, David R Tribble
<dtribble@technologist.com> writes
>Please explain, I don't understand how changing DEF from a macro
>constant to a variable constant leads to obscure errors.  My point
>was that the fact that such a name is all uppercase makes it obvious
>that it's a constant (and not a variable).  Please explain how your
>scheme does this.

The problem arises because programmers fail to purge all the previous
uses so we get (after file inclusion but before other pre-processing)

#define DEF 12
int const DEF= 12;

and that line becomes (after preprocessing)
int const 12 = 12;



Francis Glassborow      Journal Editor, 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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <373345E3.C6AC27AC@technologist.com>, dtribble@technologist.com
says...
> So you're saying that it's a superior method to have both variables
> and constants be lowercase?  Sorry, but I disagree; constants are
> fundamentally different from variables and deserve to be placed in
> their own naming space.  I certainly don't see the harm.
>
>     deg = 180/pi * rad;  // yours
>     deg = 180/PI * rad;  // mine
>
>     mode = stream.in;    // yours (and ISO's)
>     fp = stream.inp;
>
>     mode = stream.IN;    // mine
>     fp = stream.inp;
>
> I have probably had to change a constant into a variable less than
> a dozen times in my entire 15 years of programming in C, but then
> again I might simply have been more lucky than you.  I don't think
> a naming scheme should be obscure in order to cater to the less than
> 1% chance of any constant being changed into a variable.

I make very heavy use of the "const" keyword, and so changing constants to
variable is much more frequent with me.  Usually the introduction of a new
element is constant (except where known design constraints dictate) and is
then changed to variable as iterative design/development proceeds.  I rely
very heavily on fast typing, sophisticated editors (with lots of hand-
written extensions) and constant refactoring to achieve a low error rate
with a clean design using an incremental process (and, a very high
productivity rate).  Under such conditions, code update anomalies are not a
good idea.  Especially when they may affect external interfaces -- because
many programmers rebel at "senseless" changes.  My coding standards are
designed around the idea of "code transformations" to prevent that sort of
issue.  I expect that mode of development to intensify in years to come --
especially as an increased support of the refinement calculus by various
programming tools becomes available.

--
Michael Lee Finney
michael.finney@acm.org


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Philip Koester wrote:
>
> But isn't small letters the way it should be in C++?

I remember reading somewhere (I thought it was in D&E, but it may
have been in a Dag Br\"uck posting on bool, or elsewhere) a
mention that the committee chose lowercase names for types, prior
to the inclusion of namespaces, precisely to avoid clashing with
type names in user programs. In other words, existing C++
practice was and is to use initial caps for type names. (I'm not
arguing that it is the only way, I'm simply suggesting that the
use of lowercase names in the standard should not be taken as a
recommendation to do the same in user programs.)

John L
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Lee Finney wrote:
> I would further suggest another meta-principle for naming -- if the
> source code can transform the representation of an object from one
> type to another type without significantly affecting the source code,
> then both types of objects should have the same naming rules.  Notice
> that in C/C++ (and taking into account the above discussion) this
> generally means that functions, variables, constants and macros will
> all be mixed case starting with a lower case letter and that type
> names, template parameters, etc. will all be mixed case starting with
> an upper case letter.  All upper case would be reserved for the
> occasional true acronym (and NOT for macro constants, contrary to the
> popular styles).  These rules can obviously be fine tuned and would
> vary from language to language.
>
> But, you can have a function
>
>         abc(x) {...}
>
> and replace it with a variable
>
>         (*abc)(x)
>
> or even a macro
>
>         #define abc(x)
>
> and not change any remaining source code.  You can have a macro
> constant
>
>         #define def 1
>
> and replace it with a constant
>
>         unsigned const abc = 1;
>
> or with a variable
>
>         unsigned abc;
>
> and, again, not change any remaining source code.
>
> You cannot, in general, replace a type with a variable or a macro so
> it makes sense to distinguish the naming rules there.

I would go one step further and make all constants be written in
all upper case, thus splitting the names into three spaces
(mixed case beginning with lowercase, mixed case beginning with
uppercase, and all uppercase).  Thus the last part of your example
becomes:

% You can have a macro constant
%
%         #define DEF 1
%
% and replace it with a constant
%
%         unsigned const DEF = 1;

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <373222BB.B334B971@technologist.com>, dtribble@technologist.com
says...
> I would go one step further and make all constants be written in
> all upper case, thus splitting the names into three spaces
> (mixed case beginning with lowercase, mixed case beginning with
> uppercase, and all uppercase).  Thus the last part of your example
> becomes:
>
> % You can have a macro constant
> %
> %         #define DEF 1
> %
> % and replace it with a constant
> %
> %         unsigned const DEF = 1;

The problem with that it that it introduces an update anomaly, similar to
the problem with database tables not being in third normal form.  If the
consonant is subsequently changed to a variable (surely a common code
transformation!), then instead of only changing the definition all of the
source code has to be updated.  Since the source code does not need to be
updated in C or C++ under that code transformation from a syntactical point
of view, the convention of all upper case for constants (even of wide
spread) is, to me, a very bad thing.  This was the point of my argument
about the interaction of legal code transformations and naming conventions.

--
Michael Lee Finney
michael.finney@acm.org


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <373222BB.B334B971@technologist.com>,
  David R Tribble <dtribble@technologist.com> wrote:

> I would go one step further and make all constants be written in
> all upper case,

To quote Alan Perlis: "One man's constant is another man's variable."
Although it certainly isn't universal, I've noticed that in practice,
there are always a few constants that cease to be constant with time.
Typically, for example, what was once a compile time constant ends up
being read from a configuration file.  I used to want to maintain
constants in a separate namespace, but have given up on it.

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                        Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86 27

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <373222BB.B334B971@technologist.com>, David R Tribble
<dtribble@technologist.com> writes
>I would go one step further and make all constants be written in
>all upper case, thus splitting the names into three spaces
>(mixed case beginning with lowercase, mixed case beginning with
>uppercase, and all uppercase).  Thus the last part of your example
>becomes:
>
>% You can have a macro constant
>%
>%         #define DEF 1
>%
>% and replace it with a constant
>%
>%         unsigned const DEF = 1;

remembering to #undef DEF first which is where the problem with such
naming schemes start.  The above suggestion is a recipe for obscure
error messages.



Francis Glassborow      Journal Editor, 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


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Philip Koester<kozmik@okay.net> wrote:
>I'm working on a somewhat bigger GUI library and am thinking about what
>naming scheme to use.  I would very much like to do it in the minimalistic
>spirit of the standard C++ classes, but that gives me problems.  Starting
>with a simple size class:
>
>    class size

I've seen enough.  Lower-case class names are fine for tiny
examples, but in any significant-size project you need to
establish naming conventions to allow you to visibly
distinguish type names from non-type names.  It would
be nice if the language grammar distinguished them, but
it doesn't.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> > An interesting claim, but one completely contrary to my own
> > experience.  I've always found such naming conventions to be
> > contra-productive and harmful to readability.
>
> These conventions are used to enhance readability.

This is just restating the claim.

> > Why exactly do you feel that this distinction is necessary?
>
> Because of the terrible C++ grammar.

Except for macros, where the motive for upper case is to avoid
problems with their unscoped nature, I don't see this.

> > Why are the rather elaborate scoping control facilities
> > insufficient to control name clashes?
>
> Naming conventions have nothing to do with scoping. Nathan
> doesn't say that you should company or package specific
> prefixes (RWString and co.), he tell people to use namespaces.
>
> The TypeName/value_name/MACRO_NAME convention is able being
> to distinguish between these very different sorts of names.

Funny, I have never written code where anyone had any slightest
difficulty in distinguishing them.  The MACRO_NAME issue didn't
arise, because we don't use them except as header guards.
Otherwise, the meanings never seem to be in question.

> > Exactly where do you find the ambiguities between types and
> > other entities?
>
> _You_ should know that; try to parse the following:
>
> x * y;
> x ();
> x<t>::y (); // ARM templates
> x (y);

I never have the need to, because anyone who uses names like "x"
"y" in other than a very local scope (like a for loop) gets shot
from a gun. :-)  Rather, the content of the names, instead of the
lexical form, is significant.

Perhaps my preference is due to English's being a largly uninflected
language, but I find code such as

 String string;

to be quite unacceptable.  In the English language, these two words
are identical, and giving them distinct meanings in some other context
seems both unnatural and perverse.  It's the sort of thing that leads
people with a degree in humanities rather than science to believe that
programmers can't communicate.

-Mike-
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dixitque Bonnard.V@wanadoo.fr (Valentin Bonnard) in comp.std.c++:
>The TypeName/value_name/MACRO_NAME convention is able being
>to distinguish between these very different sorts of names.

I tend to write my own names the same way, but your statement makes me
wonder:

If the TypeName convention is so terrific, why do we have istream and
string and vector and complex? Some might be required to avoid breaking
old code, but it certainly would have been possible to standardize on
TypeName as a typedef for typename, and deprecate the latter.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                    http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[This followup was also e-mailed to the cited author for speed -- please
follow up in the newsgroup.]

Dixitque kozmik@okay.net (Philip Koester) in comp.std.c++:
>One last question: I browsed through the standard documents looking for the
>leading underscore issue but couldn't find anything.  I know double
>underscores are illegal because they are reserved for name mangling, but
>when exactly are leading underscores illegal?

I'm a bit puzzled by your reference to "standard documents" in the
plural. I don't know which documents you mean.

I know of only one standard document for C++, ISO/IEC 14882:1998(E), and
the index entry for "reserved / name" takes you right to the spot. I
won't post the text again because I've done so several times.

--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
                                    http://www.mindspring.com/~brahms/
My reply address is correct as is. The courtesy of providing a correct
reply address is more important to me than time spent deleting spam.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <372B91EF.A6273A3C@eng.sun.com>, Michael Ball
<michael.ball@eng.sun.com> writes
>Perhaps my preference is due to English's being a largly uninflected
>language, but I find code such as
>
>       String string;
>
>to be quite unacceptable.  In the English language, these two words
>are identical, and giving them distinct meanings in some other context
>seems both unnatural and perverse.  It's the sort of thing that leads
>people with a degree in humanities rather than science to believe that
>programmers can't communicate.

And also causes grave problems to those that are severely visually
handicapped as screen readers do not normally distinguish case.  It
maybe convenient that C++ use case significant identifiers but perhaps
we should do more to discourage taking advantage of this.

What I would rather like is to see editors that extend the sue of colour
coding so that I could ask for all typenames to be coded in a colour,
all global variables coloured bright red etc.

I simple enhancement to screen readers should support colour coded text.


Francis Glassborow      Journal Editor, 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
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Ball <michael.ball@eng.sun.com> wrote:

: Perhaps my preference is due to English's being a largly uninflected
: language, but I find code such as

:  String string;

: to be quite unacceptable.  In the English language, these two words
: are identical, and giving them distinct meanings in some other context
: seems both unnatural and perverse.

I hate it when someone challenges meaningless conventions which make
my life easier :)  Nathan's unsupported edict was no problem.  There
is no reason, tradition!  It works for me.  Now you want me to think
and make sense of it.

Nathan:  Cat tabby;
English: cat Tabby;
Mike:    cat tabby;
Std:     std::animal_collection::const_cat_type tabby;

I think you may have something to say, but I am missing it.  How about
some concrete examples?

: It's the sort of thing that leads
: people with a degree in humanities rather than science to believe that
: programmers can't communicate.

I have no problem communicating with machines.  Never found one with a
humanities degree.  People are another thing, though :)

John
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

John Potter (jpotter@falcon.lhup.edu) wrote:
: Nathan:  Cat tabby;
: English: cat Tabby;
: Mike:    cat tabby;
: Std:     std::animal_collection::const_cat_type tabby;

Don't know what Mike is thinking, but I would expect to see:
 class tabby : cat { ... };
and:
 tabby jennyanydots;
The question being whether "tabby" is the name of a type of cat, what one
would first assume from English usage without other information, or the
name of a particular cat, which is possible, though probably not a good
generality. (No, I shall not descend into a discussion of singular
inscrutable names and their implications for namespace usage.)

In practice, mixed case class names "clash" (in the visual sense) with the
all lower case convention of the standard. I tend toward a lowercase style
when working on new code. Most of the existing code I work with is already
mixed case so I stick with it. I'm also told that mixed case style doesn't
work as well outside of English, but I do not know why. (I can see why it
would be a problem in many languages, but not necessarily in say languages
that use Roman or Cyrillic alphabets.)

As to color coding, Metrowerks CodeWarrior already has the this feature for
types and other language consturcts. Though the color will not be
correctly rendered until after the first instance of a type is
compiled. The editor uses the class browser database I imagine, which is of
course updated by the compiler.

-Z-
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Fh8EEIAZeCL3EwfU@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
> In article <372B91EF.A6273A3C@eng.sun.com>, Michael Ball
> <michael.ball@eng.sun.com> writes
> >Perhaps my preference is due to English's being a largly uninflected
> >language, but I find code such as
> >
> >       String string;
> >
> >to be quite unacceptable.  In the English language, these two words
> >are identical, and giving them distinct meanings in some other context
> >seems both unnatural and perverse.  It's the sort of thing that leads
> >people with a degree in humanities rather than science to believe that
> >programmers can't communicate.
>
> And also causes grave problems to those that are severely visually
> handicapped as screen readers do not normally distinguish case.  It
> maybe convenient that C++ use case significant identifiers but perhaps
> we should do more to discourage taking advantage of this.
>
> What I would rather like is to see editors that extend the sue of colour
> coding so that I could ask for all typenames to be coded in a colour,
> all global variables coloured bright red etc.

And when a name shows up in an unexpected color, you know you've got a
bug.

But what happens to your visually handicapped readers?  Color blindness
isn't a rare affectation.

(While I'm at it, I'll put in my 2 cents worth.  While I agree globally
with Mike, I find that there are enough questionable cases that I find a
convention which distinguishes between types and non-types useful.  As
for macros, you want a convention easily recognized by a simple shell
script, which can then be run over the program on check-in, to send
termination notices to the programmer who introduced the macro.)

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orientie objet/
                        Beratung in objekt orientierter Datenverarbeitung
Ziegelh|ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86 27

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <zalmanFB5DHF.KuB@netcom.com>,
  zalman@netcom.com (Zalman Stern) wrote:

> In practice, mixed case class names "clash" (in the visual sense) with the
> all lower case convention of the standard. I tend toward a lowercase style
> when working on new code. Most of the existing code I work with is already
> mixed case so I stick with it. I'm also told that mixed case style doesn't
> work as well outside of English, but I do not know why. (I can see why it
> would be a problem in many languages, but not necessarily in say languages
> that use Roman or Cyrillic alphabets.)

I know in German it poses problems, but not in the sense we are
concerned with here.  (The question is more: what constitues a new word,
given the German tendancy to write just about anything as a single word,
so you get one person writing "Stammvertragsnummer" and another
"StammvertragsNummer") Sticking with whatever is present in the existing
code is doubtlessly the best solution -- one of the reason I tend to
favor mixed case so strongly is I have done a lot of work in telecoms,
and the CCITT standards use the mixed case convention, with the first
letter upper case for types, lower case for everything else.

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                        Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86 27

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.11955a671cbb3cb598995f@news.mindspring.com>,
  brahms@mindspring.com (Stan Brown) wrote:
> Dixitque Bonnard.V@wanadoo.fr (Valentin Bonnard) in comp.std.c++:
> >The TypeName/value_name/MACRO_NAME convention is able being
> >to distinguish between these very different sorts of names.
>
> I tend to write my own names the same way, but your statement makes me
> wonder:
>
> If the TypeName convention is so terrific, why do we have istream and
> string and vector and complex? Some might be required to avoid breaking
> old code, but it certainly would have been possible to standardize on
> TypeName as a typedef for typename, and deprecate the latter.

A lot of things would have been possible:-).  In fact, the naming
convention in C starts with int, char, etc.  C++ just decided to keep
the same convention.

--
James Kanze                         mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                        Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany  Tel. +49 (069) 63 19 86 27

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Philip Koester <kozmik@okay.net> wrote in message
news:newscache$xel0bf$7d5$1@outerworld.news.ipf.de...
[...]
>   Things are more convenient to type when you don't need the SHIFT key
> all the time. This is why I prefer this_way_of_writing, it comes closer to
> what we read and write every day outside the source code world.

Could you please post your keyboard mapping that provides the unshifted
underscore?  ;-)

[Moderator note: Could you please _not_ post it ? --vb]
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3729D3D2.43C7D772@eng.sun.com>, michael.ball@eng.sun.com says...
> An interesting claim, but one completely contrary to my own
> experience.  I've always found such naming conventions to be
> contra-productive and harmful to readability.  Following
> normal English language conventions has always turned out
> best in the end.

And the standard English rule are that "proper" names are capitalized and
"common" names are not.  I would interpret type names as "proper" and non-
type names as "common".  So, the standard English rules would result in the
convention of type names starting with an upper case letter (but not all
upper case).  Further, English rules would result in acronyms in being all
upper case -- until they entered common usage and then being lower case as
for most other words.  In computer usage, a rarely used acronym should then
be upper case (say if you refer to ISO in only a few places), but an
invented acronym that enters "common usage" in your environment should no
longer be all upper case.

It's true that an English phrase does not consist of a sequence of
capitalized words, but neither does it consist of a sequence of words
separated by underscores (or dashes as in COBOL).  Further, an English phase
is not marked off in any particular way, but inferred by context.  In this
case, English is not a good guide (analogy only carries so far) because the
compilers require that the "phrase" be a single unit.  Therefore the
individual words must be delimited or connected in some manner.

I personally find an analogy from the German language where new words are
made by "sticking" old words together -- but usually without marking word
separations.  So, I prefer to use the shifted case" technique rather than
the underscores.  I personally used the underscores for more than a decade
of my programming carrier because I only had upper case letters available on
the limited type trains of the time.  I stuck with that style out of inertia
even after lower case became commonly available.  I only switched slowly,
and after a great deal of consideration of readability -- I simply find the
shifted case much more readable.  It is less easy to miss a case change than
to miss an underscore -- especially in print and display text where many
fonts do not represent underscores very well, or in very small text (which I
commonly use).

I would further suggest another meta-principle for naming -- if the source
code can transform the representation of an object from one type to another
type without significantly affecting the source code, then both types of
objects should have the same naming rules.  Notice that in C/C++ (and taking
into account the above discussion) this generally means that functions,
variables, constants and macros will all be mixed case starting with a lower
case letter and that type names, template parameters, etc. will all be mixed
case starting with an upper case letter.  All upper case would be reserved
for the occasional true acronym (and NOT for macro constants, contrary to
the popular styles).  These rules can obviously be fine tuned and would vary
from language to language.

But, you can have a function

 abc(x) {...}

and replace it with a variable

 (*abc)(x)

or even a macro

 #define abc(x)

and not change any remaining source code.  You can have a macro constant

 #define def 1

and replace it with a constant

 unsigned const abc = 1;

or with a variable

 unsigned abc;

and, again, not change any remaining source code.

You cannot, in general, replace a type with a variable or a macro so it
makes sense to distinguish the naming rules there.

[Moderator note: there is no confirmation that an article
has been recieved by the moderators in comp.std.c++ (unlike
comp.lang.c++.moderated). You only get a mail if your
article is rejected. --vb]

--
Michael Lee Finney
michael.finney@acm.org
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Michael Ball <michael.ball@eng.sun.com> wrote:
>Nathan Myers wrote:
>
>> I've seen enough.   ... you need to ... visibly
>> distinguish type names from non-type names.  It would
>> be nice if the language grammar distinguished them, but
>> it doesn't.
>
>An interesting claim, but one completely contrary to my own
>experience.  I've always found such naming conventions to be
>contra-productive and harmful to readability.  Following
>normal English language conventions has always turned out
>best in the end.  Those whose native language is not English
>may have their own literary conventions, of course, but my
>point is that treating a program as a piece of literature has
>always been more productive than treating it as a piece of
>mathematics.

I have learned to respect Mike's experience.  My response was
based on the observation that using a simple convention would
have prevented the original question from arising.  I usually
prefer not encountering a problem at all over having workarounds
and strategies at hand to ameliorate it.

>Why exactly do you feel that this distinction is necessary?
>Why are the rather elaborate scoping control facilities
>insufficient to control name clashes?

I agree that programs are best written as literature, and the
best programs are best read as literature.  Few programmers,
though, have literary skills, and to insist upon such skills
in addition to necessary technical competence in a variety of
other areas may narrow the field of usable talent for each job
down from the embarrassing N right past the ideal Unity to the
problematic Nil.

If a simple naming convention (e.g. capitalize type names) can
substitute for a refined and rare cultural skill, why avoid it?
The pride of Chinese calligraphy's adherents is well-justified,
yet given a chance to start fresh I would advise teaching an
alphabet first, and using that to conduct business.

I find C++ scoping facilities insufficient because they
are used on a much larger granularity than I think would be
needed to compensate for the language's inherent ambiguity.
To use C++ scoping on a fine enough scale to substitute for a
naming convention would seem to me to add too much clutter.

>Exactly where do you find the ambiguities between types and
>other entities?  Is it some confusion between the language
>and the metalanguage??  I'm really curious.

I was referring to the specific language grammar, as noted by
Valentin.  I have not found the boundaries between parts of speech
in English to be sufficient to disambiguate my intent, when every
noun can be verbed and every verb nouned. English is a poetic and
slippery language, which makes for good poetry but confusing code.
I find an extra notational convention provides necessary friction.

Perhaps I mistake Mike's meaning.  If so, I hope he can find time
to elaborate with some examples of a naming/scoping convention
or style which depends less on the Shift key.   I can't say I
really _like_ capitalizing type names; it just seems (in current
idiom) to "suck less" than the alternatives I have tried.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Philip Koester<kozmik@okay.net> wrote:
>Nathan Myers wrote:
>
>>>I would very much like to do it in the minimalistic
>>>spirit of the standard C++ classes, but that gives me problems.  Starting
>>>with a simple size class:
>>>
>>>    class size
>
>>I've seen enough.  Lower-case class names are fine for tiny
>>examples, but in any significant-size project you need to
>>establish naming conventions to allow you to visibly
>>distinguish type names from non-type names.
>
>But isn't small letters the way it should be in C++?

No.  The Standard Library adopted an all-lower case style
for what amount to purely procedural reasons.  Nobody I have
talked to actually preferred it, they just preferred talking
about real problems over haggling about conventions.

>It is just that I feel this mixedCaseWritingStyle isn't a natural
>thing to do;

It is, in fact, IMHO an abomination. Mixed_case_writing is in fact
what you use in English, as in this sentence, albeit with different
meaning assigned to case.

>>It would be nice if the language grammar distinguished them, but
>>it doesn't.
>
>Well in a way it does, you can always say `class size' to express the
>type-ness of the `size' identifier, like this:
>
>    class size size() const { return _size; }
>    view& size(const class size& size) { _size = size; return *this; }
>
>The more I look at this, the more I feel it could be an appropriate way to
>go.

It would work.  Still, people reading your code would curse you.
C++ dropped the "struct tag" namespace for sound reasons.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

>>> If a simple naming convention (e.g. capitalize type names) can
substitute for a refined and rare cultural skill, why avoid it?
The pride of Chinese calligraphy's adherents is well-justified,
yet given a chance to start fresh I would advise teaching an
alphabet first, and using that to conduct business.

An interesting metaphor. However, Chinese is written the way
it is not because of hidebound primitive tradition, but because
this is most appropriate to its morphology. Likewise the Japanese
syllabary and the Russian alphabet. My point is that no human
language can serve as a model for C++.

Why must code read as either literature or mathematics? Surely a
programmer should read as code in the same way that a musician
reads music?

Arnold the Aardvark



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Nathan Myers wrote:
>
> I have learned to respect Mike's experience.  My response was
> based on the observation that using a simple convention would
> have prevented the original question from arising.  I usually
> prefer not encountering a problem at all over having workarounds
> and strategies at hand to ameliorate it.

Quite frankly, I never encounter the problem your convention
is attempting to solve, which I why I wonder at attempts to
solve it.

> If a simple naming convention (e.g. capitalize type names) can
> substitute for a refined and rare cultural skill, why avoid it?

I don't find it all that rare.  Encouragement seems to be able to
bring it out in (almost) everybody.

> The pride of Chinese calligraphy's adherents is well-justified,
> yet given a chance to start fresh I would advise teaching an
> alphabet first, and using that to conduct business.

Have you ever studied Chinese?  Have you ever looked at the number
of homonyms in the language?  An alphabet doesn't really seem
that suitable.  Caveat:  I have taken exactly one course in
Chinese, but what I say here is based on the opinion of those
who have studied it much more than I.  All that aside, it
seems almost totally unrelated to this issue.

> I was referring to the specific language grammar, as noted by
> Valentin.  I have not found the boundaries between parts of speech
> in English to be sufficient to disambiguate my intent, when every
> noun can be verbed and every verb nouned. English is a poetic and
> slippery language, which makes for good poetry but confusing code.
> I find an extra notational convention provides necessary friction.

A "slippery" analogy indeed :-)

> Perhaps I mistake Mike's meaning.  If so, I hope he can find time
> to elaborate with some examples of a naming/scoping convention
> or style which depends less on the Shift key.   I can't say I
> really _like_ capitalizing type names; it just seems (in current
> idiom) to "suck less" than the alternatives I have tried.

Basically, I have trouble understanding why we need a solution to
a problem that I've never seen arise in practice.  Names seldom
occur in isolation, and context has almost always been sufficient
to make the usage quite clear.

-Mike-


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Philip Koester" <kozmik@okay.net> writes:

>         const size& size() const { return _size; } // problem

This is illegal: size first indicates ::size, but then view::size when
re-interpreted at end-of-class. This is ill-formed, no diagnosis
required. The obvious reason: Lookup finds the name in the class scope
first, before looking into global scope.

>         // write access to size
>         view& size(const size& size) { _size = size; return *this; }

Here, view::size was already defined. The type in the argument is the
then refers to view::size, which is not a type. However, the parameter
name then shadow the method name, so in the method, size refers to the
parameter, as intended.

>         size _size; // problem

Same problem.

> Should the code above be legal according to the standard?

No, it is ill-formed.

> I know there are numerous work-arounds, like explicitly saying `class size'
> in all lines in questions, but that would bloat my code and, even worse,
> permanently force me to deal with this problem, and I don't want to think
> too much when prototyping =)  Naming the member functions `get_size()' and
> `set_size' would solve this problem too, but that is a naming scheme I don't
> like and doesn't fit well with the standard classes.

There is a third option: qualify the class name (instead of
elaborating it), as done below:

    class view
    {
    public:

        view();

        // read access to size
        const ::size& size() const { return _size; }

        // write access to size
        view& size(const ::size& size) { _size = size; return *this; }

    private:

        ::size _size;
    };

This doesn't look too terrible to me, is well-formed, and accepted by
egcs 1.1.

Regards,
Martin


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Philip Koester wrote in message <7g6le9$1og$1@newsreader.ipf.de>...
>Now inside the view class, `size' is both used as a class name and as a
name
>for two members functions.  (It's even used as variable name here, but
>that's not part of the problem.)  egcs gives me warnings about conflicting
>declarations, and VC5 issues an error even.
>
>Should the code above be legal according to the standard?

I know you're not asking for a workaround, maybe you'll find it helpful.
I'll leave the "is this legal?" question to the language lawyers.

You could get around this problem with a typedef. I'd change some of the
names for clarity anyway (e.g., IMO "size" as a class, method, variable, and
member data seems like asking for confusion). Also, although you can get
away with it, I believe names beginning with underscores (like your "_size"
member data) are reserved.

class size {};

class view
{
public:
   typedef size size_type;
   const size_type& size() const {return m_size;}
   view& size(const size_type& s) {m_size = s; return *this;}

private:
   size_type m_size;
};

-john, jlund@allaire.com


>    class view
>    {
>    public:
>
>        view();
>
>        // read access to size
>        const size& size() const { return _size; } // problem
>
>        // write access to size
>        view& size(const size& size) { _size = size; return *this; }
//problem
>
>    private:
>
>        size _size; // problem
>    };
>
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I'm working on a somewhat bigger GUI library and am thinking about what
naming scheme to use.  I would very much like to do it in the minimalistic
spirit of the standard C++ classes, but that gives me problems.  Starting
with a simple size class:

    class size
    {
    public:

        size() {}
        size(int w, int h) : w(w), h(h) {}

        int w;
        int h;
    };

So far, so good.  Now, I want to make a view class that owns such a size.  A
view can both return its current size, and it can be assigned a new size.
The straightforward minimalistic approach is this:

    class view
    {
    public:

        view();

        // read access to size
        const size& size() const { return _size; } // problem

        // write access to size
        view& size(const size& size) { _size = size; return *this; } //
problem

    private:

        size _size; // problem
    };

Now inside the view class, `size' is both used as a class name and as a name
for two members functions.  (It's even used as variable name here, but
that's not part of the problem.)  egcs gives me warnings about conflicting
declarations, and VC5 issues an error even.

Should the code above be legal according to the standard?

I know there are numerous work-arounds, like explicitly saying `class size'
in all lines in questions, but that would bloat my code and, even worse,
permanently force me to deal with this problem, and I don't want to think
too much when prototyping =)  Naming the member functions `get_size()' and
`set_size' would solve this problem too, but that is a naming scheme I don't
like and doesn't fit well with the standard classes.

Aside from these warning messages, egcs compiles and executes fine.  So, if
anyone can enlighten me if it's legal at all what I'm trying to do, I will
look for a way to get rid off these warnings.

Regards,

    Philip



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]