Re: Cpp Considered Harmful

From: Kai-Uwe Bux (jkherciueh_at_gmx.net)
Date: 08/31/04 

Date: Tue, 31 Aug 2004 10:56:13 -0400

Steven T. Hatton wrote:

> Kai-Uwe Bux wrote:
>
>> Steven T. Hatton wrote:
>>
>>> Paul Mensonides wrote:
>>>
>>>> Assertions are invaluable tools.
>>>
>>> Some people seem to think so.
>>
>> Some people, including me, *do* think so.
>
>>> I read up on them in both Java and C++, and was also aware of them in C.
>>> They never seemed to be much use.
>>
>> "Read up on them"? Have you ever used this feature? Sometimes you realize
>> that something is useful not from reading about it.
>
> There has to be some need I have before I look for something to fill it.
> The idea of aborting a program on failure is simply not something I
> believe to be a good practice.

That is why assertions are preproccessed away in production code. And of
course, the preprocessor would allow you to write an assertion macro that
does not abort.

>>> I'll grant you, with the weak exception handling of C++ such a thing
>>> might be a bit handy.
>>
>> Assertions and exceptions are completely different beasts. Assertions are
>> about aborting the programm and printing a useful statement (useful
>> predominantly in debugging). Exceptions provide a flow construct to
>> escape from arbitrary levels of nesting (useful predominantly in
>> postponing the handling of error conditions).
>
> Actually Stroustrup goes on to demonstrate an alternative form of
> assertion
> which also failed to appeal to me. He uses a template that takes an
> invariant as a parameter. And get this. It throws an exception rather
> than aborting the program. In general that is the kind of thing I was
> talking about, but I simply don't find cluttering my programs with
> debugging code a good idea, nor, in general do I find it useful. I've
> noticed C and C++ programmers new to Java tend to use stuff like if(DEBUG
> {/*...*/} until they realize it really isn't all that useful in that
> context.

An assert( blah ) line is not cluttering your program with debug code but a
concise way of stating an invariant (e.g., within a loop, at the entry of a
block, or before a return statement).

 
>>> Too bad C++ doesn't have printStackTrace. I can't even think of
>>> problem I've had where such a mechanism would be of much use.
>>
>> My debugger prints the stacktrace just fine.
>
> When the code crashes? Will it print it to a web browser when your web
> application aborts? How do you use something like abort in a lodable
> module hosted by an application server?
>

Admittedly not. I was thinking of a debugging session to get my code right
so that it would not crash in the field.

>
>> * I do not see how that could be useful to anybody.
>
> That is not something I really care about, as long as the feature doesn't
> impact anything else.
>
>> * It will not allow me to have my IDE.
> This is a very important issue. The availability of superior IDEs for C++
> was one of the key features that distinguished it from the pack in the
> early days. What I've seen done with Java IDEs has shown me that they can
> be extremely powerful. Perhaps the more recent Microsoft IDEs for C++ are
> similar in their capabilities to what JBuilder, Eclipse, NetBeans, etc
> provide for Java. Something tells me that is not the case.
>
>> * If others can do something like that, I will have to adjust.
>
> Some things I accept as unlikely to change. For example, I don't believe
> there will ever be a file naming specification for C++. Some things seem
> more significant. For example, the dependence on header files to include
> resources. I've seen better ways of handling that situation, and I think
> it is a serious impediment to providing far more powerful support to the
> language.
>
>> * Bjarne Stroustrup seems to say so.
>
> You may care to note that this thread was forked from a thread I started
> with the purpose of questioning one of his more strongly voiced opinions.
>
>> * In Java you cannot do that; and Java rocks.
>
> For the most part, I've pointed to things you /can/ do with Java and
> you /can't/ do with C++.

This is an interesting point. I would like to make a distinction. I think
you pointed to things you *can know* in Java but you *cannot know* in C++.
In C++, because of the preprocessor, you cannot really be sure that what
you read is not transformed into something entirely different. Because of
conditional compilation, you cannot know which headers are included in
which order. Because of the flexibility of throw(), you cannot be sure
about the type of the object thrown. All these things are things you cannot
know about, because of things you (or others) *can do*.

This is precisely what I was refering to farther down the post when I said
that you apparently want to enforce coding policy by language design. I am
not saying that that is necessarily a bad thing. I am, however, saying that
I like C++ because it does not do that.

> There are good ideas in Java. The people who
> created the language are not stupid, and they had solid accomplishments
> using C (and perhaps C++) before they started working on Java. To ignore
> Java, as many C++ programmers would like to do, is an unwise approach to a
> legitimately successful competitor to C++.
>

I neither deny that Java is successful nor that Java has incorporated some
good ideas. And I never claimed Java to be designed by stupid people. I
just do not feel the need to make C++ more Java-like.

>> * ...
>>
>> c) May I suggest to replace X by some feature set / mechanism that would
>> only allow for the uses listed in (a). [Specifics about the proposed
>> replacement are unfortunately missing at this time.]
>
> Well, then you haven't read all of what I've posted.

I will note that it is very hard to read "all of what you've posted": you
are prolific. I am sure that I missed many of your points. I appologize.

> I've been very
> specific about what I would like the exception handling to do. I also
> posted a fairly extensive explanation of how I believe the Java library
> model would work for C++. I also proposed the addition of a feature to
> allow for user defined infix operators.
>
> You may also care to notice that I have been persuaded on several
> occasions that my proposals were not as viable as I originally thought.
>
>>
>> In short, you want to enforce coding policies by language design. I,
>> however, like C++ precisely because it does not enforce policies but
>> provides mechanisms, and a lot. E.g., [try, throw, catch] to me is not
>> about error handling but about stack unwinding; and your suggestion that
>> throw() should only accept arguments derived from std::exception would
>> break some of my code.
>
> Then you didn't read all of what I wrote about the topic. Either that, or
> you chose to ignore it.

It is a pitty that you chose to pick on the example and did not address the
main point that I raised int the topic sentence. I appologize if I
mischaracterized your opinion on exceptions. I still feel that you prefer
the language to enforce policies rather than have it provide mechanisms.

>> I like to explore the possibilites, and every once
>> in a while, I am really awestruck at how something can be done elegantly
>> in C++ in a way that I could not have fathomed.
>>
>> I do not think that C++ is perfect, but I dislike the direction in which
>> you want to push it. To me, it looks as though you are about to cripple
>> the language.
>
> How so? By introducing a more elegant, efficient, and effective means of
> managing libraries? I know damn good and well that the Cpp is going to be
> around for the foreseeable future. That doesn't mean I can't criticize
> its use, and proposed solutions for supporting the same functionality
> without resorting to using it.

Sure you can criticize the cpp. I was not denying any rights of yours. I
was pointing toward an underlying philosophy in your way of criticizing
various features of C++, including the preproccessor. It is that philosophy
that makes me uneasy about the direction of your proposals.

To take your last paragraph as an example: You start by talking about
library management when finally addressing the preprocessor in the
negative. This creates the subtext: "library management is *the* legitimate
use of the preprocessor, let's find a better way to that (so that hopefully
nobody will use the preprocessor anymore)."

Again, I am not saying that policy enforcing is a bad idea. I just prefer
to have at least one really powerful language around that does not do that.
And I like C++ to be that language.

Best

Kai-Uwe Bux

Relevant Pages

  • Re: Cpp Considered Harmful
    ... > One is to present the 'raw' interface of the template to the user. ... easier than they can parse the underlying language itself. ... resulting from the preprocessor, it merely has to preprocess it. ... > Using JBuilder, and the Java counterpart, I can fly through XML ...
    (comp.lang.cpp)
  • Re: Cpp Considered Harmful
    ... ordering, template declaration instantiation, etc.. ... I think you have a serious misunderstanding of the preprocessor. ... Parsing Java is quite a bit simpler than parsing C++. ... >> source code much easier than they can parse the underlying language ...
    (comp.lang.cpp)
  • Re: Software Development: maintenance vs. hardcore coding
    ... Support should be part of the language. ... Since very few people really build Java projects in the realy world by ... that would be no different from the C preprocessor, ...
    (comp.lang.java.programmer)
  • Re: Paper on PL/I
    ... >>> more capable than C's preprocessor. ... too much care to ensure that assertions do not cancel each other out. ... It is no sin to admit the shortcomings of one's favorite language. ...
    (comp.lang.pl1)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... All the ISO standards in the world will not make the world ... Nothing keeps you from annotating your program with exceptions based on what ... language should adhere to your theory. ... Curiously, although you don't say it, Java has the opposite problem. ...
    (comp.lang.lisp)