Effeciency

[Attila Feher]

Then read it again. Several places Bjarne expresses that some things
are not exactly as he wishes, and may well be changed later.

I see no doubt in this. The word you have been looking for is probably
light regret as opposed to strong doubt.

So now I am not allowed to say anything building on my own experience
and the experience of thousand others using the features in question,
in other languages, just because it disagrees with Bjarne? Get real.

From the two of us I am not the one who needs it most.

I am not at all claiming to understand language design as well as
Bjarne does.

I see.

But that doesn't mean that some points in his book are
more well argued than others.

Yes? And a topic being well argued in the book has to do *what* with the
standard C++ language? (Done by a large group of people and companies.)

For example, he sometimes say something
to the effect that this or that feature isn't included since,
although it can be helpful and powerful, it can also be misused
especially by beginners. I don't think that is a valid argument
against a feature. He even says so himself, that one shouldn't
underestimate the professional programmers that uses a language.

Yes. And most of all he also says that a programing language is not a set
of ad-hoc features, thrown together into a mess. And he also says (more to
our point) that a feature should provide enough benefits to be added and
complicate the lifes of everyone involved.

You want me to write a book?

No. I want you to say *one* concrete thing, instead of generic BS.

I am just stating my opinions after
reading the book (a year ago or so).

Great. Your opinion is that the book is not convincing. Mine is that it
is. Great. Now that we now opinions, how about facts?

If I were to write a useful and
valid criticism that anybody can use for anything, I am not going to
say something random in a newsgroup.

I see that you can explain why you do not say anything concrete or factual.
How about coming up with some real life arguments?

I would read the book again and
carefully comment where I thought i was needed, and publish it
somewhere on the net. Many people would disagreee with me, and maybe
many would agree.

I should be honest: I could not care less about how would you make a book
review. This is comp.lang.c++

You would have a hard time making a hard proof that
one group was right and the other was wrong.

You are mixing things. This is not about me, deciding who is wrong or
right, but you, putting down a man and a book without any arguments or
facts.

Language design is not an exact science.

Are you sure?

But I haven't done this yet. That doesn't mean that
I can't comment on his book. Or if so, then please don't comment
yourself.

Wow. Why don't you try to imagine that this is not about you or me or a
fight or p3nis envy, but about coming up with hard facts in a technical
newsgroups, where unfounded opinions of well known experts are not taken
lightly?

You're hard to take serious now. Please take the discussion serious,
or don't say anything.

I live in a free world. Respect this. BTW the above line of mine says
exactly what you said: be serious please.

I don't see how it is my job. As far as I'm concerned, you're the one
making unsubstantiated statements. I understand that you probably
think the same about me. But that doesn't make it my job more than
yours.

I made no unsubstantiated statements. You did. Anyways, let's THINk, even
if it is hard for you: what is possible/easy? To prove something does not
exist or that it does? Think about this.

To whom it is important to come up with proof that a feature is important?
To you, so I will vote yes on the proposal in the committee (if I get there)
or to me, who could not care less, because right now I am sure it is
useless.

That's not exactly what we're discussing. I am not necesarily talking
about "inheritance" in the traditional C++ way.

Good. Then tell what you do talk about. Because as I saw you mentioned
this area.

Sorry, I don't understand this.

It happens.

Well, yes, if you want to participate in a discussion where that is
your point.

You have definitely missed the point! *You* want to put the feature into
the language. *You* need to come up with good points to convince me. That
is how it works.

And therefore we can't discuss the langauge?

That is what you say. I did not say anything like it. But techincal
discussions are known to contain facts, so I was looking for those.

I don't have the time, but it is an interesting proposal. I will
consider writing a proposal whenever I get the time to do it.

Do it so. And if you want it to get accepted, you probably do not want to
start it with baseless (factless) criticizm.

Of course. "Possible to implement" is the easy part. It is a feature
that is so easy to add to any C++ compiler implementation in
existance, in my experience with compiler design.

Since you did not describe the feature and I do not know your experience
with compiler design, I should say that I cannot take this statement too
seriously.

Really? Interesting. Could you outline this?

Nope. Why? As I said: I do not need it. If you do need it, you do the
work. If you have no time to do it (it is not important to you) why should
I bother?

It seems like you are the prejudical one right now. You don't know
anything about whether my "mind is closed". I don't know whether yours
is, which is why I don't make such unsubstantiated claims, that btw.
has nothing to do with the subject at hand. Let's get back to that.

Has nothing? As it seems you cannot even imagine that there are good
technical reasons why the features you have requested did not get into the
language. So whose mind was closed? Certainly not mine.

This issue is important to me so I probably will do that, when time
allows it.

Good. And since I have not see one single technical fact in your so-called
"argument", I will just bail out from here. Why? Because if it is not
important enough for you to come up with an organized description of what
you want, it is certainly not important for me to waste my time with endless
and meaningless discussions about the vague opinions of yours - instead of
facts. So if I will have time I will spend it now on reading proposals done
by people who take the time, so that I can (straw) vote on them responsibly.

 

[Jerry Coffin]

Maybe you're right, but the point still stands.

That particular fiasco has little to do with types and such, though it
is interesting to note that almost all of the features that led to the
problem were _intended_ to prevent such things from happening.

Presumably the Ada feature you're talking about so positively is the
ability to do things like:

type Int1 is new integer; -- etc.

as opposed to:

type Int2 is integer;

but I'm not sure -- maybe you're just talking about a subtype, such as:

subtype digit is Integer range 0 .. 9;

While imitating the full capability of 'subtype' is probably difficult,
it sounds like you're interested primarily in a restricted range (e.g.
you also mention Pascal, which has a enumerated type that's quite
similar to enum in C++). Assuming that's the case, you can provide
roughly the same thing in C++, albeit with somewhat different syntax:

class out_of_bounds {};

template <typename type, type lower, type upper>
class ranged_subtype {
type value;
public:
operator type() { return value; }
operator=(type const &val) {
if ( val < lower || val > upper)
throw(out_of_bounds());
value = val;
}
ranged_subtype(type initial) {
if ( initial < lower || initial > upper)
throw(out_of_bounds());
value = initial;
}
};

#ifdef TEST
#include <iostream>

int main() {
typedef ranged_subtype<int, 0, 9> digit;

digit x = 1;

std::cout << x << std::endl;

digit y = 11;

std::cout << y << std::endl;

return 0;
}

#endif

which, when executed gives output something like this:

1

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

The second part is the response to the out_of_bounds exception that was
thrown but not caught -- obviously a real application would normally
want to catch and handle it appropriately.

That's not equivalent to a derived type in Ada, and doesn't give what
you seem to be asking for below: specifically, the ability to derive
directly from a built-in type, and then have assignments (for example)
type-checked, so you can't accidentally assign an object of the base
type directly to an object of the derived type.

At least from what I've seen, this isn't really a particularly great
loss. In point of fact, early in the history of C++ it _was_ seen as a
major problem, and a fair number of early class libraries included types
that were intended to cover this shortcoming, but including classes
(e.g. Integer) that were basically direct analogs of built-in types, but
were defined as classes so you could derive from them like you can from
any other class.

Such class libraries, however, have mostly gone the way of the dodo
bird, and for a simple reason: this capability seems useful at first,
but often leads quite quickly to problems -- much as is often the case
in Ada. The difference is that in Ada it's been a base part of the
language since the beginning, so it's essentially impossible to remove,
but in C++ it was never part of the language, so when problems arose it
was much easier to get rid of it.

I don't think you can find anything in that book about why you can't
have the compiler to that added type checking on types derived from
builtin types. I also doubt very much that you can come up with any good
reasons for leaving it out.

I can come up with some very good reasons for leaving it out. One is
that the language is already tremendously complex, and this would make
it even more so. Another is that experience with Ada has shown that
this ability isn't really as useful as you're implying.

As noted above, early users of C++ did see this as a problem, and did
provide a perfectly usable workaround to it -- but this practice has
almost entirely died (though it may be worth noting that Java has
standardized pretty much the same thing, so along with the built-in type
int, there's also a class Integer with similar characteristics, though
you can't derive from the former while you can from the latter).

In the end, however, if you're really convinced that this is important,
you have (at least) a couple of choices. The most obvious would be to
use a programming language (such as Ada) that already provides it.
Another would be to grab the sources to gcc (or some other C++ compiler
to which you can obtain source code) and modify it to allow what you
want. Given a successful implementation and a number (even a small
number) of happy users, I'm pretty sure you could write a proposal to
the C++ committee to get the possibility considered. I, for one, think
the committee would be badly mistaken to require such a thing of there's
nobody who's even willing to go to the trouble of trying it before they
propose requiring it.

 

[Jerry Coffin]

[ ... ]

Then read it again. Several places Bjarne expresses that some things are
not exactly as he wishes, and may well be changed later.

Compare the copyright of the book to the date of the C++ standard, and
perhaps you'll start to realize why this is so.

Bjarne hasn't personally made the final decisions on the definition of
the language for quite some time now. He is a member of the standard
committee, and I'm sure his input is given considerable weight, but in
the end, the decisions are made on a more or less democratic model, not
an autocratic one.