Re: Cpp Considered Harmful
From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 08/31/04
- Next message: Chris F Clark: "Re: Cpp Considered Harmful"
- Previous message: Chris Theis: "Re: Limitations of initialization list"
- In reply to: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Next in thread: Chris F Clark: "Re: Cpp Considered Harmful"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 31 Aug 2004 12:35:41 -0400
Kai-Uwe Bux wrote:
> Steven T. Hatton wrote:
>
>> 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.
It was really a philosophical point. I don't want my code to abort for any
but absolutely unrecoverable circumstances. I started working with
hardware in 1979. failing to maintain an operational system was not merely
bad for my reputation, it was a threat to national security. My more
recent experience has been of the same nature. Add to that the fact that I
was developing code to run on servers, as services. Crashing the server
was just not a good development strategy. Especially because I was the
sysadmin.
> 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).
>
I believe I understand the strategy. In the kinds of development I've done
I haven't seem much need for that kind of thing. I'm more likely to want
to leave dumpers that will spit all the members of a class out to a stream.
> Admittedly not. I was thinking of a debugging session to get my code right
> so that it would not crash in the field.
>
But that's the nature of application servers. A single application should
not bring down the server. I'll admit I have very little experience with
C++ in that area, so there may be ways to call abort and only crash the
service, and not the server.
>> 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*.
Yes. You are correct. Information technology is about information. Good
solid easily obtainable information is vital to design, to implementation,
to trouble shooting and to security.
>>> 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.
In the case of exceptions, I have solid experience that supports the
opinions I hold. What I suggested simply works better as a default. And
that is what I was referring to when I suggested you hadn't read everything
I wrote. I explicitly said that the should be configurable through some
mechanism similar to the one currently used to switch out handlers. I'm
not sure how that might be accomplished, but I suspect someone in the C++
community is capable of finding a means.
> 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.
Actually, to a large extent, it's the other way around. I believe the
library management in C++ stinks. If there were a better system - which I
believe is highly doable - I would have far less to complain about
regarding the CPP. The CPP does go against certain principles of
encapsulation that are generally regarded as good in computerscience. A
better library system would go a long way toward addressing that as well.
If people aren't #including 15 megs of source in every file, there is less
(virtually no) opportunity for hidden variables entering the environment.
-- "[M]y dislike for the preprocessor is well known. Cpp is essential in C programming, and still important in conventional C++ implementations, but it is a hack, and so are most of the techniques that rely on it. ...I think the time has come to be serious about macro-free C++ programming." - B. S.
- Next message: Chris F Clark: "Re: Cpp Considered Harmful"
- Previous message: Chris Theis: "Re: Limitations of initialization list"
- In reply to: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Next in thread: Chris F Clark: "Re: Cpp Considered Harmful"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
