E2015 Ambiguity with Stream->Seek

[Roddy Pratt]

I just ran into this:

str->Seek(7, soCurrent);

Looks fine, but won't compile.

[C++ Error] E2015 Ambiguity between '_fastcall
Classes::THandleStream::Seek(const __int64,Classes::TSeekOrigin) and
'_fastcall Classes::THandleStream::Seek(int,unsigned short)

Naturally, replacing it with this fixes it:-

str->Seek(7LL, soCurrent);

But, does the language really give the same "weight" to casting an int
to __int64 as it does to casting an enumeration value to a word...?
That seems a little odd. Maybe TStream should define Seek(int,
TSeekOrigin) as well...?

- Roddy

[Alan Bellingham]

Post by Roddy Pratt
But, does the language really give the same "weight" to casting an int
to __int64 as it does to casting an enumeration value to a word...?

Shouldn't it?

They're all integral types: given two possible conversions, with similar
rankings, would you prefer it to pick the (int, short) one?

Probably not, since you actually chose the other one.

It's a good reason for not having rules to disambiguate ambiguous
choices like this: it may end up choosing the unexpected option.

Post by Roddy Pratt
That seems a little odd. Maybe TStream should define Seek(int,
TSeekOrigin) as well...?

I'll agree that the interface is unfortunately designed. In this case,
I'd expect that either choice would work for you: the __int64 one is
probably there purely for those cases where you *need* to seek more than
2GB forwards or backwards in one jump, and that the enumeration is there
more for documentation purposes than anything else.

(7 *is* considerably less than 2GB.)

Alan Bellingham

[Roddy Pratt]

(7 is considerably less than 2GB.)

Can't say I disagree with that ;-)

I guess I struggle with this because I learnt pascal before C, so while
enums /are/ integral types, I try and avoid thinking of them as such.
And I'd rather use a function with (int,enum) than one with (int,int)
because then the compiler should be able to prevent me getting the
parameters in the wrong order. Which I've done before with seek...

And to make matters worse...

str->Seek(soCurrent, 7); // Error - param order is swapped

... compiles without any error whatsoever.


- Roddy

[Alan Bellingham]

Post by Roddy Pratt
And to make matters worse...
str->Seek(soCurrent, 7); // Error - param order is swapped
... compiles without any error whatsoever.

Yep. C-style enumerations aren't even second class citizens, they're
third class.

(I tend to make use of a struct-enum: same size, but actually typesafe,
when I can. It'd be nice to have a language solution, in the same way
that 'bool' was introduced.)

Alan Bellingham

[Chris Uzdavinis (TeamB)]

Post by Alan Bellingham
(I tend to make use of a struct-enum: same size, but actually typesafe,
when I can. It'd be nice to have a language solution, in the same way
that 'bool' was introduced.)

I've been working on a solution that is a c++ code generator for enum
objects. Far more than just structs, you can have user-defined member
functions, plus automatic string->enum and back functions generated,
plus introspection (iterators across the names, values, and aliases.)
They're forward-declarable, strongly typed, and lightweight objects.

The new standard will obviate some of the utility, but I think there
will still be a use for it, but the generated code will make use of
more built-in features.

One question I've not been able to answer clearly is:

Given two enumerators, 'a' and 'b', both with same numeric value,
when instantiated as objects, should the objects compare equal or not.
That is, is their value the same thing as their identity? In normal
C++ the answer is "yes", but with objects it's not so clear.

In particular, think of this:

enum E {a=1, b=1};

char const * enum_to_string(E e)
{
// ...
}

The answer to the identity question determines if the result of

enum_to_string(b)

returns "a" or "b". (It would return "a" if identity is based on
their value.)


Anyway, the program is available, but still in early form and not
quite production ready. Still, it's kind of neat, and the generated
code is very easy to read.

home
http://code.google.com/p/enumgen/

download (svn)
http://code.google.com/p/enumgen/source/checkout


Also, the code generator is written in common lisp. I've never tried
it on windows either, but one of the CL implementations should work.
I think. :)

Thought you might be interested... even as just a curiousity.

[Alan Bellingham]

Post by Chris Uzdavinis (TeamB)
Given two enumerators, 'a' and 'b', both with same numeric value,
when instantiated as objects, should the objects compare equal or not.
That is, is their value the same thing as their identity? In normal
C++ the answer is "yes", but with objects it's not so clear.

In C++, the answer does tend to depend on the semantics of the objects
in question. If you're talking value semantics (things that can be
copied around willy nilly, interchanged, put into vectors, etc. etc.),
then equal values means equal values. If they have object semantics
(can't copy, etc. - for example, handles), then it's a different matter.

I'd expect enumerations to have value semantics. If the internal values
are defined to be numerically the same, then I would expect the external
values to compare equal.

Alan Bellingham

[Alan Bellingham]

Post by Alan Bellingham
then equal values means equal values. If they have object semantics

(It's reference semantics that's the opposite to value semantics - i.e.
things you tend to have pointers to.)

Alan Bellingham

[Chris Uzdavinis (TeamB)]

Post by Alan Bellingham

Post by Chris Uzdavinis (TeamB)
Given two enumerators, 'a' and 'b', both with same numeric value,
when instantiated as objects, should the objects compare equal or not.
That is, is their value the same thing as their identity? In normal
C++ the answer is "yes", but with objects it's not so clear.

In C++, the answer does tend to depend on the semantics of the objects
in question. If you're talking value semantics (things that can be
copied around willy nilly, interchanged, put into vectors, etc. etc.),
then equal values means equal values. If they have object semantics
(can't copy, etc. - for example, handles), then it's a different matter.

Agreed. But for a code-generator that can do "whatever I want", the
question is, what do I want?

Post by Alan Bellingham
I'd expect enumerations to have value semantics. If the internal values
are defined to be numerically the same, then I would expect the external
values to compare equal.

I would too. But if you have two enumerator objects "a" and "b", and
you ask them how to spell their name, would you expect the same
spelling for both, or would their names be different even if their
values are the same?

I'm looking for arguments either way, but until I settle on one, I
just went ahead and made it like the C++ enums, such that when two
objects have the same value, the "value-to-string" function will
consistently return only one of the names between them. Thus,
b.name() would return "a".

[Bob Gonder]

Post by Chris Uzdavinis (TeamB)
b.name() would return "a".

What happened to least surprise?

But if not equal, then
switch( e )
case E.a:
case E.b:
could get interesting...

[Chris Uzdavinis (TeamB)]

Post by Bob Gonder

Post by Chris Uzdavinis (TeamB)
b.name() would return "a".

What happened to least surprise?

I like that principle, but either way has some surprising behaviors.
It just changes the where the surprise is.

Post by Bob Gonder
But if not equal, then
switch( e )
could get interesting...

With regular enums, that would be a compile time error for duplcate
cases in the switch. If a and b were synonyms, doesn't it make sense
that only one name can be shared between them?


If a and b are the same value, it makes sense that using a and b in a
switch would be an error. If we treat a and b as different objects,
then it would be surprising if they cannot both be used in a switch.

Since people know how enums are today, if a=1 and b=1, then if they
were treated as different objects, would it be surprising that
a.name() and b.name() return "a" and "b", but a.value() and b.value()
both return the same name?

One could easily argue either way, but since we're modeling on enums,
keeping consistent with existing ones seems the least surprising of
the two. But that does mean that b.name() says "a", if their values
are the same.

[Bob Gonder]

Post by Chris Uzdavinis (TeamB)
b.name() would return "a".

What happened to least surprise?

[Alan Bellingham]

In the not-too-distant future, C++ will have stronger types for enums,
without the implicit conversion to int, that are also
forward-declarable.

enum class WhatEver { .... };

(http://en.wikipedia.org/wiki/C%2B%2B0x)

Alan Bellingham

[Chris Uzdavinis (TeamB)]

Post by Roddy Pratt
I guess I struggle with this because I learnt pascal before C, so while
enums /are/ integral types, I try and avoid thinking of them as such.
And I'd rather use a function with (int,enum) than one with (int,int)
because then the compiler should be able to prevent me getting the
parameters in the wrong order. Which I've done before with seek...
And to make matters worse...
str->Seek(soCurrent, 7); // Error - param order is swapped
... compiles without any error whatsoever.

In the not-too-distant future, C++ will have stronger types for enums,
without the implicit conversion to int, that are also
forward-declarable.

[David Dean [CodeGear]]

In the not-too-distant future, C++ will have stronger types for enums,
without the implicit conversion to int, that are also
forward-declarable.

And these are on the public roadmap for Tiburon. (the next version of
C++Builder)

[Ed Mulroy [TeamB]]

Which means that the language will no longer have enum, just something else
using the name enum but for the old style enum perhaps one can then use a
#define.

The language keeps getting bigger and bigger but existing problems such as
arcane syntax are retained.

. Ed

In the not-too-distant future, C++ will have stronger types for enums,
without the implicit conversion to int, that are also
forward-declarable.

[Alan Bellingham]

Post by Ed Mulroy [TeamB]
Which means that the language will no longer have enum, just something else
using the name enum but for the old style enum perhaps one can then use a
#define.

The existing enum won't be going away.

Post by Ed Mulroy [TeamB]
The language keeps getting bigger and bigger but existing problems such as
arcane syntax are retained.

Yes. Because you *cannot* get rid of existing stuff, it breaks too much.
That's what even Java has discovered.

Alan Bellingham

[Ed Mulroy [TeamB]]

Post by Alan Bellingham
The existing enum won't be going away.

Of course it will. That which is identified as enum will not be the same.
Therefore the original one is no more.

Post by Alan Bellingham
...you *cannot* get rid of existing stuff...

enum being removed and replaced with something that no longer has implicit
conversion to int is getting rid of existing stuff.

Providing an alternative syntax for items such as complex expressions
involving template specialization is not "getting rid of existing stuff".

. Ed

Post by Alan Bellingham

Post by Ed Mulroy [TeamB]
Which means that the language will no longer have enum, just
something else using the name enum but for the old style enum
perhaps one can then use a #define.

The existing enum won't be going away.

Post by Ed Mulroy [TeamB]
The language keeps getting bigger and bigger but existing problems
such as arcane syntax are retained.

Yes. Because you *cannot* get rid of existing stuff, it breaks too much.
That's what even Java has discovered.

[Roddy Pratt]

Post by Ed Mulroy [TeamB]
Of course it will.

Not as I understand it. If you want newfangled "scoped enums", you need
to define them as "enum class", rather than plain "enum".

Oldfangled enums, warts and all, are sadly here to stay ;-)

However, this raises another question: Should the PAS -> HPP converter
in the delphi compiler should emit scoped enum types for delphi enums?
My gut feeling is yes, as scoped enums should be a better map to the
Delphi type.

But, I guess there are possible incompatibilites that might require
people to improve certain aspects of existing code...

- Roddy

[Ed Mulroy [TeamB]]

I did not know that you had to say 'enum class'. That is better but I would
prefer it be different.

If they want to create a different fundamental type then use a different
keyword for that type. Railing by committee members against adding another
keyword has been going on at least since '90. It at least used to relate to
memory size in tables for parsing and possibly to CPU speed. Those issues
don't really apply. The memory and CPU cycles are already used parsing
'enum' vs 'enum class'.

. Ed

Post by Roddy Pratt

Post by Ed Mulroy [TeamB]
Of course it will.

Not as I understand it. If you want newfangled "scoped enums", you need
to define them as "enum class", rather than plain "enum".
Oldfangled enums, warts and all, are sadly here to stay ;-)
However, this raises another question: Should the PAS -> HPP converter
in the delphi compiler should emit scoped enum types for delphi enums?
My gut feeling is yes, as scoped enums should be a better map to the
Delphi type.
But, I guess there are possible incompatibilites that might require
people to improve certain aspects of existing code...

[Leo Siefert]

Railing by committee members against adding another keyword ...

ISTM that the real argument against adding a new keyword is that it
would break any existing code already using that keyword as a variable
or function name. And keyword bloat makes it more difficult to
remember all of the reserved words as well.

- Leo

[Alan Bellingham]

Post by Leo Siefert
ISTM that the real argument against adding a new keyword is that it
would break any existing code already using that keyword as a variable
or function name. And keyword bloat makes it more difficult to
remember all of the reserved words as well.

And that's the reason for generating new keywords by combining existing
keywords, or reusing existing keywords in contexts where they have no
current meaning.

Alan Bellingham

[Roddy Pratt]

Post by Alan Bellingham
And that's the reason for generating new keywords by combining
existing keywords, or reusing existing keywords in contexts where
they have no current meaning.

Yes, but the end results aren't always pretty. I still can't use const
correctly without reading the documentation:

class a {
void const MyFunction(const char * const aString) const;
};

- Roddy

[Alan Bellingham]

Post by Roddy Pratt
Yes, but the end results aren't always pretty. I still can't use const
class a {
void const MyFunction(const char * const aString) const;
};

I see.

Does that actually compile?

(OK, Comeau considers that first 'const' to be meaningless. Just a
warning, then, not an error.)

In general, 'const' always applies to whatever is to its left. There's
only one case when this isn't the case, and that's when there is
*nothing* to its left, and then the language gets all helpful, and lets
you apply it to the item immediately to its right.

(I consider this a mistake, because it's inconsistent, and therefore
confusing, and you are my evidence!)

If the 'const' is to the right of the whole of the rest of the function
declaration, then function itself is const, i.e., it doesn't effect
'*this'.

Alan Bellingham

[Roddy Pratt]

Post by Alan Bellingham
Does that actually compile?
(OK, Comeau considers that first 'const' to be meaningless. Just a
warning, then, not an error.)

RADStudio didn't warn me, but I guessed it was meaningless.

Post by Alan Bellingham
(I consider this a mistake, because it's inconsistent, and therefore
confusing, and you are my evidence!)

Happy to be of use ;-)

Post by Alan Bellingham
If the 'const' is to the right of the whole of the rest of the
function declaration, then function itself is const, i.e., it doesn't
effect '*this'.

The problem is that other keywords which affect the function itself
belong at the left - static, extern, etc...

IMO, reusing existing keywords in new and 'interesting' ways is making
the language significantly harder to read, learn and use. As Ed says,
avoiding breakage to existing code is a worthy goal, but one that
causes long-term pain in the future to all users of the language.

- Roddy

[Hendrik Schober]

[confusion about const member function syntax]
The problem is that other keywords which affect the function itself
belong at the left - static, extern, etc...
IMO, reusing existing keywords in new and 'interesting' ways is making
the language significantly harder to read, learn and use. [...]

Your example, however, doesn't fall into this category.

- Roddy

Schobi

[Roddy Pratt]

Post by Hendrik Schober
Your example, however, doesn't fall into this category.

I'm so sorry. Is this any better?

void const MyFunction(char const * const const * aString ) const;

And yes, that compiles in Radstudio, and no, I do not *entirely*
understand it... Is the fourth const bound to the right, or is it
duplicating the third? I frankly have no idea.

But actually, it's almost irrelevant whether you find it easy to read
or not. Chances are, someday someone dumber than me (and a LOT dumber
than you) will have the unenviable task of trying to work out a: what
it actually does vs b: what I thought it did vs. c: what it actually
needs to do. It's those folk that you need to be writing code for, not
yourself.

- Roddy

[Hendrik Schober]

Post by Roddy Pratt

Post by Hendrik Schober
Your example, however, doesn't fall into this category.

I'm so sorry. Is this any better?
void const MyFunction(char const * const const * aString ) const;

No. It's still not an example of causing confusion by reusing an
existing keyword.

Post by Roddy Pratt
[...]
But actually, it's almost irrelevant whether you find it easy to read
or not. Chances are, someday someone dumber than me (and a LOT dumber
than you) will have the unenviable task of trying to work out a: what
it actually does vs b: what I thought it did vs. c: what it actually
needs to do. It's those folk that you need to be writing code for, not
yourself.

Actually, it would take me too long to decode the meaning of
every 'const' in that to bother for a newsgroup posting. Which
is why I would avoid this code. (A few 'typedef's would help a
lot with this.) Or it's the other way 'round: Since I avoid
such code, I'm not used to having to read it...
However, it's got nothing to do with reusing keywords.

Post by Roddy Pratt
- Roddy

Schobi

[Roddy Pratt]

Post by Roddy Pratt
void const MyFunction(char const * const const * aString ) const;
No. It's still not an example of causing confusion by reusing an
existing keyword.

I think we're at cross purposes ;-) I thought you meant it didn't
confuse you, but I belive you meant that it wasn't an example of
keyword reuse.

However, I'd disagree: C++ recycled ANSI C's "const" keyword for member
functions, changing the meaning from "this data object cannot be
modified" to "this member function does not modify it's object".

- Roddy

[Hendrik Schober]

Post by Roddy Pratt
[...]
I think we're at cross purposes ;-) I thought you meant it didn't
confuse you, but I belive you meant that it wasn't an example of
keyword reuse.

Exactly.

Post by Roddy Pratt
However, I'd disagree: C++ recycled ANSI C's "const" keyword for member
functions, changing the meaning from "this data object cannot be
modified" to "this member function does not modify it's object".

You're wrong, though. 'const' was a C++ invention which found
its way back into C. :)

Post by Roddy Pratt
- Roddy

Schobi

[Alan Bellingham]

Post by Roddy Pratt
However, I'd disagree: C++ recycled ANSI C's "const" keyword for member

However, I'd disagree: C++ recycled C++'s "const" keyword for member

Post by Roddy Pratt
functions, changing the meaning from "this data object cannot be
modified" to "this member function does not modify it's object".

modified" to "this data object cannot be modified by this member
function".

I made a couple of corrections for you.

'const' *was* a new keyword that C++ brought in, and its meaning is
pretty consistent. It *always* means 'this object cannot be modified'.
The three places it's seen (that I can think of) are

type const Identifier;

The object to which the name Identifier refers may not be modified.

void f(type const& Identifier);
void f(type const* Identifier);

The object to which the name Identifier refers may not be modified
within the function f().

class g {
void f() const;
} Identifier;

The object to which the name Identifier refers may not be modified
within the member function f().

The only marginally tricky bit of syntax is that last one, where the
const is after the parameter list. But if you're having problems with
that, and not with pointer syntax (which is a huge pile of worms), then
I can only assume that your introduction to 'const' was a badly
confusing one.

(I'd blame the 'leftmost const' rule for that.)

'static', now ... oh, my! C99's new overloading of the static keyword is
the most egregious:

void foo(int a[static 10]);

Eeep!

Alan Bellingham

[Hendrik Schober]

Post by Alan Bellingham
[...]
'static', now ... oh, my! C99's new overloading of the static keyword is
void foo(int a[static 10]);

What is this?

Post by Alan Bellingham
Eeep!
Alan Bellingham

Schobi

[Alan Bellingham]

Post by Hendrik Schober

Post by Alan Bellingham
void foo(int a[static 10]);

What is this?

It's how you tell C99 that you're really passing an array of 10 (or
more) elements. (C99 6.7.5.3/7)

Alan Bellingham

[Hendrik Schober]

Post by Alan Bellingham

Post by Hendrik Schober

Post by Alan Bellingham
void foo(int a[static 10]);

What is this?

It's how you tell C99 that you're really passing an array of 10 (or
more) elements. (C99 6.7.5.3/7)

Thanks. I am really amazed that they were able to find
yet another meaning for 'static'...

Post by Alan Bellingham
Alan Bellingham

Schobi

[Chris Uzdavinis (TeamB)]

Post by Roddy Pratt

Post by Hendrik Schober
Your example, however, doesn't fall into this category.

I'm so sorry. Is this any better?
void const MyFunction(char const * const const * aString ) const;

The rule is "const" modifies the thing to its left, unless there isn't
anything there, in which case it modifies the thing to its right.

Strictly following that rule, I would say that the first const (on the
return type) is strange, and while perhaps not strictly invalid,
utterly meaningless and therefore confusing.

The next const (reading left to right) makes the (char) data const.
The third one makes the pointer to that data const. The fourth also
attempts to make the same pointer const, duplicating qualifiers
and therefore making the code invalid.

One might say "there's nothing to the left of the third const, so it
modifies the thing to its right, but that's not really true. There
still is a pointer to its left, but it's just a little farther away
(past the previous const qualifier). That there's already a const
qualifier doesn't make it go away.

To visualize it, the square brackets show what each const is
associated with, except for the final one making the whole function
const, which I omitted.

[void const] MyFunction( [char const] [[* const] const] * aString )
^^^^^
|
duplicate qualifiers is an error

Post by Roddy Pratt
And yes, that compiles in Radstudio, and no, I do not *entirely*
understand it... Is the fourth const bound to the right, or is it
duplicating the third? I frankly have no idea.

There's a thing to its left, so it is duplicating the third, and is
invalid.

Post by Roddy Pratt
But actually, it's almost irrelevant whether you find it easy to
read or not. Chances are, someday someone dumber than me (and a LOT
dumber than you) will have the unenviable task of trying to work out
a: what it actually does vs b: what I thought it did vs. c: what it
actually needs to do. It's those folk that you need to be writing
code for, not yourself.

I think that typedefs would help here, and hopefully coding style
would lead to a conclusion similar to: "more than one levels of
pointers are undesireable, and more than 2 levels are not tolerable."
Indirection works great for computers but is hard for humans, even
with just one or two levels. Exceed that and you're just asking for
trouble. :)

[Leo Siefert]

Post by Roddy Pratt
IMO, reusing existing keywords in new and 'interesting' ways
is making the language significantly harder to read,

Yet in your own example I think that adding a different keyword that
means "const" for a different part of the expression would be more
confusing than using a single keyword that always can be placed to the
right of the token it modifies.

For English speakers, it might seem more like natural language to have
the modifier precede the token, but then how would a const function be
differentiated from a function returning a const value?

- Leo

[Ed Mulroy [TeamB]]

'keyword bloat' is not a valid argument. 'class enum' is the new keyword.

Breaks existing code is a valid argument that has been violated before.
Assume the new keyword is 'classenum'. Think of the difficulties of the 17
programs using that name for which 4 are still actively supported. They
will need a simple search and replace before meeting the new standard.

Remembering all the reserved words is another red herring. 'class enum'
means they have to remember the new, 2-word keyword. They need to remember
the various library items, including the massive number of them brought in
from Boost. They already must be able to parse stilted syntax. The
arguments about keywords echo the same arguments that ran through the C
crowd from its inception and related more to memory and cpu speed
limitations. The days when Bjarne said you need serious computing power, at
least a 1 meg machine with 10 or more meg of memory are long gone.

. Ed

Post by Leo Siefert

Railing by committee members against adding another keyword ...

ISTM that the real argument against adding a new keyword is that it
would break any existing code already using that keyword as a variable
or function name. And keyword bloat makes it more difficult to
remember all of the reserved words as well.

[Hendrik Schober]

Post by Ed Mulroy [TeamB]
'keyword bloat' is not a valid argument. 'class enum' is the new keyword.
Breaks existing code is a valid argument that has been violated before.
Assume the new keyword is 'classenum'. Think of the difficulties of the 17
programs using that name for which 4 are still actively supported. They
will need a simple search and replace before meeting the new standard.

www.google.de/search?hl=de&q=%22classenum%22 actually finds
identifiers 'classenum'. (The first hit I saw was #21 and I
immediately stopped looking for more.) This simple search
suggests that there might be a few more than 17 applications
using this as an identifier.
Worse yet, there's obviously a lot of code out there using
'ClassEnum' or 'classEnum' as an identifier. Adding this
keyword would make those programs automatically use the moral
equivalent to 'If', 'Class', and 'While' as keywords. That's
really bad.

Post by Ed Mulroy [TeamB]
[IMO valid arguments removed]
. Ed

Schobi

[Ed Mulroy [TeamB]]

I did not say it should be 'classenum'. I said "assume the new keyword is
'classenum'. Use any term you want. Pick one you think is little used.

As for >21 search hits, so? Pick another term. Neither 'class enum' nor
'classenum' are cast in stone.

Post by Hendrik Schober

Post by Ed Mulroy [TeamB]
[IMO valid arguments removed]

Interesting. I was beginning to think that any argument I posted on here
would be received as de-facto invalid :-)

. Ed

Post by Hendrik Schober
www.google.de/search?hl=de&q=%22classenum%22 actually finds
identifiers 'classenum'. (The first hit I saw was #21 and I
immediately stopped looking for more.) This simple search
suggests that there might be a few more than 17 applications
using this as an identifier.
Worse yet, there's obviously a lot of code out there using
'ClassEnum' or 'classEnum' as an identifier. Adding this
keyword would make those programs automatically use the moral
equivalent to 'If', 'Class', and 'While' as keywords. That's
really bad.

Post by Ed Mulroy [TeamB]
[IMO valid arguments removed]

[Hendrik Schober]

Post by Ed Mulroy [TeamB]
I did not say it should be 'classenum'. I said "assume the new keyword is
'classenum'. Use any term you want. Pick one you think is little used.
As for >21 search hits, so?

There were thousands, since helpful google tried to second-
guess me. I said No. 21 was the first exact hit. I have no
idea how many more exact hits there were, since I stopped
looking after the first.
I stopped because I considered the amount of C/C++ code
found by google marginal compared to the amount of code out
there.

Post by Ed Mulroy [TeamB]
Pick another term. Neither 'class enum' nor
'classenum' are cast in stone.

1. Pick any other term you want that has vague resemblance
to its intended use and is shorter than a dozen letters.
2. Repeat what I did.
3. Goto 1.

Post by Ed Mulroy [TeamB]
[...]
. Ed

Schobi

[Leo Siefert]

Post by Ed Mulroy [TeamB]
Interesting. I was beginning to think that any argument
I posted on here would be received as de-facto invalid :-)

Not sure if that was directed at a particular individual, but I for
one tend to find your arguments at worst amusing.

Skepticism for bells and whistles or change for the sake of change can
help keep others grounded - the fanciest code using the latest
techniques is not always the best code to get the job done.

And, by the way, I do agree that the C++ committee has gone too far in
avoiding the addition of new keywords when it results in the language
being difficult for a human to parse.

- Leo

[Chris Uzdavinis (TeamB)]

Post by Leo Siefert
And, by the way, I do agree that the C++ committee has gone too far in
avoiding the addition of new keywords when it results in the language
being difficult for a human to parse.

I do too. (And Stroustroup does too, if I remember him correctly.
Somehow the community seems adverse to the idea, and so the pressure
is on. But keywords are relatively rare, and clashes are so easy to
resolve that the problem is almost laughable. (Except for code
generators that happen to generate code that isn't compatible, or
libraries that you have no control over. Then change depends on
others to do it for you and they might not even still be in business
or supporting that software, etc.) But in general, it's not a big
deal.

For your own code, just rename the variables.

For libraries, you can rename variables in headers and just have a
local update to the standard delivered versions. Not desirable, but
doable.

For code generators, especially if they're invoked by your build
system, you can modify the build rules to run an extra
post-generation-processor over the files, to rename generated variable
names that collide. Not terribly hard if you just wrap the invocation
of the build tool with a shell script that calls the processor.


None are especially fun, but libraries and code generators are rather
unlikely to be a problem, so the description is mostly a "thought
exercise".

[Leo Siefert]

Post by Ed Mulroy [TeamB]
'keyword bloat' is not a valid argument. 'class enum' is the new keyword.

Should have said "reserved word bloat". Adding "class enum" does not
increase the number of reserved words. As a programmer, I do not have
to know that it is considered a single symbol by the compiler until I
decide to learn how to use it in my programs.

IMO, languages with a large number of reserved words are problematic
to use (and I have used some). It sometimes is difficult to determine
that the cause of a problem is that a function name I have used is a
reserved word that I have not memorized.

If "class enum" is added to the language, I do not have to even know
about it to continue with my work as before. If "classenum" is added I
do have to get the notice or my code may be broken.

You may not think it is an important argument, but it is valid.

Post by Ed Mulroy [TeamB]
Remembering all the reserved words is another red herring.
'class enum' means they have to remember the new, 2-word keyword

Why? Reserved words need to be avoided when I name my own variables
and functions, so I need to be familiar with all of them. Haw can
adding "class enum" to the language affect me at all if I choose to
remain ignorant of it (as I suspect most users will for a number of
years).

Sure, if I want to stay on top of the new developments in the language
there is almost no difference between adding "class enum" and adding
"classenum" to the language - either way I'll learn to use it
properly. But if I don't quickly consume the new standard when it is
implemented, "classenum" could hut me, "class enum" could not.

- Leo

[Ed Mulroy [TeamB]]

...Adding "class enum" does not
increase the number of reserved words...

Have you considered offering your services to one of Obama or McCain to
construct political arguments. :)

No, it does not increase the number of reserved words. It is a phrase so
increases the number of reserved phrases. With today's CPU speeds and
memory sizes, one more entry in the compiler's table of reserved words is of
minimal importance. An additional entry in the programmer's mind is the
issue and here we have a phrase to add to the table of words.

One other things:

At one level:

Look at the similar manner in which a class, a struct and an enum are
defined. They are specific, brace-enclosed entities, each with specific
rules on what is enclosed. Each is a specific concept, different from the
others. Now class is combined with the different but somewhat similar
looking in definition enum to form yet another, analagous to saying 'class
struct' or 'struct class' or 'struct enum'. The symantically inconsistency
annoys me. Using 'classenum' also annoys me but I was throwing in a word as
a place holder in describing things. The argument that 'classenum' is not a
good selection is not material. I have no dog in that fight.

At another level:

TPTB in C++ seem to have never felt overly burdened by a need for things to
have a relation between a word's meaning, if it has any, and its meaning in
the language. I contend that when possible, a word with a relationship be
used as it enhances understanding. C++ is growing in a PL/I fashion and
people routinely use some subset of it in what they do, using other things
infrequently. That relationship helps them when using those infrequently
used items. I admit that 'classenum' kind of passes this test although
'class enum' arguably does not.

Of course they could something similar to what was done by picking 'pragma',
an obscure word whose only meaning that I know of dealt with styles of love.
Essentially it is a newly coined term without meaning to which they assigned
a meaning. Perhaps they should have considered 'constrotinangle' :)

Third level:

Number of reserved words is a red herring. To use C++ you need to know the
words important to using the language and that includes those in the base
language and those in the libraries. If we need a new item for an
enumurated type which has strong typing and does not implicitly convert then
of course it should be added. However the differences from 'enum' are
enough that I wonder about why 'enum' would be used in its name at all. For
example, it is much further removed than the difference between 'class' and
'struct' yet those two have totally different names.

. Ed

Post by Ed Mulroy [TeamB]
'keyword bloat' is not a valid argument. 'class enum' is the new keyword.

Should have said "reserved word bloat". Adding "class enum" does not
increase the number of reserved words. As a programmer, I do not have
to know that it is considered a single symbol by the compiler until I
decide to learn how to use it in my programs.
IMO, languages with a large number of reserved words are problematic
to use (and I have used some). It sometimes is difficult to determine
that the cause of a problem is that a function name I have used is a
reserved word that I have not memorized.
If "class enum" is added to the language, I do not have to even know
about it to continue with my work as before. If "classenum" is added I
do have to get the notice or my code may be broken.
You may not think it is an important argument, but it is valid.

Post by Ed Mulroy [TeamB]
Remembering all the reserved words is another red herring.
'class enum' means they have to remember the new, 2-word keyword

Why? Reserved words need to be avoided when I name my own variables
and functions, so I need to be familiar with all of them. Haw can
adding "class enum" to the language affect me at all if I choose to
remain ignorant of it (as I suspect most users will for a number of
years).
Sure, if I want to stay on top of the new developments in the language
there is almost no difference between adding "class enum" and adding
"classenum" to the language - either way I'll learn to use it
properly. But if I don't quickly consume the new standard when it is
implemented, "classenum" could hut me, "class enum" could not.

[Hendrik Schober]

Post by Ed Mulroy [TeamB]
[...]
Number of reserved words is a red herring. To use C++ you need to know the
words important to using the language and that includes those in the base
language and those in the libraries. [...]

You don't. Your own identifiers can't clash with the std lib's.

Post by Ed Mulroy [TeamB]
. Ed

Schobi

[Ed Mulroy [TeamB]]

Clash is but a small issue, probably tiny rather than small as you'll
usually get a diagnostic. Having to know the larger number of names to use
them is the big one.

. Ed

Post by Hendrik Schober

Post by Ed Mulroy [TeamB]
Number of reserved words is a red herring. To use C++ you need to know
the words important to using the language and that includes those in the
base language and those in the libraries. [...]

You don't. Your own identifiers can't clash with the std lib's.

[Hendrik Schober]

Post by Ed Mulroy [TeamB]
Clash is but a small issue, probably tiny rather than small as you'll
usually get a diagnostic. Having to know the larger number of names to use
them is the big one.

IMO that depends on your code base.

Post by Ed Mulroy [TeamB]
. Ed
[...]

Schobi

[Leo Siefert]

Post by Ed Mulroy [TeamB]
Have you considered offering your services to one of
Obama or McCain to construct political arguments. :)

I work for the state senate.

Post by Ed Mulroy [TeamB]
It is a phrase so increases the number of reserved phrases.

Seems like you are the one trying to obscure the argument by fanciful
language here to me. There is no such thing as a "reserved phrase" in
any language description I have ever seen. Have you ever seen a case
where, for instance "loop while" is reserved, but "loop" and "while"
are not?

Post by Ed Mulroy [TeamB]
An additional entry in the programmer's mind is the
issue and here we have a phrase to add to the table of words.

Either you missed my point here or you are sidestepping it. Adding a
language feature to C++ that uses two or more reserved words does not
mean that I have to keep in my head more reserved words since both
parts of it are already there. It is a valid argument. But as I
already stated it may not be an important one. Clarity of syntax is
another valid argument and it may be far more important.

Post by Ed Mulroy [TeamB]
people routinely use some subset of it in what they do,
using other things infrequently.

Which is why the addition of "class enum" will have absolutely no
impact on most users. It can be completely ignored with no consequence
on their work. The addition of "classenum" or "scopedenum" or
"mysuperdooperenum" could affect their work.

On the other hand, the addition of 'scopedenum" or "scoped enum" would
have the distinct advantage of a correspondence between the keyword
and the name of the new feature. I do agree with you that that seems
like a more compelling argument.

Post by Ed Mulroy [TeamB]
I admit that 'classenum' kind of passes this test although
'class enum' arguably does not.

I see both as equally obscure and the former has the disadvantage of
adding a reserved word.

Post by Ed Mulroy [TeamB]
Number of reserved words is a red herring.

Not to anyone who has worked in a language with thousands of them. You
don't put "using namespace std;" in all of your headers do you?

Post by Ed Mulroy [TeamB]
To use C++ you need to know the words important to using the language
and that includes those in the base language and those in the libraries.

And that's why the libraries are now in namespaces, You can choose
exactly which of the set of defined symbols to dump into your
namespace from included libraries. The language itself has very few
reserved words, and it is not possible to fence off any of them from
your code.

Post by Ed Mulroy [TeamB]
the differences from 'enum' are enough that I wonder about
why 'enum' would be used in its name at all.

Not really familiar with use of scoped enums yet, but from my first
look they seem very much like enums to me and I would be most
comfortable with them retaining that term.

Post by Ed Mulroy [TeamB]
For example, it is much further removed than the difference between
'class' and 'struct' yet those two have totally different names.

Almost anything is further removed that the difference between class
and struct. I suspect class was added only to keep in line with OO
terminology. If I were designing the language I would probably have
reserved "struct" for strictly C style structs.

- Leo

[Chris Uzdavinis (TeamB)]

Post by Leo Siefert
Seems like you are the one trying to obscure the argument by fanciful
language here to me. There is no such thing as a "reserved phrase" in
any language description I have ever seen. Have you ever seen a case
where, for instance "loop while" is reserved, but "loop" and "while"
are not?

I think Ed means that in preserving the number of reserved words, the
number of concepts continues to grow, so by mixing existing keywords
to build a new meaning, it's essentially equivalent to a new keyword,
just more confusing.

Not that the new standard really is without new keywords already...

Post by Leo Siefert
Either you missed my point here or you are sidestepping it. Adding a
language feature to C++ that uses two or more reserved words does not
mean that I have to keep in my head more reserved words since both
parts of it are already there. It is a valid argument. But as I
already stated it may not be an important one. Clarity of syntax is
another valid argument and it may be far more important.

As I understand your point, new combinations of existing keywords may
introduce new features, but if you don't opt to learn all the
combinations, the old behaviors and semantics still work as before.
That is, even being ignorant of the new combinations, you aren't going
to accidently get any surprising change of behavior of existing
code.

I agree with you and Ed at the same time, and don't see an argument.
:)

Post by Leo Siefert
Which is why the addition of "class enum" will have absolutely no
impact on most users. It can be completely ignored with no consequence
on their work. The addition of "classenum" or "scopedenum" or
"mysuperdooperenum" could affect their work.

Until you run into code using it, and you're tasked with maintaining
it. Then suddenly it matters. (But it's good that you can defer
learning things until it matters. That way we don't waste time
learning things that DONT matter!)

Post by Leo Siefert
Not really familiar with use of scoped enums yet, but from my first
look they seem very much like enums to me and I would be most
comfortable with them retaining that term.

I agree. One of the main important difference is that you can
forward-declare the enum, and implement its enumerators in a .cpp
file. This, of course, requires the compiler knowing the size of the
enum without having the benefit of looking at the enumerators and
choosing the best representation. So the programmer can specify the
underlying type. Pretty simple, and still true to what an enum is.

When using this enum, the benefit becomes obvious. Suppose your class
has a private member enum type that nobody else uses, and is included
by hundreds of cpp files. If you need to add an enumeration--an
internal implementaion detail of your class--you must edit the header
just to add the new enumerator, causing a re-compile of all the other
hundreds of source files that depend on the header.

[Ed Mulroy [TeamB]]

Post by Chris Uzdavinis (TeamB)
I think Ed means that in preserving the number of reserved words,
the number of concepts continues to grow, so by mixing existing
keywords to build a new meaning, it's essentially equivalent to a
new keyword, just more confusing.

You said it far better than I. Thank you.

. Ed

[Leo Siefert]

Post by Ed Mulroy [TeamB]
You said it far better than I. Thank you.

Actually, if you could not tell, I pretty much agreed with your main
point all along. I just disagreed with you dismissing the
counter-argument as "invalid" and a "red herring". I do not like the
new terminology either.

And BTW - just to point out the level of confusion, I think all
references to the new keyword in this thread have been to "class
enum". I just checked and in the latest draft of the standard that I
have the actual term is "enum class" or "enum struct", so even we seem
to be easily confused by it. (Or did it change in a later draft?)

- Leo

[Chris Uzdavinis (TeamB)]

Post by Leo Siefert

Post by Ed Mulroy [TeamB]
You said it far better than I. Thank you.

Actually, if you could not tell, I pretty much agreed with your main
point all along. I just disagreed with you dismissing the
counter-argument as "invalid" and a "red herring". I do not like the
new terminology either.
And BTW - just to point out the level of confusion, I think all
references to the new keyword in this thread have been to "class
enum". I just checked and in the latest draft of the standard that I
have the actual term is "enum class" or "enum struct", so even we seem
to be easily confused by it. (Or did it change in a later draft?)

As we get closer to the FDIS of the new standard, and the certainty of
the draft wording becomes more and more likely to become official,
I'll start getting more and more pedantic about terms, concepts, and
phrasing. But until then, since things may change, I'll be
comfortable remaining fairly loose with terms. :)

[Alan Bellingham]

Post by Leo Siefert
And BTW - just to point out the level of confusion, I think all
references to the new keyword in this thread have been to "class
enum". I just checked and in the latest draft of the standard that I
have the actual term is "enum class" or "enum struct", so even we seem
to be easily confused by it. (Or did it change in a later draft?)

I mentioned it being enum class a week ago. And pointed out the
Wikipedia link.

But it doesn't really matter too much - get the parts of the keyword the
wrong way round and it will fail to compile. It won't compile with
different meaning, it will merely do what that pair of words have always
done up until now.

The rationale for taking a character sequence that currently fails to
compile (that is, 'enum class') and giving it meaning is that nobody has
to check any existing code to see if it breaks with the new meaning.

Alan Bellingham

[Roddy Pratt]

Post by Alan Bellingham
The rationale for taking a character sequence that currently fails to
compile (that is, 'enum class') and giving it meaning is that nobody
has to check any existing code to see if it breaks with the new
meaning.

Makes sense, but I do hope that's "actually fails to compile with the
majority of compilers in regular use" rather than "theoretically fails
to compile with a 'perfect' standard-compliant compiler which may or
may not exist...".

- Roddy

[Alan Bellingham]

Post by Roddy Pratt
Makes sense, but I do hope that's "actually fails to compile with the
majority of compilers in regular use" rather than "theoretically fails
to compile with a 'perfect' standard-compliant compiler which may or
may not exist...".

As far as I can see, any code that relies on 'enum class' compiling with
*any* existing compiler (or as far back as when C-with-classes settled
on 'class' as a keyword) is badly broken in an interesting way.

Assume this actually compiled, somehow managing to avoid interpreting
'class' as the actual keyword, and managing to treat it as an
identifier:

enum class { x, y, z };

You've defined a variable named 'class'.

Now how do you get an expression that actually could make use of it?

Actually, compiler technology is based on lexing followed by parsing.
The moment the lexer saw the letter sequence 'class', without
letters/digits immediately next to either end, it would return a code
meaning 'the keyword class' rather than 'an identifier, whose name is
"class"'. The only way to avoid this is to start playing very strange
games with the compiler, to basically force it to special-case the
returned token, and compiler writers don't do that if they don't have a
very good reason for it.

(One place in C++0X where they do do this is in the new rule that you
can close a nested template declaration with '>>' rather than needing
'> >'. I know of no other case.)

The only way I can think of that code compiling is by using a
preprocessor macro so the compiler itself never sees those words. In
which case, nor would a C++0x one.

Alan Bellingham

[Chris Uzdavinis (TeamB)]

Post by Alan Bellingham
But it doesn't really matter too much - get the parts of the keyword the
wrong way round and it will fail to compile. It won't compile with
different meaning, it will merely do what that pair of words have always
done up until now.

Or, the 'enum' affects the class to its left, unless there is no class
to its left, in which case it affects the class to its right...

:)

[Alan Bellingham]

Post by Chris Uzdavinis (TeamB)
Or, the 'enum' affects the class to its left, unless there is no class
to its left, in which case it affects the class to its right...

NNNOOOOooooo.......

Alan Bellingham

[Duane Hebert]

Post by Chris Uzdavinis (TeamB)

Post by Alan Bellingham
But it doesn't really matter too much - get the parts of the keyword the
wrong way round and it will fail to compile. It won't compile with
different meaning, it will merely do what that pair of words have always
done up until now.

Or, the 'enum' affects the class to its left, unless there is no class
to its left, in which case it affects the class to its right...
:)

Yikes. Can you kill this post before someone without
a sense of humor reads it and thinks it's a good idea?

[Alex Bakaev [TeamB]]

Post by Duane Hebert
Yikes. Can you kill this post before someone without
a sense of humor reads it and thinks it's a good idea?

Too late. Ed has read this already <G>

[Dennis Cote]

Post by Leo Siefert
Why? Reserved words need to be avoided when I name my own variables
and functions, so I need to be familiar with all of them.

No you don't. You can safely ignore the new reserved word as long as you
use a compliant compiler. If you ever use the new reserved word as an
identifier, your compiler will immediately tell you that you have an
problem. Until that happens there is no need to be aware of, or familiar
with, the new reserved word unless you want to use the new feature.

No one writes large programs with thousands of lines of code spread over
hundreds of files without ever running it through the compiler. In the
normal course of events you will be notified the first time you compile
a file using the new reserved word, and at that point the fix is a
trivial search and replace in one or two files.

Dennis Cote

[Hendrik Schober]

Post by Dennis Cote

Post by Leo Siefert
Why? Reserved words need to be avoided when I name my own variables
and functions, so I need to be familiar with all of them.

No you don't. You can safely ignore the new reserved word as long as you
use a compliant compiler. If you ever use the new reserved word as an
identifier, your compiler will immediately tell you that you have an
problem. Until that happens there is no need to be aware of, or familiar
with, the new reserved word unless you want to use the new feature.
No one writes large programs with thousands of lines of code spread over
hundreds of files without ever running it through the compiler. In the
normal course of events you will be notified the first time you compile
a file using the new reserved word, and at that point the fix is a
trivial search and replace in one or two files.

That's all fine for the words that are already there. But we're
talking about introducing new keywords into a language which has
a community that sits on gazillions of LoC. Consider you do the
first compiler run with that new compiler version and the 4MLoC
trigger 23k new errors.[1] What are you going to do? See, so would
everyone else.

Post by Dennis Cote
Dennis Cote

Schobi

[1] I have run into the situation where a new compiler version
brought with it >10k new warnings on a 2-3MLoC base. It took
months having a daily script parsing the compiler output and
creating an HTML page with a hall of shame, until we were
down to a couple of dozen warnings again. (We had deadlines
to fight against, after all.) In the end we found <10 useful
ones. Had we have the chance, we'd have switched back to the
old compiler version and delayed upgrading to "some other
time"[TM], but the customer specified the compiler version.

[Dennis Cote]

Post by Hendrik Schober
That's all fine for the words that are already there. But we're
talking about introducing new keywords into a language which has
a community that sits on gazillions of LoC. Consider you do the
first compiler run with that new compiler version and the 4MLoC
trigger 23k new errors.[1] What are you going to do?

Continue to use the old compiler. If it could be compiled successfully
when it was originally built it can still be compiled with that version.

Post by Hendrik Schober
[1] I have run into the situation where a new compiler version
brought with it >10k new warnings on a 2-3MLoC base. It took
months having a daily script parsing the compiler output and
creating an HTML page with a hall of shame, until we were
down to a couple of dozen warnings again. (We had deadlines
to fight against, after all.) In the end we found <10 useful
ones. Had we have the chance, we'd have switched back to the
old compiler version and delayed upgrading to "some other
time"[TM], but the customer specified the compiler version.

Ah, I see you were prepared to do that. Your problem wasn't really with
the new compiler, but instead with your customer's insistence on using
it with legacy code.

New reserved words are only an issue if you try to use a new compiler
(for a slightly revised language) with old code. If it ain't broke,
don't fix it. Stick with the old compiler for legacy code.

In general, if the new compiler works with your legacy code, you don't
have a problem. If not, you can choose to stick with the old compiler
and you still have no problem, or update to the new compiler and make
the changes required to use the new language. You (usually) aren't
forced to update legacy code.

My point was primarily that the mere existence of reserved words doesn't
mean you have to be familiar with them.

Dennis Cote

[Hendrik Schober]

Post by Dennis Cote

Post by Hendrik Schober
That's all fine for the words that are already there. But we're
talking about introducing new keywords into a language which has
a community that sits on gazillions of LoC. Consider you do the
first compiler run with that new compiler version and the 4MLoC
trigger 23k new errors.[1] What are you going to do?

Continue to use the old compiler. If it could be compiled successfully
when it was originally built it can still be compiled with that version.

See, and if the std committee would force this down our
throats, they wouldn't need bother with new standard
versions, since nobody would use them. Which is exactly
why they go out of their way to prevent old code from
breaking. (You never hear from the several million users
who successfully installed some software, but you hear a
lot about those few hundred or thousand who couldn't.)

Post by Dennis Cote

Post by Hendrik Schober
[1] I have run into the situation where a new compiler version
brought with it >10k new warnings on a 2-3MLoC base. It took
months having a daily script parsing the compiler output and
creating an HTML page with a hall of shame, until we were
down to a couple of dozen warnings again. (We had deadlines
to fight against, after all.) In the end we found <10 useful
ones. Had we have the chance, we'd have switched back to the
old compiler version and delayed upgrading to "some other
time"[TM], but the customer specified the compiler version.

Ah, I see you were prepared to do that. Your problem wasn't really with
the new compiler, but instead with your customer's insistence on using
it with legacy code.

That surely is a funny look onto things. Wherever I worked
in the last decade 90% of the code was several years old (up
to a decade) and often only around 2% was written anew for
some project. Every single customer, every single project,
and every single off-the-shelf product required working with
lots of legacy code. If we had refused to port legacy code
to newer compiler, we would have had to work with ten year
old ones.

Post by Dennis Cote
New reserved words are only an issue if you try to use a new compiler
(for a slightly revised language) with old code. If it ain't broke,
don't fix it. Stick with the old compiler for legacy code.
In general, if the new compiler works with your legacy code, you don't
have a problem. If not, you can choose to stick with the old compiler
and you still have no problem, or update to the new compiler and make
the changes required to use the new language. You (usually) aren't
forced to update legacy code.

I have no idea what kind of work you do, but be assured it
isn't like this for all the rest of the industry. Some of us
have to maintain decade old legacy code and will have to
earn their money doing so for another decade.
Code is assembled intellectual property. There's ideas in it
from people who have long since left and right now there
might be nobody in the company who's able to re-do what they
did. (Not because they are stupid, but because they are
specializing in other things.) You wouldn't throw this out
the window just because compilers change over a decade, would
you?

Post by Dennis Cote
My point was primarily that the mere existence of reserved words doesn't
mean you have to be familiar with them.

And my point was that, should new reserved words arise, some
of us could have a hell of a year trying to adapt several
MLoC to make them compile.

Post by Dennis Cote
Dennis Cote

Schobi

[Dennis Cote]

Post by Hendrik Schober
See, and if the std committee would force this down our
throats,

Nobody is forcing anybody to do anything.

If you choose to migrate forward, you may need to port some legacy code.
If you choose to continue using the older compiler, you leave your code
as is and find something else to do.

Post by Hendrik Schober
If we had refused to port legacy code
to newer compiler, we would have had to work with ten year
old ones.

Yes you might have had to do that if the code hadn't been updated for
that long. If you did, it would have been your choice. Those ten year
old compilers still work just as well today as they did ten years ago
when that code was written.

If you choose not to use the old compiler, you need to be prepared to
port the code. This is exactly what you say you chose to do, and
eventually did.

Post by Hendrik Schober
And my point was that, should new reserved words arise, some
of us could have a hell of a year trying to adapt several
MLoC to make them compile.

And I think you are exaggerating to make a point. How many times does
the identifier "classenum" actually appear in your several MLoC? I doubt
you will find a single instance. Even if you did, it can be fixed with a
simple search and replace in far less than a year.

Dennis Cote

[Hendrik Schober]

Post by Dennis Cote

Post by Hendrik Schober
See, and if the std committee would force this down our
throats,

Nobody is forcing anybody to do anything.

I know, and I am defending this.

Post by Dennis Cote
If you choose to migrate forward, you may need to port some legacy code.
If you choose to continue using the older compiler, you leave your code
as is and find something else to do.

And if your business is nuild on legacy code, you're
not allowed to move forward? When I write 100k lines
of new code, should I be forbitten to use modern C++,
because there's another MLoC which didn't use it? Had
we worked that way in some projects I was involved in,
they would have had to be burried after half a decade.

Post by Dennis Cote

Post by Hendrik Schober
If we had refused to port legacy code
to newer compiler, we would have had to work with ten year
old ones.

Yes you might have had to do that if the code hadn't been updated for
that long. [...]

You misunderstood. If you work on big projects, at any
given time you have 90% of legacy code. If you cannot
port them /now/ to newer compilers, libs, tools, you can
/never/ port them. Porting huge amounts of legacy code
to new compilers is a continous battle you fight. If a
new compiler comes along and makes this /really/ hard,
you're doomed.

Post by Dennis Cote
[...]
Dennis Cote

Schobi

[Alex Bakaev [TeamB]]

Post by Roddy Pratt
However, this raises another question: Should the PAS -> HPP converter
in the delphi compiler should emit scoped enum types for delphi enums?
My gut feeling is yes, as scoped enums should be a better map to the
Delphi type.

That it should. The fact each .hpp ends with the using statement blows bad.

[Chris Uzdavinis (TeamB)]

Post by Ed Mulroy [TeamB]
Which means that the language will no longer have enum, just something else
using the name enum but for the old style enum perhaps one can then use a
#define.
The language keeps getting bigger and bigger but existing problems such as
arcane syntax are retained.

Actually, enum will continue to exist exactly as it is, and you have
to opt-in to use the new features by using a syntax that never
compiled before (so there is no possibility of breaking old code.)

[Ed Mulroy [TeamB]]

Yes, a new, 2-word keyword is created, and to introduce confusion, one of
the words is the keyword for a different type. Exactly what I am
complaining about.

. Ed

Post by Chris Uzdavinis (TeamB)
Actually, enum will continue to exist exactly as it is, and you have
to opt-in to use the new features by using a syntax that never
compiled before (so there is no possibility of breaking old code.)

[Chris Uzdavinis (TeamB)]

Post by Ed Mulroy [TeamB]
Yes, a new, 2-word keyword is created, and to introduce confusion, one of
the words is the keyword for a different type. Exactly what I am
complaining about.

What's a new standard with a little grumbling, anyway?

Besides, I'd suggest you reserve judgement on the enum issue. There
are far, far more sweeping changes to be unhappy about. :)

[Ed Mulroy [TeamB]]

...There are far, far more sweeping changes to be unhappy about. :)

Agreed.

Even some old proposed (and supposedly added or adding) items gall me.

Probably not the best selected examples:

- Adding file and directory search classes to the language that
internally use search functions that are not part of the language.

- No proposed alternative syntax for templates, particularly complex
specializations (not referring to the class 'complex'). I don't care if a
compiler can parse them easily. I need to spend what little mental
mousepower that I have on cutting good code and not on parsing
obscure syntax. Tired at midnight as I am debugging code which
TPTB have declared MUST ship last week it would be nice to think
about diagnosing the problems and not about what the heck some
arcane syntax means.

. Ed

Post by Ed Mulroy [TeamB]
Yes, a new, 2-word keyword is created, and to introduce confusion,
one of the words is the keyword for a different type. Exactly what I
am complaining about.

What's a new standard with a little grumbling, anyway?
Besides, I'd suggest you reserve judgement on the enum issue. There
are far, far more sweeping changes to be unhappy about. :)

[Chris Uzdavinis (TeamB)]

Post by Ed Mulroy [TeamB]
- No proposed alternative syntax for templates, particularly complex
specializations (not referring to the class 'complex'). I don't care if a
compiler can parse them easily. I need to spend what little mental
mousepower that I have on cutting good code and not on parsing
obscure syntax. Tired at midnight as I am debugging code which
TPTB have declared MUST ship last week it would be nice to think
about diagnosing the problems and not about what the heck some
arcane syntax means.

The new Concepts proposal offers a lot of promise on improving
template error messages and helping ensure that parameters meet the
interface contract. Rather than pages of weird errors that appear in
the internal instantiation of the templates, the error is up-front,
showing just the concept that the type fails to meet.

While it's not improving the syntax, but adding a lot to it (arguably
more complicated if you're writing such code), it will make it much
easier to USE such code that is already written.

[Hendrik Schober]

[...] Tired at midnight as I am debugging code which
TPTB have declared MUST ship last week it would be nice to think
about diagnosing the problems and not about what the heck some
arcane syntax means.

Sounds like the problem is TPTB. :)

. Ed

Schobi

[Alan Bellingham]

Post by Hendrik Schober
Sounds like the problem is TPTB. :)

The problem is *always* TPTB.

(Even when you work for yourself.)

Alan Bellingham

[Hendrik Schober]

Post by Alan Bellingham

Post by Hendrik Schober
Sounds like the problem is TPTB. :)

The problem is *always* TPTB.
(Even when you work for yourself.)

Especially then...

Post by Alan Bellingham
Alan Bellingham

Schobi

[Ed Mulroy [TeamB]]

Post by Hendrik Schober
Sounds like the problem is TPTB. :)

All my life TPTB causes the paychecks to be issued. I've not figured out a
viable way around that.

Post by Hendrik Schober

...TPTB have declared MUST ship last week ...

Also implies that I was assigned this only a day or so ago. When
you ask for a living wage they typically instead pick up whatever
double-yolked egg will work for starvation wages or, more likely,
one who is a friend of some suit in the organization and is paid far
more than you asked for. Later you get called in to clean up the
mess. If it then works, it's his accomplishment. If not, it's your fault
:-(

. Ed

Post by Hendrik Schober

[...] Tired at midnight as I am debugging code which
TPTB have declared MUST ship last week it would be nice to think
about diagnosing the problems and not about what the heck some
arcane syntax means.

Sounds like the problem is TPTB. :)

[Hendrik Schober]

Post by Ed Mulroy [TeamB]

Post by Hendrik Schober
Sounds like the problem is TPTB. :)

All my life TPTB causes the paychecks to be issued. I've not figured out a
viable way around that.

In the companies I worked for, a (usually female) employee
issued paychecks (or rather: their local equivalent). And
usually she suffered as much as all the other employees.
Have you ever tried to befriend this person? :)

Post by Ed Mulroy [TeamB]

Post by Hendrik Schober

...TPTB have declared MUST ship last week ...

Also implies that I was assigned this only a day or so ago. When
you ask for a living wage they typically instead pick up whatever
double-yolked egg will work for starvation wages or, more likely,
one who is a friend of some suit in the organization and is paid far
more than you asked for. Later you get called in to clean up the
mess. If it then works, it's his accomplishment. If not, it's your fault
:-(

No, it's not mine. I refuse such offers.
(Yes, I'd need the money, but then I have four kids already
wrecking my nerves. <g> No need for such jobs.)

Post by Ed Mulroy [TeamB]
. Ed

Schobi