Re: Cpp Considered Harmful
From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 09/02/04
- Next message: Steven T. Hatton: "Re: Cpp Considered Harmful"
- Previous message: Howard: "Re: binary number"
- In reply to: Chris F Clark: "Re: Cpp Considered Harmful"
- Next in thread: Chris F Clark: "Re: Cpp Considered Harmful"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 01 Sep 2004 18:49:32 -0400
Chris F Clark wrote:
> Steve Hatton wrote:
>> Take careful not that I am not actually advocated abolishing the CPP, nor
>> am
>> I advocating the abolishment of the #include. I simply want superior
>> means of doing some of the things the CPP is currently used for.
>
> Then the title is wrong.
I have to disagree. I borrowed the form from Edsger W. Dijkstra's title for
a reason. The goto was never abolished, but it is rarely used in most
code.
hattons@ljosalfr:/usr/src/linux/kernel/
Wed Sep 01 18:15:45:> grep goto *.c | wc -l
290
> I could care less about #include. The quote
> from BS isn't about #include either. The part of cpp he doesn't like
> is the textual manipulation stuff. That is the part that is
> *NECESSARY* and powerful.
I understand that his focus is on the use of defines, nonetheless, I believe
I am, to a large extent addressing the same problem. I don't want
unnecessary stuff introduced into my translation unit that can result in
unexpected behavior, or hidden dependencies. In addition, and this may go
beyond what Stroustrup is concerned with, I find the use of #include to
introduce resources messy, redundant, inefficient, often confusing, and
significantly annoying.
I see little gained by isolating a given #define to a namespace, if it can
still sneak into my translation unit in a #include. Sure, it narrows down
the possibilities, but the problem remains. When I import an identifier
into my file, that's _all_ I want. Sure Koening lookup might technically
bring in a bit more, but I don't believe that introduces anything like the
problem I am trying to solve.
> At best #include is a small implementation detail for doing imports.
> Sure it is ugly in its implementation, but it harks back to the fairly
> early days of C. I believe there are even C++ compilers that don't
> use/need it.
If you can provide an example, please share it with us. I really, really,
want to explore this area.
> The current standard certainly implies that with the new
> syntax of #include for the language specified libraries. Those
> #include statements don't need to be implemented as files.
But that is not what I'm talking about. The Standard still specifies that
the entire contents of the header is included in the translation unit. I
believe it would be trickier in C++ than in Java to accomplish what I'm
describing, but I believe it is doable. The problem with C++ is that more
of the supporting infrastructure needs to be compiled per instance, than
does with Java. That means I cannot simply import a template in the way
Java imports a class. The template will (officially) have to be compiled.
(I will note that gcc 3.4.x is now advertising precompiled templates.) But,
even in Java, there is often a need to compile a class before it can be
used where it is imported, so this is simply a metter of degrees.
> Of course, for backward compatibility, there will always be a way to
> implement them using files--too many C++ compilers have and always
> will have implemented them that way. And, backward compatibility is
> truly important in C++--and actually in almost every programming
> language.
I've seen that issue dealt with from both approaches. Certainly, it is
easier to break version 1.x when going to 2.x, than it is to break 3.x when
going to 4.x. Both Java and Qt were willing to forego backward
compatability for the sake of progress. There are ways of grandfathering
in older software by lugging around antiquated libraries and compilers, and
creating glue-code to bridge the differences.
> If you want to break backward compatibility, it is better to design a
> "new" language, i.e. Java, C#, D, than to try to change an old
> language. Users are going to migrate to newer languages anyway, and
> you are better off making your new language be one of the alternatives
> they can try, than trying to get all the compiler vendors for your
> current language to come on board with your backward incompatible
> version.
I agree, for the most part. However, backward compatability can sometimes be
achieved as an either/or option. Either you use the new feature, or the old
one for a given translation unit, or a given program.
> C++ is too old
> *NOW*. Any other backward incompatible changes will be mostly like
> the changes that went into FORTRAN 90--I bet there were a lot more
> FORTRAN 77 compilers than there ever will be FORTRAN 90 ones. I doubt
> that in 10 years from now I will be writing any C++, maybe not in 5.
> On the other hand, I've written C++ code for 15 years already, so it
> won't be like I didn't use it for a long time.
What ever happened to Claudio Puviani?
-- "[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: Steven T. Hatton: "Re: Cpp Considered Harmful"
- Previous message: Howard: "Re: binary number"
- In reply to: Chris F Clark: "Re: Cpp Considered Harmful"
- Next in thread: Chris F Clark: "Re: Cpp Considered Harmful"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
