"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:xY1ZaeBQ$rg6EwGY@ntlworld.com...
> I do not think that is true, but if it is, why not go and use the
> language of your choice instead of trying to change another language.

For some tasks, C++ is my language of choice. Every craftsman chooses the
right tool for the job. Java is the right tool for some jobs, C# is the
right tool for others, but some jobs can only be done properly by C++. In
their domains, Java and C# are a lot safer and easier to use than C++ is in
its domain. I would expect that just because C++'s domain is different
wouldn't necessitate that it has to be much more difficult to work with. As
Andrei Alexandrescu said in his post earlier on in this discussion, perhaps
this is where we need a "clean slate" to design another language to tackle
the problems in C++'s domain, without the complexity and lack of
expressiveness of C++. However, I would have liked if C++ itself could be
augmented with these features. I mean, since it is already so good and can
solve so many problems, why have to create a whole new language to solve
only a few additional problems. I would think that if you already have a
well designed language, it would be preferable to update it with new
features (backwards compatible of course) than to have and invent a whole
new language to deal with essentially the same issues in the same domain.

> Yes, C++ is not designed for those who are not engineers. In other words
> many who are using it would be better using another language that will
> protect them from their ignorance.

But even engineers should have tools that allow them to easily go about
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? 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.

> That is just an opinion. C++ is stable in the sense that it is not
> currently being actively changed (it is you who want to destabilise it
> by adding all these extras) and, as it meets the needs of those for whom
> it was designed I think it is reasonably well engineered considering the
> design constraints.

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

> You really do not understand, do you. Keywords add complexity and
> destabilise the product. Worse still new keywords break existing code.
> If you have a code base of 5 million lines the last thing you want is
> some bright theoretician adding a new keyword. New keywords have to be
> very useful to justify the cost (in destabilising code) of introducing
> them. I am not against new keywords as such, but there is a cost-benefit
> analysis to be done as well as consideration of their effect on other
> parts of the language.

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
new compilers would support these keywords. I'm not saying that we should
force people to define classes that can only be instantiated in one of these
three places. The keywords should be optional. So, for example, the
following bit of code should be able to compile on existing compilers, and
on compilers that would support these new keywords:

class A {};

In addition, the following code would compile on a new compiler supporting
the new keywords, but not on existing compilers:

heaponly class B {};

So you see, the changes I'm proposing are backwards compatible and would not
at all affect the existing code base. Of course I wouldn't do such a stupid
thing as to propose something that would require billions of lines of code
to be rewritten. If I was proposing that, I wouldn't be proposing a change
to C++ but rather that a new language is created.

> And we need to get our priorities straight. Just let me ask you; suppose
> we gave you your six new keywords, would you promise to stop there? Of
> course you would not, you would continually come up with new ones that
> you wanted to add. Look back to where you mentioned stability ... do you
> see what I mean?

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
C++ is good for so many things, why should somebody be forced to invent a
completely new language to add just a couple of features? I can't see the
logic in that, particularly if the features can easiliy be added to the
language itself in a backwards compatible way.

Have a look at fridges.The fridge you buy in the shop today is likely very
different to a fridge you would have bought 30 years ago, with many other
new features - but it's still a fridge. Or look at your word processor.
Whichever word processor you are using (eg. MS Word), I'll bet it's much
better than the same word processor even 5 years ago, with many new
features - but it's still the same word processor. Or if you want to talk
about tools, look at the drills and jigsaws you can buy in the hardware
shops now compared to those of 30 years ago. 30 years ago a drill could more
or less only drill holes. Now a drill can drill holes, cut, sand, carve,
etc. All these new features, but it's still a drill.

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.

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. 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. But by the same token, change should not be restricted where it
can be done in a backward compatible way, and where it can add new
functionality in a simple and cost effective way. eg. The proposed
"stackonly" keyword would for the first time provide the developer the means
to insure that an object is instantiated on the stack only. Currently there
is no way to insure that 100% with no loopholes. ie. There are currently
some things you cannot do in C++ - such as insure that your object is
instantiated only on the stack. A new keyword could provide this feature.

Jonatan Kelu



---
[ 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.     ]

In article <95vukr$26p8$1@si05.rsvl.unisys.com>, Jonatan Kelu
<Jonatan.Kelu@unisys.com> writes
> What we
>need is a clean slate, learn from all these three languages (and any others
>that have an idea to contribute) and make another language in the same style
>that meets all this criteria. Alas, I can't see it happening soon, or
>perhaps at all. Many would argue that there's too many such languages there
>already. Oh well...

Designing better languages is easy:) Getting people to use them is very
hard :( That is why C++ is so much more successful than languages such
as xxx (fill in your own choice of language only used in academia), C++
was designed pragmatically for use, and not for computer science
idealists.

--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ 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.     ]

In article <9600td$28a9$1@si05.rsvl.unisys.com>, Jonatan Kelu
<Jonatan.Kelu@unisys.com> writes
>So you see, the changes I'm proposing are backwards compatible and would not
>at all affect the existing code base.

Almost all changes destabilise, and new keywords certainly do.


--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ 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 appreciate that there are ways to produce this behaviour. My point was not
that you couldn't make this behaviour for the general case, but that you
couldn't enforce it in such a way that there was no way around it. You
yourself recognise that it still "lets you do it if you really REALLY want
to." My argument was that sometimes you don't want to make it possible to do
at all, in which case you can only enforce that if the compiler enforces it.

Jonatan Kelu

"Anthony Williams" <anthwil@nortelnetworks.com> wrote in message
news:960bha$jfnjt$1@ID-49767.news.dfncis.de...
> > > Jonatan Kelu wrote:
> > > >
> > > > For example, suppose we introduced the keywords "heaponly" and
> > "stackonly".
> > > >
> > >
>
> "stackonly" can be implemented very straightforwardly. Here is a base
class
> that will do the job.
>
> class StackOnly
> {
> private:
>     void* operator new(size_t s); // leave unimplemented
>     void operator delete(void*p);
> };
>
> class SomeClass: StackOnly
> {};
>
> void f()
> {
>     SomeClass sc; //OK
>     SomeClass* scp=new SomeClass; //error
> }
>
> Now SomeClass cannot be created on the heap, because operator new is
> private. Of course, you can get round that by allocating a block of
memory,
> and then using placement new, or deriving a class and adding operators new
> and delete, but this would stop the general situation. Namespace scope
> variables of SomeClass would still be permitted, so perhaps a better name
> would be "NotHeap" rather than "StackOnly"
>
> Anyway, I don't see how this is inferior to the keyword, in general, and
> like most things in C++, it lets you do it if you really REALLY want to.
>
> Making something heap only is more tricky, but not much - make all
> constructors private, and add factory functions:
>
> class SomeClassHeapOnly
> {
> private:
>     // implementation of constructors elsewhere
>     SomeClassHeapOnly();
>     SomeClassHeapOnly(const SomeClassHeapOnly& other);
> public:
>     SomeClassHeapOnly* create()
>     {
>         return new SomeClassHeapOnly;
>     }
>     SomeClassHeapOnly* create(const SomeClassHeapOnly& other)
>     {
>         return new SomeClassHeapOnly(other);
>     }
> };
>
> Obviously, this is less expressive than the "StackOnly" solution.
>
> One alternative is to make the constructors private, and make a generic
> factory template a friend.
>
> template<typename T>
> class New
> {
> private:
>     T*p;
> public:
>     operator T*() const{ return p;}
>
>     New():p(new T){}
>
>     template<typename T1>
>     New(T1& a1):p(new T(a1)){}
>
>     template<typename T1>
>     New(const T1& a1):p(new T(a1)){}
>
>     // add more template constructors as required
> };
>
> class SomeClassHeapOnly
> {
> private:
>     // implementation of constructors elsewhere
>     SomeClassHeapOnly();
>     SomeClassHeapOnly(const SomeClassHeapOnly& other);
>     friend class New<SomeClassHeapOnly>;
> };
>
> void func()
> {
>     SomeClassHeapOnly* p=New<SomeClassHeapOnly>();
>     SomeClassHeapOnly* p2=New<SomeClassHeapOnly>(*p);
>
>     delete p2;
>     delete p;
>
>     SomeClassHeapOnly scho; // error
> }
>
> Anthony
> --
> Anthony Williams
> Software Engineer, Nortel Networks
> The opinions expressed in this message are mine and do not represent those
> of my employer
>
>
>
> ---
> [ 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.     ]
>


---
[ 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.     ]

You're right, I stand corrected - the suggestions I was making would not
necessarily be backwards compatible. However, by choosing keywords that are
suitably prefixed by underscores or whatever is needed to minimize the
probability that somebody has used them already, the chance of making it
backwards incompatible can be made negligible, though it would still be
there. The saving grace would be that the keywords could only be used in
contexts where identifiers would be illegal and vice versa, so you would get
a compilation error if your code was incompatible - saving everybody from
having to search their code for possible incompatibilities. Either way, the
point is taken.

Jonatan Kelu

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3A854DD0.7CF20977@wizard.net...
> 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.     ]
>


---
[ 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.     ]

In article <9676vn$10mo$1@si05.rsvl.unisys.com>, Jonatan Kelu
<Jonatan.Kelu@unisys.com> writes
>I appreciate that there are ways to produce this behaviour. My point was not
>that you couldn't make this behaviour for the general case, but that you
>couldn't enforce it in such a way that there was no way around it. You
>yourself recognise that it still "lets you do it if you really REALLY want
>to." My argument was that sometimes you don't want to make it possible to do
>at all, in which case you can only enforce that if the compiler enforces it.

There is always a way round for a sufficiently skilled hacker, that is
not an excuse for doing it. If you want a nanny language to dictate to
your clients, do not use C++.


--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ 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.     ]

Anthony Williams writes:
> "stackonly" can be implemented very straightforwardly. Here is a base class
> that will do the job.
[ solution elided ]
> Namespace scope variables [ ... ] would still be permitted, so perhaps a
> better name would be "NotHeap" rather than "StackOnly"

If the objective is to be "more expressive" then it would be best to name
it by what it is :)

> Anyway, I don't see how this is inferior to the keyword, in general, and
> like most things in C++, it lets you do it if you really REALLY want to.

OK, how does one declare a class which is permitted to have static instances
(e.g., declared at file scope or namespace scope) or dynamic instances
(allocated with new), but _not_ auto instances (allocated on the stack)?

Mike

---
[ 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 just read the two C++ books: "Effective C++" and "More Effective C++"
by Scott Meyers. He goes to great pains to explain certain techniques for
doing certain tricky things in C++ that are not supported by the compiler.
However, I can't see why they couldn't be supported by the compiler.

I'll give two examples. There is an item in "More Effective C++" that talks
about how to go about writing classes in a way to insure that they are
always created on the heap and never on the stack. He goes through a few
examples of how it may be done, and their draw backs. Much of it is due to
the fact that an object that you don't want created on the stack may be
subclassed and the derived class then created on the stack. Or it may be
included as a member subobject of another object that is created on the
stack. Eventually, if my memory serves me correctly, he finds a way to
insure that an object is always created on the heap in all situations, with
a few provisos.

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 { ... };

When a compiler would encounter such a class, it could enforce these
restrictions. For instance, the following code would work as commented:

OnlyOnHeap * pooh = new OnlyOnHeap();    // OK
OnlyOnStack oos;    // OK
OnlyOnHeap ooh;    // compile error
OnlyOnStack * poos = new OnlyOnStack();    // compile error

Furthermore, the compiler could enforce the trickier situations where one of
these classes may occur as base classes or as members of other classes. So
the following code should work as commented:

class OOHChild : public OnlyOnHeap { ... };
class OOSChild : public OnlyOnStack { ... };
class OOHContainer
{
    ...
    OnlyOnHeap ooh;
};
class OOSContainer
{
    ...
    OnlyOnStack oos;
};

OOHChild * poohc = new OOHChild();    // OK
OOSChild oosc;    // OK
OOHContainer * poohcont = new OOHContainer();    // OK
OOSContainer ooscont;    // OK
OOHChild oohc;    // compile error
OOSChild * oosc = new OOSChild();    // compile error
OOHContainer oohcont;    // compile error
OOSContainer * pooscont = new OOSContainer();    // compile error

If compilers provided such a facility, we wouldn't have to resort to all
sorts of fancy tricks to try and somhow achieve what we are trying to do. In
any case, we can't do it nearly as well with tricks as the compiler would be
able to do. The other added advantage is that by having a keyword to
indicate our intent, we make our intent explicit so that maintainers of our
code can know what we were trying to achieve rather than wondering why we
declared a private destructor, or whatever other trick we may have employed.

This is just one example where a compiler could be made to do something that
we otherwise have to manually try and enforce as best we can, most of the
time with little success. There are other examples into which I won't go
here.

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? If so, in which revision of the C++ standard
is it likely to come up? If not, why not? Why has a language that was
designed from the beginning to put much more onus on the compiler to help
out the programmer missed such obvious things that the compiler could do
much better than the programmer?

Anyway, I hope somebody knows some of the answers.

JK





---
[ 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.     ]

In article <95qo9k$1ns7$2@si05.rsvl.unisys.com>, Jonatan Kelu
<Jonatan.Kelu@unisys.com> writes
>My questions are, does somebody know why such keywords and constructs have
>not become part of the C++ standard as yet?

Basically, adding things to C++ (called extensions) require a lot of
work (words have to be written, there interaction with other words have
to be considered etc.) This is a lot of pain. There must be commensurate
gain. There also needs to be someone with enough interest to pursue it.

If I want to prevent dynamic instances of a class I think I would
declare a private operator new. If some silly programmer then wants to
subvert my design by deriving from my class and providing an operator
new they presumably know what they are doing and are willing to take the
blame for the consequences.

--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ 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" <Jonatan.Kelu@unisys.com> wrote in message
news:95soj8$1pp$1@si05.rsvl.unisys.com...
[snip]

Well, I'll bite :o).

I agree with most of your points. However, I think we shouldn't go that
route with C++, for a number of reasons. The most important one is
compatibility. Many changes and embellishments that are even obvious to
everybody can't be made because that would break existing programs.

Basically C++ has been in the mode you wish for years now - a crucible of
exciting additions and changes, and that ended when the language was
standardized. Standardization is a very good thing because at least we can
bitch about compilers with a definite reason.

Last but not least, I think C++, after undergoing a number of incremental
changes, is not the most proper language for an overhaul such as the one you
envision. In my humble opinion it's one of those situations when a clean
slate is desirable. A new language learning from C++'s and other languages'
lessons should be designed. And no, that desire hasn't been incarnated by
Java nor C#.


Andrei


---
[ 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.     ]

In article <95soj8$1pp$1@si05.rsvl.unisys.com>, Jonatan Kelu
<Jonatan.Kelu@unisys.com> writes
>
>> These are all things that are occasionally useful, but are better
>> expressed in documentation.
>
>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.

>From your perspective what you want seems simple, but most additions to
the language add complexity and make our compilers more fragile (When
Ada was first released Professor Hoare (and if you have no idea who he
is, do a bit of research) wrote a lengthy diatribe explaining why such a
complex language was going to be difficult to implement for use with
safety critical programming (though the designers had intended it for
such use)

> Since C++ is a much more
>expressive language, it allows you to create objects both on the stack and
>the heap. However, if you want to insure that the object is used the right
>way, you both have to document it and you have to do syntactic gymnastics to
>get the compiler to realise the constraints you are trying to impose on the
>usage of a class. Even then nothing is guaranteed because if somebody
>happens to use it in just the way it's not supposed to be used, because they
>haven't read the documentation or whatever, your whole scheme falls on its
>face. While at the same time, it is a constraint that could easily be
>enforced by the compiler.
>
But objects that MUST be static or MUST be dynamic are actually
relatively rare and encapsulating an object that must be dynamic in a
suitable handle class should meet most needs.


>English as a language has many thousands of words that express the most
>subtle concepts. That's why it is so expressive.

And why there are so many misunderstandings.
>I don't see why computer
>language developers get so up tight about adding more keywords to express
>the concepts encountered in programming. 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. In addition, it allows the compiler to enforce the constraint -
>something your documentation can never do. Not to mention all of the other
>keywords that make C# so much more explicit with its concepts than C++.
Can we wait a little before hyping C#. Experience says that there are
going to be some costs for all those things you like. Seeing the good
bits is often easy, recognising the costs often takes quite a lot of
time.

>
>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.

I do not think that is true, but if it is, why not go and use the
language of your choice instead of trying to change another language.
>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.

Yes, C++ is not designed for those who are not engineers. In other words
many who are using it would be better using another language that will
protect them from their ignorance.

>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.

You do not win arguments by assertion.

>
>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.

Well usually, but he also chooses the tools for the job. A compiler and
a computer language are only tools. Those designing tools do so to meet
certain needs, that is also good engineering.

>By
>that I mean that small perturbations will not cause a dramatic effect.
>Without the sorts of keywords I am talking about, C++ cannot be considered
>stable, or a well-engineered product.
That is just an opinion. C++ is stable in the sense that it is not
currently being actively changed (it is you who want to destabilise it
by adding all these extras) and, as it meets the needs of those for whom
it was designed I think it is reasonably well engineered considering the
design constraints.

>
>C++ needs to be rounded off and filled out with more explicit keywords to
>handle those concepts that can be easily enforced by the compiler, that
>users would otherwise have to try and somehow emulate in the code, usually
>finding no way to do as good a job as the compiler otherwise could. Not only
>that it's difficult to create such code, but it's a terror to maintain -
>particularly if comments are few and far between. There's no way the
>maintenance programmer can be certain what the original programmer intended
>without the documentation. However, a simple keyword would make it explicit.

You really do not understand, do you. Keywords add complexity and
destabilise the product. Worse still new keywords break existing code.
If you have a code base of 5 million lines the last thing you want is
some bright theoretician adding a new keyword. New keywords have to be
very useful to justify the cost (in destabilising code) of introducing
them. I am not against new keywords as such, but there is a cost-benefit
analysis to be done as well as consideration of their effect on other
parts of the language.

>
>Anyway, I won't go on with more examples, but it's pretty clear to me that
>C++ in its current state is still incomplete. The compilers are not made to
>do enough work as long as there is more that they could do. More keywords
>need to be added to succinctly express concepts that can be
>compiler-enforced, that would otherwise have to be implemented by means of
>syntactic gymnastics, supported by documentation, and enforced by nobody. A
>few examples of these keywords were "heaponly", "stackonly", "staticonly",
>"constonly", "volatileonly", and lists of these, possibly with their
>negations, as well as "finally". What's 6 keywords compared to the hundreds
>of thousands in the English language? A small price to pay for clarity of
>intent and the ability of the compiler to enforce the constraint.

And we need to get our priorities straight. Just let me ask you; suppose
we gave you your six new keywords, would you promise to stop there? Of
course you would not, you would continually come up with new ones that
you wanted to add. Look back to where you mentioned stability ... do you
see what I mean?
>
>Anyway, that's my opinion.
>
And to write Java effectively I have to have 4000 pages of documentation
of libraries etc. There is much more to good design than adding
everything. Now what is the name of that ship that many members of the
C++ Standards Committees went to see last time we met in Stockholm?


--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)

---
[ 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.     ]

Thanks for that. I just have a few more questions on the standardization
process:

1) Were I to decide to write a formal proposal and submit it to the ISO
committee, where would I mail it to?

2) Is there anything like a template for writing such a proposal, or is
there somewhere I can access previous proposals so that I can see how they
should be laid out?

3) Were I to write such a proposal, is it appropriate to post it here to get
some feedback?

4) How often is the standard revised, or when is the next revision due?

Jonatan Kelu

"David R Tribble" <david@tribble.com> wrote in message
news:3A82CCEA.E731B81B@tribble.com...
> 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.     ]
>


---
[ 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".
> > >
> >

"stackonly" can be implemented very straightforwardly. Here is a base class
that will do the job.

class StackOnly
{
private:
    void* operator new(size_t s); // leave unimplemented
    void operator delete(void*p);
};

class SomeClass: StackOnly
{};

void f()
{
    SomeClass sc; //OK
    SomeClass* scp=new SomeClass; //error
}

Now SomeClass cannot be created on the heap, because operator new is
private. Of course, you can get round that by allocating a block of memory,
and then using placement new, or deriving a class and adding operators new
and delete, but this would stop the general situation. Namespace scope
variables of SomeClass would still be permitted, so perhaps a better name
would be "NotHeap" rather than "StackOnly"

Anyway, I don't see how this is inferior to the keyword, in general, and
like most things in C++, it lets you do it if you really REALLY want to.

Making something heap only is more tricky, but not much - make all
constructors private, and add factory functions:

class SomeClassHeapOnly
{
private:
    // implementation of constructors elsewhere
    SomeClassHeapOnly();
    SomeClassHeapOnly(const SomeClassHeapOnly& other);
public:
    SomeClassHeapOnly* create()
    {
        return new SomeClassHeapOnly;
    }
    SomeClassHeapOnly* create(const SomeClassHeapOnly& other)
    {
        return new SomeClassHeapOnly(other);
    }
};

Obviously, this is less expressive than the "StackOnly" solution.

One alternative is to make the constructors private, and make a generic
factory template a friend.

template<typename T>
class New
{
private:
    T*p;
public:
    operator T*() const{ return p;}

    New():p(new T){}

    template<typename T1>
    New(T1& a1):p(new T(a1)){}

    template<typename T1>
    New(const T1& a1):p(new T(a1)){}

    // add more template constructors as required
};

class SomeClassHeapOnly
{
private:
    // implementation of constructors elsewhere
    SomeClassHeapOnly();
    SomeClassHeapOnly(const SomeClassHeapOnly& other);
    friend class New<SomeClassHeapOnly>;
};

void func()
{
    SomeClassHeapOnly* p=New<SomeClassHeapOnly>();
    SomeClassHeapOnly* p2=New<SomeClassHeapOnly>(*p);

    delete p2;
    delete p;

    SomeClassHeapOnly scho; // error
}

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks
The opinions expressed in this message are mine and do not represent those
of my employer



---
[ 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.     ]

Francis Glassborow wrote:
> If I want to prevent dynamic instances of a class I think I would
> declare a private operator new.

..or you can write something like this (in spirit
of 'boost::noncopyable'):

#include "techniques/stackbased.hpp"

struct something : stackbased {
// ...
};

int main() {
  something* s = new something; // compile-time error
}

Getting some C++ idioms right indeed can be tricky, and scattering
lines like

private: // prohibiting copying of 'my' objects
  my(my const&);
  my& operator=(my const&);

through a dozen of classes in the project is not pretty too, but who
says that one should do it every time by hand. Identify the idioms,
factor them out into generally applicable (generic?)
classes/components, give them descriptive names, and soon you won't
need to spend half an hour on (unsuccessful) explanation to just hired
junior programmer that in order to prevent allocation of class objects
on the heap she should declare operator delete as private.. (on the
other hand, there is a danger that that way she will never know how to
implement the 'stackbased' herself ;).

IMO C++ offers amazing possibilities for expressing the intent/design
of code directly in, well, code; we just need to use these
possibilities more often ourselves, to promote them more actively, and
teach the techniques like 'boost::noncopyable' in the first place, as
the standard practices (<unrealistic?> E.g. code examples from
futuristic MEC's item #27 'Requiring or prohibiting heap-based objects'
would be something like these:

class UPNumber : std::technique::heapbased<UPNumber> { /**/ };
class UPNumber : std::technique::stackbased { /**/ };

(and probably the item itself would be ~25 lines of text :), and (it's
hard to stop dreaming after you've started :) one of the guidelines in
the item #20 of Herb's book would be (re-)worded as "If you want your
class to support one of the operators the language does allow to
overload, consider the use of standard operators library...", with the
code sample along these lines:

class Complex
  : std::operators::addable<Complex>
  , std::operators::incrementable<Complex>
{
//...
};

</unrealistic>)

Of course there will be still books for those crazy programmers who
want to know how all these techniques are implemented :).

--Aleksey


Sent via Deja.com
http://www.deja.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.     ]

Andrei, I'll agree with you on that one. Perhaps we need another language
that is as versatile as C++, but as easy to use as Java and C#. That
language doesn't exist yet. Java tried to make things easier, but in the
process eliminated too many of the good things in C++. C# comes somewhere
between C++ and Java, but even that doesn't compile to native code. What we
need is a clean slate, learn from all these three languages (and any others
that have an idea to contribute) and make another language in the same style
that meets all this criteria. Alas, I can't see it happening soon, or
perhaps at all. Many would argue that there's too many such languages there
already. Oh well...

Jonatan Kelu

"Andrei Alexandrescu" <andrewalex@hotmail.com> wrote in message
news:95vnal$gm8ui$1@ID-14036.news.dfncis.de...
> "Jonatan Kelu" <Jonatan.Kelu@unisys.com> wrote in message
> news:95soj8$1pp$1@si05.rsvl.unisys.com...
> [snip]
>
> Well, I'll bite :o).
>
> I agree with most of your points. However, I think we shouldn't go that
> route with C++, for a number of reasons. The most important one is
> compatibility. Many changes and embellishments that are even obvious to
> everybody can't be made because that would break existing programs.
>
> Basically C++ has been in the mode you wish for years now - a crucible of
> exciting additions and changes, and that ended when the language was
> standardized. Standardization is a very good thing because at least we can
> bitch about compilers with a definite reason.
>
> Last but not least, I think C++, after undergoing a number of incremental
> changes, is not the most proper language for an overhaul such as the one
you
> envision. In my humble opinion it's one of those situations when a clean
> slate is desirable. A new language learning from C++'s and other
languages'
> lessons should be designed. And no, that desire hasn't been incarnated by
> Java nor C#.
>
>
> Andrei
>
>
> ---
> [ 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.     ]
>


---
[ 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.     ]