Re: Cpp Considered Harmful
From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 09/02/04
- Next message: Fao, Sean: "Re: Class Confusion"
- Previous message: Steven T. Hatton: "Re: Cpp Considered Harmful"
- In reply to: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Next in thread: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Reply: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 01 Sep 2004 19:07:51 -0400
Kai-Uwe Bux wrote:
> Steven T. Hatton wrote:
>
>> 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.
>
> a) This is rethoric. The information in "Information technology is about
> information." is the information, my program deals with. The information
> in "Good solid easily obtainable information is vital to design, to
> implementation, to trouble shooting and to security." is information about
> the structure of my code. The second statement may be true, but it does
> not follow from the first. You are using one term to reference two
> different entities.
It's not contradictory, it is simply recursive. I am applying the same
argument a mechanical engineer would use to explain his use of computers to
do his job. The programs and tools a software engineer uses are the
programming language, the compiler, the IDE, the libraries, etc.
> b) The information about my code is already available. After all, it must
> be sufficient for the compiler to generate object code. However, I agree
> that in C++ the information may be scattered around and is not as local as
> the human mind (or some IDE) would like it to be.
And I believe this is a significant problem that can and should be
addressed.
> c) I still see that there are trade offs. If you increase what can be
> known at coding time at the cost of what can be done, then there are trade
> offs. Since, apparently, I do not face the difficulties you are dealing
> with, I would rather keep the power of what can be done.
But what power do you lose by being able to import a resource with a using
declaration, or to bring in -perhaps implicitly- an entire namespace with a
using declaration? That really is what I am suggesting, more than
anything. WRT exceptions, the fact of the matter is that placing certain
requirements (restrictions) on their use improves their usability. If that
behavior can be configured at compile time in such a way that the
restrictions are not enforced, you have lot virtually nothing. The only
issue becomes the requirement that you do specify the alternative behavior.
Most compilers would probably provide a means of modifying the option
through a commandline switch, so compiling code that doesn't use the
feature would require no more than adding one command to your autoconf.ac,
or environment variables.
>> 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.
>
> I will drop exceptions. Obviously talking about them just gives you an
> opportunity not to address the issue of enforcing policies versus
> providing mechanisms.
Its your issue, not mine. The only reason I mentioned exceptions is that it
is the only place where I am advocating placing restrictions on what you
can do by default in C++. There are many restrictions placed on your use
of code. That's what type checking is all about. If you are suggesting
that I want to see changes in the way C++ is used in general, yes, that is
correct.
>> 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.
>
> Maybe, if cpp was even more powerful and more convenient, a superior
> library management could be implemented using macros.
I actually have a wishlist item in the KDevelop bug database that suggests
attempting such a thing using #pragma and a strategy of filename, resource
name consonance.
-- "[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: Fao, Sean: "Re: Class Confusion"
- Previous message: Steven T. Hatton: "Re: Cpp Considered Harmful"
- In reply to: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Next in thread: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Reply: Kai-Uwe Bux: "Re: Cpp Considered Harmful"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
