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

2008-06-24 07:37:28 PM
cppbuilder62
Roddy Pratt wrote:
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 wrote:
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.
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 wrote:
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
 

{smallsort}

"Roddy Pratt" < XXXX@XXXXX.COM >writes:
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
invalid.
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. :)
--
Chris (TeamB);
 

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

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

Leo Siefert wrote:
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
 

Dennis Cote wrote:
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.
[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.
 

Alan Bellingham wrote:
 

Ed Mulroy [TeamB] wrote:
 

Hendrik Schober wrote:
when it was originally built it can still be compiled with that version.
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
 

Dennis Cote < XXXX@XXXXX.COM >wrote:
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.)
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.
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?
of us could have a hell of a year trying to adapt several
MLoC to make them compile.
--
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
 

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

Hendrik Schober wrote:
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.
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.
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 < XXXX@XXXXX.COM >wrote:
more) elements. (C99 6.7.5.3/7)
Alan Bellingham
--
Team Browns
ACCU Conference 2009: to be announced