Board index » cppbuilder » Re: E2015 Ambiguity with Stream->Seek

2008-06-25 08:18:21 PM
cppbuilder81
Ed Mulroy wrote:
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?
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.
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.
adding a reserved word.
don't put "using namespace std;" in all of your headers do you?
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.
look they seem very much like enums to me and I would be most
comfortable with them retaining that term.
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
 

Leo Siefert < XXXX@XXXXX.COM >writes:
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...
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.
:)
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!)
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.
--
Chris (TeamB);
 

. Ed

{smallsort}

Alan Bellingham < XXXX@XXXXX.COM >wrote:
yet another meaning for 'static'...
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
 

Ed Mulroy [TeamB] < XXXX@XXXXX.COM >wrote:
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
 

Dennis Cote < XXXX@XXXXX.COM >wrote:
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.
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.
--
XXXX@XXXXX.COM is never read
I'm HSchober at gmx dot de
"I guess at some point idealism meets human nature and
explodes." Daniel Orner
 

Ed Mulroy wrote:
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
 

Leo Siefert < XXXX@XXXXX.COM >writes:
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. :)
--
Chris (TeamB);
 

Leo Siefert < XXXX@XXXXX.COM >wrote:
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
--
Team Browns
ACCU Conference 2009: to be announced
 

Alan Bellingham wrote:
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 < XXXX@XXXXX.COM >writes:
to its left, in which case it affects the class to its right...
:)
--
Chris (TeamB);
 

"Roddy Pratt" < XXXX@XXXXX.COM >wrote:
*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
--
Team Browns
<url:www.borland.com/newsgroups/>Borland newsgroup descriptions
<url:www.borland.com/newsgroups/netiquette.html>netiquette
 

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote:
Alan Bellingham
--
Team Browns
ACCU Conference 2009: to be announced
 

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
a sense of humor reads it and thinks it's a good idea?
 

Duane Hebert wrote: