Jonatan Kelu wrote:
>
> "Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
> news:xY1ZaeBQ$rg6EwGY@ntlworld.com...
...
> their work. Why should I have to go through all the rigmorole of insuring
> that my object can only be instantiated on the stack, or on the heap, if it
> is something that the compiler can easily do with the addition of only a few
> backwards compatible keywords? ...

You have NOT suggested backwards compatible keywords. You've suggested
keywords that could have been used as user-defined identifiers in legal
code. This is not just an abstract possibility, due to your failure to
use leading underscores to make them come from the reserved namespace.
It's a significant possibility, due to your choice of simple ordinary
words that might easily have already been used by somebody for a
conflicting purpose in real code.

> ... Also, why should I have to invent a new
> language just because I want one additional feature that isn't present in
> this language, which otherwise satisfies all my needs? I don't know if
> you've read the item in More Effective C++ where Scott Meyers explains what
> needs to be done to insure an object can be instantiated ONLY on the stack
> or ONLY on the heap. If you haven't read it, I suggest you do so that you
> see the complexity involved. In the end, even after going through all the
> precautions, you still cannot guarantee that a class is created only on the
> stack because there's still a loophole that somebody can exploit to create
> it on the heap. There are times when you would like to be able to control
> where an object is instantiated, and at those times it would be nice to have
> keywords that allow the compiler to enforce these constraints rather than
> having to document them and hoping that somebody reads it and doesn't
> violate them.

Is such control really needed sufficiently often to justify modifying
the language to make it easy? I personally can't conceive of any
situation where such control is needed, though I'm willing to assume
that you have such a situation. But is that commonplace?

...
> I don't want to destabilis it as the extras I'm suggesting are added are
> optional and backwards compatible.

As I've pointed out above, your suggestion is NOT backwards compatible.
Even if it were, that only reduces the destabilizing effects; the same
is true of their being optional. Use of most features of C++ are
optional; offhand I'd be hard pressed to come up with one that's
mandatory. Useful C++ code must contain at least one definition; that's
about the only mandatory feature I can think of. What makes a language
complex is the number of options it provides. The more options it has,
the harder it is to learn, understand, and implement.

There's room for languages of different complexities for different kinds
of applications and different kinds of users, but C++ is already one of
the most complex languages out there. It's already uncomfortably near
the borderline separating useable languages from unusably complex
languages. There are many people who consider that it's already crossed
that border. Any step that takes it any farther in that direction should
be very carefully considered, and well justified. The change you're
asking for is small, but the advantage it buys seems absolutely
minuscule.

...
> Again, the keywords I was suggesting - "heaponly", "stackonly",
> "staticonly", and "finally" - would not destabliise the product. Of course
> code that didn't have these keywords (all existing code and any new code
> that wouldn't want to enforce these restrictions) would compile even after

How are you concluding that all existing code excludes use of those
identifiers? They're all in the name space of legal user-defined
identifiers. The fact that you seem unaware of the negative consequences
of that fact, should probably be taken as evidence that C++ is already
too complex for you to fully understand.

...
> Of course I would not stop with six new keywords. I would let the language
> live an breathe and adapt just like people and things do in all other areas
> of life. I have nothing against adding many new keywords to express many
> other concepts of which I perhaps haven't even thought of yet but that could
> come up in the future. Just because a language has been standardized doesn't
> mean it has to be set in concrete and can't be improved. Look at the world
> around you. Things are constantly improving. The only constant is change
> itself. If the language is not allowed to develop further, it will die. If

And if it's allowed to develop too rapidly, it will die. In living
organisms, uncontrolled growth is known by the name of "cancer". A
computer language must be kept simple enough so that individuals can
learn how to use them effectively in a reasonably short amount of time.
It must must also be kept stable enough that both users and implementors
have time to produce a quality implementation; that they're not required
to spend all their resources just keeping pace with new features.

> I believe the same goes for a computer programming language. If C++ is the
> same in 10 years from now as it is today, you can bet your bottom dollar
> that nobody (plus or minus a few percent) will be using it. The choice is
> simple: evolve or die.

Yes, but the uncontrolled evolution will kill it just as surely as
stagnation,
and is a far bigger danger.

> Just so you don't get me wrong, I must say that I don't endorse in any shape
> or form the sorts of changes that would make a lanugage incompatible with
> previous versions.

Then why did you propose such a change? Any change that adds keywords
selected from what used to be the namespace reserved for user-defined
identifiers makes a language incompatible with previous versions.

> ... Like you said, if somebody has 5 million lines of code,
> they shouldn't be forced to change them just because a language feature has
> been added.

Which is precisely what your proposal will require. Admittedly, the
search will be fairly straightforward - just look for any occurrence of
any of your proposed keywords as an identifier. There have been other
backwards incompatibilities which are much harder to adapt to  (such as
the addition of "long long" to C99). However, it's still a search that
would need to be done, and might force the otherwise unnecessary
updating of code.

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

I have wondered whether a feature like this would enable more efficient
string implementations (both space and performance).

Consider

string s("hello");

If there was a string constructor that was invoked only when the
parameter was static storage class, this would make it possible to avoid
copying the string.

something like:
string::string(static const char* value)

unfortunately this is still not quite right because I want to use
"const" not to specify that the constructor will not touch it, I want to
say that this is an object that will never be modified.

maybe:
string::string({static const} const char* value)

Having a constructor that was being used only for constructing const
objects might also be useful from an efficiency point of view.

Something like:
string::string({static const} const char* value) const


Of course it is arguable that the extra complexity in the language would
be justified.

TY

Jonatan Kelu wrote:
>
> To guarantee that an object is never created on the heap but always created
> on the stack was even more difficult, and from memory, there was no
> satisfactory solution that worked in all cases.
>
> However,  I cannot see why we should go to such lengths to enforce such a
> simple concept. Either you want an object to be created on the heap only, or
> on the stack only, or you don't care (C++ default behaviour). Furthermore, I
> believe there is enough information at compile time to enforce this
> restriction at compile time. Why isn't there a C++ language construct, such
> as a keyword, that would allow the enforcement of such behaviour. It would
> save Scott Meyers some word, and the rest of us a lot more.
>
> For example, suppose we introduced the keywords "heaponly" and "stackonly".
> Then we could apply it to a class declaration:
>
> heaponly class OnlyOnHeap { ... };
> stackonly class OnlyOnStack { ... };
>

---
[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Jonatan Kelu wrote:
>
> For example, suppose we introduced the keywords "heaponly" and "stackonly".
>

Why stop there? <g> How about staticonly and functionstaticonly? And
then there's constonly, volatileonly, constvolatileonly. And, probably,
nonconstonly, nonvolatileonly, nonconstvolatileonly. And, of course, you
also have to permit lists of these qualifiers, so that you can say that
some type can only be used to create const objects that live on the
heap.

These are all things that are occasionally useful, but are better
expressed in documentation.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Jonatan Kelu wrote:
> My questions are, does somebody know why such keywords and constructs
> have not become part of the C++ standard as yet? Are there plans to
> introduce keywords to do such obvious things that a compiler should
> have no problem doing as I have outlined above?

One of the reasons that additional keywords and programming features
are not added to a language is to keep the language (relatively) small
and manageable.  (Some of us think that C++ is already too large for
mere mortals to comprehend.)

Another principle is that if there is already a way to do something
in the language, then there is no need to go and invent special
syntax to add a second way to do it.  Of course, if the current way
of doing that thing is very painful, then the new syntax might be
worth the effort of adding it to the language (and the extra effort
required by implementors to support it).


> If so, in which revision of the C++ standard is it likely to come up?
> If not, why not?

The only way that new features get added to the language or library
is for someone, like you, to write a formal proposal and submit it to
the ISO committee.  A good place to start is this very newsgroup
(news:comp.std.c++), which can be a source of valuable feedback.
But you must start with a compelling reason for any change or
addition to the language, no matter what the size or scope of your
proposal.

--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Jonatan Kelu wrote:
>
> I don't agree. Take for example the keyword "const". According to what you
> are saying, this keyword is not really necessary because you can document
> that a certain object should not be modified. (I know that it plays a part
> in compiler optimization, but although it aids optimization, conceptually it
> is not necessary.) I'm sure that there are other keywords and constructs
> that aren't really necessary and whose function could otherwise be explained
> by the documentation. The point is that we are not getting full mileage out
> of our compilers.

Arguing that 'const' is unnecessary doesn't help your claim that
'heaponly' should be added.

>
> Take Java as an example. In Java everything is on the heap so you don't have
> to worry and think about whether your object is going to be created on the
> stack or the heap, so there's no chance of you making a mistake.

I have never had to worry about whether my objects were created on the
stack or on the heap. The classes that I write work either way, as well
as for static objects. While it's an interesting exercise to try to
figure out ways of restricting this, I simply don't see its practical
value. Which is why I don't see the point of building restrictive
mechanisms into the language.

> If there is
> any chance of you making a mistake in some other way, the compiler will warn
> you. The only errors left to runtime are those that the compiler could not
> possibly detect.

This claim is hardly new -- it was made for Pascal twenty years ago, and
look how successful that's been.

> That's one reason why it's so much easier to use than C++ -
> by easier, I mean less strain on the brain.

No doubt. Java gives you fewer options, so as long as you stick to the
sort of problem that Java is good at solving, it's easier. Try writing a
device driver in Java. Or a garbage collector. Or any of the other
things that are implemented in the VM or in native code because they
can't be done in Java.

>
> English as a language has many thousands of words that express the most
> subtle concepts. That's why it is so expressive. I don't see why computer
> language developers get so up tight about adding more keywords to express
> the concepts encountered in programming.

This stretches the analogy between programming languages and human
languages far beyond its breaking point. It takes decades for native
speakers to learn to speak English effectively. And that's with highly
motivated learners, surrounded by English speakers twenty-four hours a
day. Learning to use a programming language should not require a
lifetime of study. Indeed, some folks claim that C++ is already too
complicated.

> Another example of being expressive
> is C#'s "override" keyword. In C# you can't override a virtual function
> without explicitly specifying that it is to be overridden. This sort of
> expressiveness can say in one word what it could otherwise take you pages to
> document.

Nonsense. Here's the documentation:

 Overrides base version.


> In addition, it allows the compiler to enforce the constraint -
> something your documentation can never do.

Yup. Do you have any concrete data that shows how often problems arise
from accidentally overriding a virtual function without intending to?

> Both in Java and in C#, you can either do something or you can't do it. If
> you can do it, you can do it easily, explicitly, and expressively. If you
> can't do it, you can't do it at all.

Good joke.

> The benefit C++ has over these
> languages is that it is more powerful, meaning that there's usually some way
> to do something, and it compiles to machine language. However, just because
> you can do something in C++ doesn't mean you can do it easily. Many times
> you have to do all sorts of syntactic gymnastics, and back it up by
> documentation, and then keep your fingers crossed and hope that the client
> (which may be just another maintenance programmer) will remember to read the
> documentation and use the class appropriately. Only if all these conditions
> are met will it work properly, otherwise it will fall on its face. Say what
> you want, but this scheme is not fault tolerant and is not an example of
> good engineering.

Writing code that is as fragile as you describe is obviously not an
example of good engineering. The solution is to write solid code, not to
hack the language so that you can stick bandaids on code that is flawed
to begin with.

>
> In all other engineering disciplines, the engineer goes out of his way to
> insure that the structure he is building is fault tolerant and stable.

Yup. That's why bridges resonate themselves to death in high winds,
aircraft fuel tanks explode, and lightning knocking out a single power
substation throws the entire Northeast into a two day blackout.

As Jerry Weinberg put it (I think it's in "Secrets of Consulting"),
"it's always a people problem." If the software that a company produces
isn't reliable, adding a bunch of "Mother, may I" rules to the language
and the code won't fix it. The way to fix bad code is to fix the
development process that produced it. (See Philip Crosby, "Quality is
Free")

If an automobile assembly line starts turning out cars that are missing
their headlights, you go to the station where the headlights are
supposed to be installed; if the person who is supposed to install them
is sleeping, you don't fix the problem by checking more carefully for
missing headlights. You fix it by waking him up. And if he insists on
sleeping instead of doing his job you fire him (or her, of course).

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]