Frederick Gotham wrote:
 > John Nagle posted:

 >> skaller wrote:
 >>> On Tue, 11 Jul 2006 12:38:15 +0000, Frederick Gotham wrote:
 >>>> In the current Standard, I particularly think the new-style
 >>>> casts are monstrosities:
 >>>>    static_cast
 >>>>    dynamic_cast
 >>>>    reinterpret_cast

 >>     If you use reinterpret_cast too much, you're doing
 >>     something wrong.

 > Ridiculous assessment.

Not really.

 >> On the other hand, dynamic_cast, which is safe, should be
 >> used more.

 > I've never used dynamic_cast, because I've never casted from a
 > base class to a derived class without knowing for certain that
 > the base object was in fact a derived object.

I think John's point was that what you think you know may not
always be correct.  I've noticed that the best programmers fill
their code with lots of asserts of things which they know are
true.  Similarly, a dynamic_cast which returns a null pointer
will usually cause an immediate failure, whereas the static_cast
will cause a subtle error somewhere down the line.

 >>> (3) The choice of long names for casts was quite deliberate.
 >>> What is more, the aim was to get rid of the need for C style
 >>> casts, and to formally deprecate them.
 >>     That really should have been done by now.  Casts are
 >> such a common source of bugs that making them highly
 >> visible and explicit is a win from a reliablity standpoint.

 > I've never introduced a bug by using casts.
 > Never.

Except, of course, in the code you post in
comp.lang.c++.moderated.

     [...]
 >>      short i, j, k;
 >>      let x1 =3D i*j;     // k is a long to avoid overflow

 > That would open a can of worms.

 > Both "i" and "j" are promoted to "int"
 > (implementation-specific as to whether signed or unsigned),
 > and the result of the operation is an "int"

Both i and j are promoted to int, period.  A short will never be
promoted to an unsigned.  (The only time a "promotion" will
result in an unsigned is if the values of the source type do not
fit into an int.  And the standard requires all of the values of
a short to be representable in an int.)

I'm not sure what the rest of the argument is.  Presumably, x1
would have type int, here, since that is the type of the
expression i*j.  I'm not sure where the k comes into it.  But
your point concerning promotion causing confusion is valid in
general.  Especially the fact that an unsigned short will act as
a signed on some implementations, and as an unsigned on others.

--=20
James Kanze                                    kanze.james@neuf.fr
Conseils en informatique orient=E9e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France +33 (0)1 30 23 00 34

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

skaller wrote:
> On Tue, 11 Jul 2006 12:38:15 +0000, Frederick Gotham wrote:
>>In the current Standard, I particularly think the new-style casts are
>>monstrosities:
>>
>>    static_cast
>>    dynamic_cast
>>    reinterpret_cast
>>

    If you use reinterpret_cast too much, you're doing something wrong.
On the other hand, dynamic_cast, which is safe, should be used more.

> For example using 'auto' for variables whose type is deduced
> is plain daft. The correct keyword to use is 'let' -- auto
> has another meaning, even if it isn't used much, and it would
> be used if C++ had lexically scoped nested functions
> (to distinguish them from externs).

    I agree.  It will break occasional code in an obvious way (programs
won't compile), but "let" would be much clearer to programmers.
And someday we might want to put in lexically scoped functions.
GCC, after all, has them as an extension.

> (3) The choice of long names for casts was quite deliberate.
> What is more, the aim was to get rid of the need for C style
> casts, and to formally deprecate them.

    That really should have been done by now.  Casts are
such a common source of bugs that making them highly
visible and explicit is a win from a reliablity standpoint.

> The answer depends on your interpretation. If you view
> unsigned types as just a local representation of
> the natural numbers, then yes, it's a narrowing cast.
>
> But on the other hand, if you view unsigned types as
> modular arithmetic, modulo 2^n for some n, then this
> is not so at all. Instead the cast is an important
> integral domain morphism -- NOT a narrowing cast.
> I'm sure there are other uses related to bit vectors.

    The semantics of "unsigned" tend to be something that
most programmers don't think about too hard.  In the
initial release of 4.3BSD, due to a poorly chosen cast,
TCP sequence number arithmetic was broken for the upper
half of the sequence number space.  That took me three
days to find and fix, and I had to look at the generated
machine code to be sure of what was happening.  (My name
is in the 4.3BSD release notes for that one.)

    Actually, the idea that unsigned values have modular
arithmetic is kind of wierd.  What should have been done
is to deal with the types of intermediate expressions
numerically, rather than syntactically, while recommending
some optimizations for performance.

     For example,

 short i, j, k;
 let x1 = i*j; // k is a long to avoid overflow
 let kshort = short(i*j); // avoid expansion

 int x2 = (i * j) / k; // (i * k) is a long.

     But

 int i;
 i = i+1; // no expansion, because the result is immediately converted

     And
 unsigned short i;
 i = (i + 1) % 65536; // Technically, this requires promotion to long,
   // but should be optimized into unsigned arithmetic
   // where supported by the hardware.

This approach gets you the same answers on all platforms.  But it's too
late to put this into C++.  Nevertheless, realize that trying to deal
with numeric types by syntatical means generally won't lead to consistent
numerical results.

     John Nagle

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

John Nagle posted:

> skaller wrote:
>> On Tue, 11 Jul 2006 12:38:15 +0000, Frederick Gotham wrote:
>>>In the current Standard, I particularly think the new-style casts are
>>>monstrosities:
>>>
>>>    static_cast
>>>    dynamic_cast
>>>    reinterpret_cast
>>>
>
>     If you use reinterpret_cast too much, you're doing something wrong.


Ridiculous assessment.

"Son, if you're using the brakes too much, you're not driving properly.",
How can the father say that if he hasn't seen the race track?


> On the other hand, dynamic_cast, which is safe, should be used more.


I've never used dynamic_cast, because I've never casted from a base class
to a derived class without knowing for certain that the base object was in
fact a derived object.

>> (3) The choice of long names for casts was quite deliberate.
>> What is more, the aim was to get rid of the need for C style
>> casts, and to formally deprecate them.
>
>     That really should have been done by now.  Casts are
> such a common source of bugs that making them highly
> visible and explicit is a win from a reliablity standpoint.


I've never introduced a bug by using casts. Never.

C-style casts are quite handy:

int Func()
{
    long i = 5;

    return (int)i;
        /* Cast to suppress warning */
}


>      short i, j, k;
>      let x1 = i*j;     // k is a long to avoid overflow


That would open a can of worms.

Both "i" and "j" are promoted to "int" (implementation-specific as to
whether signed or unsigned), and the result of the operation is an "int"
also (implementation-specific as to whether signed or unsigned).

If "x1" is to be a "long", this would have consequences on integer
promotion and so forth...

--

Frederick Gotham

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

On Tue, 11 Jul 2006 12:38:15 +0000, Frederick Gotham wrote:

>
> This is mostly about my own personal taste, but still I'd like to express
> my opinion:

Lol!

> I'd like to suggest to the Committee that they use identifiers as short as
> possible for future additions to the standard.

[]

> In the current Standard, I particularly think the new-style casts are
> monstrosities:
>
>     static_cast
>     dynamic_cast
>     reinterpret_cast
>

Well here's my take .. a lot of comments have been made here,
especially on casts.

(1) the choice of names for library functions which can be
namespace qualified is distinct from keywords.

(2) I personally hated the committee attitude -- prior to the
establishment of the first Standard -- trying to
to avoid new keywords. The same approach would make more sense now,
but clarity shouldn't be sacrificed by something as simple as a
keyword clashing with an identifier.

For example using 'auto' for variables whose type is deduced
is plain daft. The correct keyword to use is 'let' -- auto
has another meaning, even if it isn't used much, and it would
be used if C++ had lexically scoped nested functions
(to distinguish them from externs). WG21 can always follow
WG14 and use an identifier out of the reserved namespace
such as _Bool as a new keyword without much risk.

(3) The choice of long names for casts was quite deliberate.
What is more, the aim was to get rid of the need for C style
casts, and to formally deprecate them.

Unfortunately, the committee (including me) rejected the deprecation
proposal. There were two reasons:

(a) Break C compatibility
(b) Faulty decomposition of casts

The first is a clear reason, and a balance of the motto
"as close to C as possible but no closer".

I personally would have favoured breaking compatibility here,
but I accept the choice was political and the majority
opinion was reasonable.

Unfortunately, the C++ casts do not properly decompose all
the kinds of casts one needs, leading to some extremely
ugly casting sequences of dubious merit. To make it
clear **the idea was very good but it didn't pan out**.

For example, consider the conversion from long
to short. You might say this was a narrowing cast and thus
potentially dangerous. Yes. OK. Maybe it should even throw
an exception if the result destroys the value.

Well how about unsigned long to unsigned short?
Is that a narrowing cast?

The answer depends on your interpretation. If you view
unsigned types as just a local representation of
the natural numbers, then yes, it's a narrowing cast.

But on the other hand, if you view unsigned types as
modular arithmetic, modulo 2^n for some n, then this
is not so at all. Instead the cast is an important
integral domain morphism -- NOT a narrowing cast.
I'm sure there are other uses related to bit vectors.

On the other hand, some people contended that the
conversion double -> float was a narrowing cast.
But they're sometimes wrong, just as above. On the contrary,
for some algorithms, it is the other way around.
For example when you're testing the convergence
of a sequence to a limit, and you want 'as much
precision as possible', you often check for

 | l - v | = 0

as a reliable way of calculating the real value

 | l - v | < e

for an e close to zero. In this
case, converting the type of e = 0 from double to float
is anything but a narrowing conversion: in fact it
will cause the algorithm to terminate much earlier,
possibly leading to an entirely wrong result, on the
other hand you may actually WANT to use a float,
rather than a double, because you want precision
'up to float precision' and fear that a double(0)
would actually lead to cyclic behaviour (or even
divergence!).

So actually truth is you simply cannot generalise about
what a 'narrowing' conversion actually is: for signed
integers it is one that risks overflow, but for unsigned
it may or may not lead to a possible loss of 'precision',
and for floating point the whole idea is bogus: you're
actually converting to a distinct representation with
a numerically complex operation, and all you can REALLY
say is that the exponent might overflow. You actually
CANNOT say the loss of bits in the mantissa results
in a loss of precision .. because the value may have
been calculated in such a way it only had 1 digit
of precision in the first place.

So .. already with arithmetic casts, it isn't even close
to being clear there is any way to simply factor the
casts.

Then, as someone else pointed out, using 'static_cast'
for a safe derived to base conversion is clearly overkill,
we needed 'implicit_cast' but didn't get it: the conversion
is sometimes needed to chose the right overload, and sometimes
desirable to be very specific you're abstracting a class
type "right here" to prevent the derived type being
widely known.

Then there is 'const cast'. Seems simple.. but where
is volatile cast? I could go on about reinterpret cast,
which isn't actually what it suggests .. it's a conversion,
even when applied to references. And it's idea not to
throw away const is entirely bogus!


And there's no way to cast 'lvalueness' although you can do
it easily with a function, which shows how brain dead the C++
type system really is:

 // convert an rvalue to an lvalue
 template<typename T>
 const &lvalue(T const &x) { return x; }

and thence:

 // this reinterpret cast works with rvalues too
 template<typename T, typename U>
 T &reinterpret(U const &x) {
   return reinterpret_cast<T&>(const_cast<U&>(x));
 }

which is perfectly typesafe when applied to an rvalue .. but
not when applied to an arbitrary lvalue!! After all, rvalues
are of non-const type .. you can do:

 X().modifier()

which is the reason rvalues were declared non-const in the
first place (motivation by Dag Bruck, Sweden).

Finally note 'function style casts' degenerate badly:

 int(1L)     // a conversion
 X(1)        // constructor
 (void*)(p)  // err is this a function cast or a C cast?
 typedef void *voidp;
 voidp(p)     // oh we wanted a function style cast
          // but couldn't have one without a typedef .. arrggg

What it comes down to is that given a severely broken
type system, properly factoring the casts to cover all
bases simply wasn't assured .. it just wasn't worth the risk
to throw out the C style casts, particularly considering
that they're usually terser.

Except in special cases such as the templates above where
I want to be very precise, and the usage is wrapped in a
template anyhow, I always use C style casts. I *would have
preferred C++ casts* if they'd properly factored the possible
intents, and been a bit easier to compose. The problem,
quite simply, is not with the casts, but the type system
they're supposed to work with.

So .. IMHO .. the new style casts are worthwhile addition
to the language but they do NOT cover all the bases succinctly
enough for anyone to claim that using C style casts is
bad style.

BTW: I regularly use a programming language without
casts .. more precisely there are coercions, but they're
always type safe. The difference is .. the language has
a decent type system to start with, and real casts are
only needed VERY rarely. Basically you aren't allowed
to break the type system (the reinterpret casts that
are provided are not documented, and can cause severe
problems for the garbage collector if abused).

So it is certainly possible to design a language with
a strong enough type system that casts aren't required ..
but C++ is not that language .. for better or
worse we still need casts.


--
John Skaller <skaller at users dot sf dot net>
Try Felix, the successor to C++ http://felix.sf.net


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Francis Glassborow wrote:
> In article <b8knb2lfciothjm4gfccsnmijaclfvcjfd@4ax.com>, Gennaro Prota
> <gennaro_prota@yahoo.com> writes
> >On Tue, 11 Jul 2006 10:32:28 CST, "kanze" <kanze@gabi-soft.fr> wrote:
> >
> >>There are 32949 legal two character names.
> >
> >Care to explain the origin of that number?
>
> Yes definitely an odd number for that claim 523 * 7 * 3 * 3 does not
> seem to offer much promise in this context.

It does if you notice that 7*3*3 is 63...

> I think there are 3339 (53 *
> 63) legal 2 character names in C++ + 53 single character ones.

Apparently James accidently typed 523*63 into his calculater, rather
than 53*63.

Mark Williams

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota wrote:
> On Tue, 11 Jul 2006 10:32:28 CST, "kanze" <kanze@gabi-soft.fr> wrote:

> >There are 32949 legal two character names.

> Care to explain the origin of that number?

Keyboard bounce when I was entering the numbers on the
calculator?  Or maybe I simply forgot to clear the input before
entering the first number.  If nothing else, there's definitly a
digit too many.  What I though I was calculating was 53 (26
upper, 26 lower and _) times 64 (the above, plus 10 digits, or
nothing).  Which gives 3392, unless I've made some other mistake
this time.

Oh, well.  I've never claimed to be perfect, or to never make
mistakes.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

On Tue, 11 Jul 2006 10:32:28 CST, "kanze" <kanze@gabi-soft.fr> wrote:

>There are 32949 legal two character names.

Care to explain the origin of that number?

--
Gennaro Prota

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

In article <b8knb2lfciothjm4gfccsnmijaclfvcjfd@4ax.com>, Gennaro Prota
<gennaro_prota@yahoo.com> writes
>On Tue, 11 Jul 2006 10:32:28 CST, "kanze" <kanze@gabi-soft.fr> wrote:
>
>>There are 32949 legal two character names.
>
>Care to explain the origin of that number?

Yes definitely an odd number for that claim 523 * 7 * 3 * 3 does not
seem to offer much promise in this context. I think there are 3339 (53 *
63) legal 2 character names in C++ + 53 single character ones.



--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Gennaro Prota posted:

> On Tue, 11 Jul 2006 10:32:28 CST, "kanze" <kanze@gabi-soft.fr> wrote:
>
>>There are 32949 legal two character names.
>
> Care to explain the origin of that number?


I don't think it's correct (although I'm open to correction).


Here's my own calculations:
---------------------------

(1) 26 letters in the English part of the alphabet (i.e. without diacritics).

(2) Each has an uppercase/lowercase form, so that's 52 distinct characters.

Pretend you're dealing with a number system whose radix is 52, and you want
to calculate the greatest value representable in two digits. Then add one.

51(52^1) + 51(52^0) + 1

= 2652 + 51 + 1

= 2704



--

Frederick Gotham

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

In article <QCSug.11572$j7.319897@news.indigo.ie>, Frederick Gotham
<fgothamNO@SPAM.com> writes
>Here's my own calculations:
>---------------------------
>
>(1) 26 letters in the English part of the alphabet (i.e. without diacritics).
>
>(2) Each has an uppercase/lowercase form, so that's 52 distinct characters.
>
>Pretend you're dealing with a number system whose radix is 52, and you want
>to calculate the greatest value representable in two digits. Then add one.
>
>51(52^1) + 51(52^0) + 1
>
>= 2652 + 51 + 1
>
>= 2704
>
You forgot underscore, and you forgot that the ten digits are legal as
the second character.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:
> Ron Natalie wrote:
> > kuyper@wizard.net wrote:
> >
> > > The fundamental problem with short identifiers is that they are
> > > popular, for precisely the reasons you give. As a result, the shorter
> > > and more reasonabley a keyword is, the more likely it is to clash with
> > > a name already in use by existing code. Namespaces reduce this problem,
> > > but for unqualified names, they do not eliminate it.
> >
> > It doesn't help for things like the cast operators and aligment_of which
> > are not NAMES but reserved words in the language.
>
> I'm not quite sure what you mean by that comment. The cast operators
> and the proposed alignment_of are keywords, which are names with a
> special meaning to the compiler.  Reserved identifiers include all of
> those keywords, plus all of the standard-defined names which are part
> of the C++ standard library.
> Previously user-defined names and new keywords are quite capable of
> interfering with each other. Using namespaces for user-defined names
> removes the conflicts, but only insofar as those names are used with
> namespace prefixes. Making the names longer helps reduce the liklihood
> of conflict, without actually removing it, for both user-defined names
> and keywords

It is not possible to resolve a conflict between a user-defined name
and a keyword without changing the user-defined name. Placing the
user-defined name in namespace or qualifying it with the name of a
namespace is of no help in resolving the conflict - a keyword is
recognized as a keyword "unconditionally". For that reason, many
language proposals tend to be reticent when it comes to proposing new
keywords to the C++ language - because any conflicts created by a new
keyword with a user-defined name is not one that could have been
foreseen and avoided.

Greg

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> This is mostly about my own personal taste, but still I'd like
> to express my opinion:

> I'd like to suggest to the Committee that they use identifiers
> as short as possible for future additions to the standard.

For what definition of "possible"? For example, the committee
could have used v, instead of vector, i instead of iterator, c
instead of complex...  It would certainly be easier to type:

    m< s, s >

than std::map< std::string, std::string >.  (Obviously, if we're
making names as short as possible, we'll have to get rid of all
this std:: junk.)

There are 32949 legal two character names.  I don't think off
hand that the library defines more symbols than that, so
strictly speaking, as short as possible means no identifier with
more than two characters.  Of course, some of the names will
have to be pretty arbitrary---there are considerably less
countries, and look at some of the two letter abbreviations for
those (zh for China, for example).

> I like names such as:

>     pow
>     memcpy
>     fmod
>     qsort
>     strlen
>     puts
>     malloc

The C++ replacements actually shorten most of those: sort,
instead of qsort, new instead of malloc, copy instead of memcpy,
size instead of strlen, << instead of puts.  That leaves pow and
fmod--pow is probably optimal, given history and extra-C++
usage.  But who knows, off hand, what fmod means?  Especially
in the C library, which generally uses an initial f as an
indication that the function deals with FILE*.  That one should
be clearer.

> In the current Standard, I particularly think the new-style
> casts are monstrosities:

>     static_cast
>     dynamic_cast
>     reinterpret_cast

I think that's intentional.  Tu discourage unnecessary use.

> They take up a disproportionate amount of horizontal
> screenspace, and are a lot less pleasant to have to type out
> (particularly "reinterpret_cast").

I can make the window on my screen 200 and some characters wide.
And I don't know if you realize this, but C++ allows line breaks
in expressions as well, so you can even use them and keep the
line length under 80 characters (as I do).  And of course,
they're not something that occurs often in the code.

Note too that these are keywords.  There are no namespaces to
prevent conflicts, and they were added relatively late.  At
least a minimum effort was required to avoid having them colide
with likely identifiers in user code.

> I would prefer the likes of:

>     alignof

> instead of:

>     alignment_of

> Of course, this is just my own opinion, and others' opinions
> may differ...  but nonetheless I'd like to throw in my two
> cents.

Readability is more important than writability---a program is
written once, but read many times.  Readability is important.

Having said that, there are trade-offs involved.  Something like
int is so frequent that anyone working in C or C++ will
recognize it immediately; very little, if any, readability would
be gained by replacing it with integer.  On the other hand, C
experimented with replacing it with nothing---with the empty
string---in some contexts, and I don't think that that
experiment can be considered a success (although it's hard to
have an identifier with less than 0 characters in its name).
Similarly, I suspect that even you would object to using
arbitrary sequences just to get the name down to two characters.

In the end, the rule should be, first, consistency---you don't
call it getline (without an _) but find_end (with an _), and you
don't abbreviate something in one symbol, and not in another.
Beyond that, trying to find meaningful short names for
frequently used identifiers is probably a good idea: find is
probably a better name than
find_the_first_value_equal_to_the_third_argument, even if the
latter is arguably clearer.  For something as little used as
alignment_of, however, who cares.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

kanze wrote:
> Frederick Gotham wrote:
.
> have to be pretty arbitrary---there are considerably less
> countries, and look at some of the two letter abbreviations for
> those (zh for China, for example).

Actually, for native speakers of mandarin, zh makes a lot of sense,
since the mandarin word for China is Zhongguo.

.
> usage.  But who knows, off hand, what fmod means?  Especially

Floating point MODulus.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

"Krzysztof    elechowski" wrote:
> U   ytkownik "Frederick Gotham" <fgothamNO@SPAM.com> napisa    w wiadomo   ci
> news:D3Msg.11332$j7.315496@news.indigo.ie...

> > This is mostly about my own personal taste, but still I'd
> > like to express my opinion:

> > I'd like to suggest to the Committee that they use
> > identifiers as short as possible for future additions to the
> > standard. I like names such as:

> >    pow
> >    memcpy
> >    fmod
> >    qsort
> >    strlen
> >    puts
> >    malloc

> These indentifiers are short because the classic C standard
> requires all global identifiers to be distinguishable using
> their initial 6 characters, case insensitive.  In order to
> comply with the standard and to make this rule express and
> instantly visible, the standard C library implementors chose
> to make this rule explicit by limiting the length of those
> identifiers to 6 letters lowercase.  It is not obeyed
> consistently, e.g. "memmove" is equivalent to "memmov", but
> you have the idea.

memmove was added much, much later.

I suspect that much of C's terseness can be traced back to the
fact that when C was being invented, the usual terminal was a
teletype.  And if you've ever been in a room where a teletype is
at work, you can understand why the less characters, the better.
(This isn't to say that the linker issue wasn't also a
consideration.)

By the time C was being standardized, teletypes were already on
their way out, and software engineering issues were beginning to
be understood.  The functions added during standardization
generally are not so restricted by the length of names (but
existing conventions were followed where they were established).

Of course, all this is well over fifteen years ago---twenty or
more for the teletypes.  Locking a language into these
restrictions today is certainly not a good idea.

> > In the current Standard, I particularly think the new-style
> > casts are monstrosities:

> >    static_cast
> >    dynamic_cast
> >    reinterpret_cast

> > They take up a disproportionate amount of horizontal
> > screenspace, and are a lot less pleasant to have to type out
> > (particularly "reinterpret_cast").

> > I would prefer the likes of:
> >
> >    alignof
> >
> > instead of:
> >
> >    alignment_of

> > Of course, this is just my own opinion, and others' opinions
> > may differ...  but nonetheless I'd like to throw in my two
> > cents.

> The identifiers printf and memcpy are "monstrosities" for
> every C language student.  Without knowing 6 character rule
> sparing one character from memcopy is inexplicable.  It gives
> no advantage in typing and makes the name unreadable.  And why
> did not they choose the identifier "memmve" as well?  The
> abbreviations are inconsistent and hard to learn.

It depends.  When there is a large set of functions, working
together, like the str... functions, the abbreviation works.
Otherwise, of course, no.

> On the other hand, nothing prevents you from #defining scast,
> dcast, rcast, alignof and using them in your code.  However,
> be warned that coining abbreviations for casts is deprecated

Disparaged, not deprecated.  The preprocessor is not going to be
removed from the language.

Using the preprocessor to change the language, in general, is
disparaged.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

kuyper@wizard.net wrote:

> The fundamental problem with short identifiers is that they are
> popular, for precisely the reasons you give. As a result, the shorter
> and more reasonabley a keyword is, the more likely it is to clash with
> a name already in use by existing code. Namespaces reduce this problem,
> but for unqualified names, they do not eliminate it.

It doesn't help for things like the cast operators and aligment_of which
are not NAMES but reserved words in the language.

>
> The *_cast operators are a special case, however. Most conversions that
> don't occur implicitly are dangerous, at least in some contexts.
> Therefore, the explicit cast operators were deliberately made long and
> unwieldy, to discourage the unnecessary and inappropriate use of casts,
> and to make it easier to locate them when they are used.
>
Well that's a stupid reason.  Actually it is to be encouraged to use
the C++-style casts over the SHORTER AND EASIER TO TYPE C-STYLE ONES
as it limits the range of possible conversions done by any one operator.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
news:1152708021.574709.255240@m79g2000cwm.googlegroups.com...
>
> Disparaged, not deprecated.  The preprocessor is not going to be
> removed from the language.
>
> Using the preprocessor to change the language, in general, is
> disparaged.
>
> --

Thanks.  The abundance of your English vocabulary keeps amazing me all the
time.
Chris


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Uzytkownik "Ron Natalie" <ron@spamcop.net> napisal w wiadomosci
news:44b5db20$0$18490$9a6e19ea@news.newshosting.com...
> kuyper@wizard.net wrote:
>
>> The *_cast operators are a special case, however. Most conversions that
>> don't occur implicitly are dangerous, at least in some contexts.
>> Therefore, the explicit cast operators were deliberately made long and
>> unwieldy, to discourage the unnecessary and inappropriate use of casts,
>> and to make it easier to locate them when they are used.
>>
> Well that's a stupid reason.  Actually it is to be encouraged to use
> the C++-style casts over the SHORTER AND EASIER TO TYPE C-STYLE ONES
> as it limits the range of possible conversions done by any one operator.
>

(cast)s should not pass the code review at all.  The developer who uses them
in C++ code will have to correct them.  This will stop him from taking
shortcuts in the future.
They cannot be eliminated from the language but the compiler could issue a
warning.  Mine does not, alas.
Chris


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Ron Natalie wrote:
> kuyper@wizard.net wrote:
>>
>> The *_cast operators are a special case, however. Most conversions that
>> don't occur implicitly are dangerous, at least in some contexts.
>> Therefore, the explicit cast operators were deliberately made long and
>> unwieldy, to discourage the unnecessary and inappropriate use of casts,
>> and to make it easier to locate them when they are used.
>>
> Well that's a stupid reason.  Actually it is to be encouraged to use
> the C++-style casts over the SHORTER AND EASIER TO TYPE C-STYLE ONES
> as it limits the range of possible conversions done by any one operator.

Of course, it's best to stay away from all kind of casts if possible,
but the general advice is to use only C++-style casts and to avoid the
old C-style casts (even though the latter may seem tempting) *when casts
can be justified* -- after all, they're there because we do need them --
so that they can stand out and keep you alert to the possible danger.
The g++ option "-Wold-style-cast" can help you with this.

--
Seungbeom Kim

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Ron Natalie wrote:
> kuyper@wizard.net wrote:
>
> > The fundamental problem with short identifiers is that they are
> > popular, for precisely the reasons you give. As a result, the shorter
> > and more reasonabley a keyword is, the more likely it is to clash with
> > a name already in use by existing code. Namespaces reduce this problem,
> > but for unqualified names, they do not eliminate it.
>
> It doesn't help for things like the cast operators and aligment_of which
> are not NAMES but reserved words in the language.

I'm not quite sure what you mean by that comment. The cast operators
and the proposed alignment_of are keywords, which are names with a
special meaning to the compiler.  Reserved identifiers include all of
those keywords, plus all of the standard-defined names which are part
of the C++ standard library.
Previously user-defined names and new keywords are quite capable of
interfering with each other. Using namespaces for user-defined names
removes the conflicts, but only insofar as those names are used with
namespace prefixes. Making the names longer helps reduce the liklihood
of conflict, without actually removing it, for both user-defined names
and keywords

> > The *_cast operators are a special case, however. Most conversions that
> > don't occur implicitly are dangerous, at least in some contexts.
> > Therefore, the explicit cast operators were deliberately made long and
> > unwieldy, to discourage the unnecessary and inappropriate use of casts,
> > and to make it easier to locate them when they are used.
> >
> Well that's a stupid reason.  Actually it is to be encouraged to use
> the C++-style casts over the SHORTER AND EASIER TO TYPE C-STYLE ONES
> as it limits the range of possible conversions done by any one operator.

Wise programmers see the limited range of possible conversions as an
advantage, not a disadvantage. It gives you more precise control over
what is happening, and allows for better error messages when you're not
doing what you think you're doing.

The fact that many programmers are not wise is a problem not easily
solved. There is, unfortunately, nothing that could be done to render
the C-style casts illegal without breaking backward compatibility with
C. The most that can be done is to prohibit them in new code, except in
those rare occasions where they do something that can't be done with
the new cast, as a matter of programming guidelines external to the
standard.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

This is mostly about my own personal taste, but still I'd like to express
my opinion:

I'd like to suggest to the Committee that they use identifiers as short as
possible for future additions to the standard. I like names such as:

    pow
    memcpy
    fmod
    qsort
    strlen
    puts
    malloc

In the current Standard, I particularly think the new-style casts are
monstrosities:

    static_cast
    dynamic_cast
    reinterpret_cast

They take up a disproportionate amount of horizontal screenspace, and are a
lot less pleasant to have to type out (particularly "reinterpret_cast").

I would prefer the likes of:

    alignof

instead of:

    alignment_of


Of course, this is just my own opinion, and others' opinions may differ...
but nonetheless I'd like to throw in my two cents.

--

Frederick Gotham

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> This is mostly about my own personal taste, but still I'd like to express
> my opinion:
>
> I'd like to suggest to the Committee that they use identifiers as short as
> possible for future additions to the standard. I like names such as:
>
>     pow
>     memcpy
>     fmod
>     qsort
>     strlen
>     puts
>     malloc
>
> In the current Standard, I particularly think the new-style casts are
> monstrosities:
>
>     static_cast
>     dynamic_cast
>     reinterpret_cast
>
> They take up a disproportionate amount of horizontal screenspace, and are a
> lot less pleasant to have to type out (particularly "reinterpret_cast").
>
> I would prefer the likes of:
>
>     alignof
>
> instead of:
>
>     alignment_of
>
>
> Of course, this is just my own opinion, and others' opinions may differ...
> but nonetheless I'd like to throw in my two cents.\

The fundamental problem with short identifiers is that they are
popular, for precisely the reasons you give. As a result, the shorter
and more reasonabley a keyword is, the more likely it is to clash with
a name already in use by existing code. Namespaces reduce this problem,
but for unqualified names, they do not eliminate it.

The *_cast operators are a special case, however. Most conversions that
don't occur implicitly are dangerous, at least in some contexts.
Therefore, the explicit cast operators were deliberately made long and
unwieldy, to discourage the unnecessary and inappropriate use of casts,
and to make it easier to locate them when they are used.

---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

Frederick Gotham wrote:
> [...]
> I would prefer the likes of:
>
>    alignof
>
> instead of:
>
>    alignment_of
>
>
> Of course, this is just my own opinion, and others' opinions may
> differ... but nonetheless I'd like to throw in my two cents.

Here my half-penny: 'alignof' is not English.  'alignto' is, e.g.
If you want abbreviations, they need to follow some kind of convention
like 'alimntof' (so it's clearer that it's a noun, not a verb like
"align" or "copy" or "put").

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]

U=BFytkownik "Frederick Gotham" <fgothamNO@SPAM.com> napisa=B3 w wiadomo=B6=
ci=20
news:D3Msg.11332$j7.315496@news.indigo.ie...
>
> This is mostly about my own personal taste, but still I'd like to expre=
ss
> my opinion:
>
> I'd like to suggest to the Committee that they use identifiers as short=
 as
> possible for future additions to the standard. I like names such as:
>
>    pow
>    memcpy
>    fmod
>    qsort
>    strlen
>    puts
>    malloc
>

These indentifiers are short because the classic C standard requires all=20
global identifiers to be distinguishable using their initial 6 characters=
,=20
case insensitive.  In order to comply with the standard and to make this=20
rule express and instantly visible, the standard C library implementors=20
chose to make this rule explicit by limiting the length of those identifi=
ers=20
to 6 letters lowercase.  It is not obeyed consistently, e.g. "memmove" is=
=20
equivalent to "memmov", but you have the idea.

> In the current Standard, I particularly think the new-style casts are
> monstrosities:
>
>    static_cast
>    dynamic_cast
>    reinterpret_cast
>
> They take up a disproportionate amount of horizontal screenspace, and a=
re=20
> a
> lot less pleasant to have to type out (particularly "reinterpret_cast").
>
> I would prefer the likes of:
>
>    alignof
>
> instead of:
>
>    alignment_of
>
>
> Of course, this is just my own opinion, and others' opinions may differ=
...
> but nonetheless I'd like to throw in my two cents.

The identifiers printf and memcpy are "monstrosities" for every C languag=
e=20
student.  Without knowing 6 character rule sparing one character from=20
memcopy is inexplicable.  It gives no advantage in typing and makes the n=
ame=20
unreadable.  And why did not they choose the identifier "memmve" as well?=
=20
The abbreviations are inconsistent and hard to learn.

On the other hand, nothing prevents you from #defining scast, dcast, rcas=
t,=20
alignof and using them in your code.  However, be warned that coining=20
abbreviations for casts is deprecated because their names are chosen to=20
constitute a physical discouraging barrier against abusing unsafe languag=
e=20
constructs, *especially* "reinterpret_cast", and to make the design of=20
static code analysis tools easier.

Burdening the committee with the duty of managing abbreviations and=20
shortcuts is unreasonable.  And what happens if some C/UNIX addict prefer=
s=20
algnof to alignof?

>
> --=20
>
> Frederick Gotham
>

Christopher Yeleighton=20


---
[ 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://www.comeaucomputing.com/csc/faq.html                      ]