Re: Cpp Considered Harmful

From: Steven T. Hatton (susudata_at_setidava.kushan.aa)
Date: 08/31/04 

Date: Mon, 30 Aug 2004 20:27:07 -0400

Paul Mensonides wrote:

> Steven T. Hatton wrote:

>>> #define STR(x) #x
>>> STR(abc) // "abc"
>>
>> And that buys you what? I don't see the profound usefullness of this
>> trick.
>
> It buys you meaningful assertions with replicating code among other
> things.

Perhaps this is useful. I have never tried using assertions. When I read
about them in TC++PL(SE) it basically went. 'Check this assertion thing
out. Pretty cool, eh? They're macros. They suck!'

There are places where retaining some of the Cpp for the implementation to
use seems to make sense. For example the various __LINE__, __FILE__,
__DATE__, etc. are clearly worth having around so debuggers and other tools
can use them. They should not be considered part of the core language to
be used by application programmers.

>> One is to present the 'raw' interface of the template to the user.
>> That is, you just parse the template and show the user code
>> completion options in the 'raw' form, e.g., if the user is creating a
>> deque the following completion options could be presented:
>
> The 'raw' interface of which specialization of the template?

That seems like an ambiguity that could be resolved by examining the
parameter when necessary.

> The point is
> that a tool, to be at all effective in modern programming, has to do near
> full parse
> of the code and semantic analysis. With C++ especially, that is *far*
> from trivial.

I agree. However, the presence of the CPP complicates this issue to the
point where it seems to degenerate into an exercise in absurdity. I will
observe that many Java IDEs do this rather successfully.

>> Your observation regarding two phase lookup, if I understand your
>> meaning, is relevant, but not a show-stopper.
>
> Actually, it pretty much is a show-stopper, more so than anything else. A
> tool can trivially preprocess a file, but a tool cannot do any meaningful
> code
> completion inside a template. E.g. what options might a tool give me at
> this point:
>
> template<class T> void f(T) {
> X<T>:: /* here */
> }

Whatever can be extracted from X. If there are specializations of X the it
seems reasonable to provide the superset of options with an indication of
which are specific to a given specialization.

> The answer is "nothing" because it cannot know what T is, and therefore
> cannot tell what specialization of X is chosen, nor can it even tell what
> X specializations there might be.

Why can't it tell what specialization for X exist?

> In generic programming, there is very little
> code in a template body that is not dependent on template parameters.
> This is second phase lookup (a very useful feature) at work. What it
> boils down to is that code analysis such as completion is fundamentally
> useless inside template code, and that is precisely the place where it
> would be most useful.

I'm not convinced that either of these assertions are correct. It may be
more difficult to provide meaningful code completion inside a template, but
I believe it is fundamentally possible to provide a significant amount of
information in that context. Furthermore, I don't accept the notion that
code completion inside a template is where it would be most useful. By
their nature, templates are abstractions, and their use implies a certain
amount of selective ignorance that would preclude your knowing the details
of how specific template parameters would affect the context.

>> This relates back to my
>> early comment about KDevelop. I don't know how they do it, but they
>> are providing code completion for classes instantiated from
>> templates. That requires that the template code has been compiled.
>> To that I say 'big deal'!
>
> Okay, I'll follow this line (even though "partially" compiling C++ as you
> type
> would be incredibly expensive). If you say 'big deal' to that, than what
> is the
> problem with the preprocessor? Tools can trivially preprocess source code
> much easier than they can parse the underlying language itself.

Well, to some extent there is syntax checking going on with KDevelop. It's
not at the level I would like, but it continues to improve. As for the
cost of compiling C++, I'm not convinced that the proprocessor and the
compilation mechanisms it supports and encourages aren't a significant part
of the problem. The current approach seems rather monolithic. I suspect a
more compartmentalized strategy would prove far more efficient. I have to
admit that g++ can take an absurd amount of time to compile fairly simple
programs. My impression is that is due to the recompilation of units that
invariably produce identical results.

>> One might argue that the same could be done with the Cpp. My response
>> is that the Cpp is far less structured, and trying to predict what
>> someone might have done to his code with it, is beyond what I would
>> expect a reasonable programmer to care to address.
>
> What on earth are you talking about? Cpp *is* well-structured, and more
> importantly, it is a straightline process. If a tool cares to look at the
> code
> resulting from the preprocessor, it merely has to preprocess it. To that
> I say 'big deal'.

But now you are talking about something editing your code at the same time
you are, but not displaying the results. What I should have said is that
the result of using the Cpp is far less structured than the result of using
a programming language.
>> But there is no justification for
>> this kind of anti-programming in any code written with the future in
>> mind.
>
> Actually, there is. Because the underlying language is so complex, there
> are numerous bugs and missing features in every single existing C++
> compiler (more
> so for some than others). Even looking at the tiny snippet of code above,
> which I know nothing about as a whole, I can tell that it is working
> around that exact
> issue. In this example, the preprocessor merely makes it possible to do
> what otherwise could not be done.

I see no reason to try to support a compiler that doesn't understand
namespaces. What significant platform is restricted to using such a
compiler?

>> I pretty much figured out what all the macro mangling does in the
>> above sample. But by that time I was so disgusted, I lost interest
>> in using the library. There are countless examples of such anti-code
>> in most of the C++ libraries I've seen.
>
> There are plenty of ways to misuse the preprocessor, just as there are
> plenty of
> ways to misuse any language feature in any language. So what? Further,
> the above code is 'anti-code' only in the sense that it is working around
> flaws in the compiler, standard library, or isolating inherent
> platform-related dependencies.

As I said, there are historical reason for the code to be that way. That is
far from the only place where the people used the CPP to rewrite code that
should be straight forward C++. There are arguments for generating code in
ways that currently rely on the Cpp. I use them all the time.
http://doc.trolltech.com/3.3/moc.html

>> I should be able to write "using xercesc::XMLString" and the compiler
>> should pull in what it needs, and ONLY WHAT IT NEEDS, to provide that
>> class. I should not need the #include a file that #includes a file
>> that #includes a file that provides the definition of the namespace
>> macro, and another three or more levels of copy and paste to get the
>> bloody class declaration, and then pray that it can find the
>> corresponding definition.
>
> What does this have to do with the C or C++ preprocessor? C++ does not
> have a module system. You're talking about fundamental changes to the
> language, not problems with the preprocessor.

"I suspect my 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.
*_It_has_been_my_long-term_aim_to_make_Cpp_redundant_*."

> Further, there are things called "good
> organization" and "good code structure" that make dealing with these
> issues trivial (e.g. to use interface X include file Y and link to Z--well
> designed headers can be blackboxes).

I try hard to get things right. There are some aspects of Xerces which do
show a better face than what I previously introduced:
http://cvs.apache.org/viewcvs.cgi/xml-xerces/c/src/xercesc/dom/

The separation of interface and implementation is textbook proper C++. I
still find the added level of complexity involved in using headers
unnecessary, and a sgnificant burden. I'm currently working on a tool that
will mitigate this drudgery by treating the class as a unit, rather than a
composit.

>> For anybody who wants to tell me that the reason that C++ code is
>> this hard to understand is that C++ is more powerful, please explain
>> to me why IBM-the company that wrote the Xerces C++ code-is using the
>> Java counterpart to serve out IBM's latest online C++ language and
>> library documentation.
>
> Because they felt like it? Honestly, who cares? In my opinion, which is
> what matters to me, Java sucks on so many levels it is unusable.
That's a silly statement. I've seen it used to do losts of useful things.
This may be a fairly useless program, but I believe it demonstrates that
Java is capable of supporting the development of fairly sophisticated
programs. It's my second Java3d project. It was pretty much a limbering
up exercise.
http://baldur.globalsymmetry.com//projects/math-3d/living-basis.html

> Regarding C++ (in general)... C++ is more powerful--that is
> unquestionable.

What do you mean by powerful? It seems clear that major players in the
industry do not consider C++ to be appropriate for many major applications.

> Whether all that power is necessary to accomplish some
> specific task is another question altogether.
>
>> http://publib.boulder.ibm.com/infocenter/comphelp/index.jsp\
>> ?topic=/com.ibm.vacpp7a.doc/language/ref/clrc00about_this_reference.htm
>>
>> Years ago I read Kernighan and Ritchie's TCPL(2E). I've read all of
>> TC++PL(SE) except for the appendices, from which I've read
>> selections. I read the core language sections twice. I've also read
>> much other material on the language, and I've been writing a good
>> deal of code. Additionally, I've read The Java Programming language
>> 3rd Edition, and have considerable experience working with Java.
>> From that foundation I have formed the opinion, shared by the creator
>> of C++,
>
> So what? Bjarne is not the ultimate authority on what is good and bad.

No, but I find it interesting that his thoughts on this matter seem to
reflect my own - mostly independently formed - assessment. I believe it is
also significant that he does hold such a strong opinion about the matter.

He may not agree with me here, and even if he does, he may be unwilling to
say as much for the sake of polity. The way the standard headers are used
is a logical mess. It causes the programmer to waste valuable time
searching for things that should be immediately accessible by name. The is
true of most other libraries as well. There is no need for this lack of
structure other than the simple fact that no one has been able to move the
mindset of some C++ programmers out of the Nixon era.

>> that the preprocessor undermines the integrity of the core
>> C++ programming language and is the main reason for the comparative
>> ease of use Java provides. The Cpp is not a strength, it is a
>> liability.
>
> You're opinion, which you are entitled to, is simply wrong. The
> preprocessor is
> not to blame, the complexity of the language as a whole is. For an
> experienced
> C++ programmer, using Java is like tying your hands behind your back. The
> language (Java) not only promotes, but enforces bad design as a result of
> seriously lacking feature set--with the excuse that it is protecting you
> from
> yourself.

In the case of the CPP, it isn't so much me I want to be protected from.
It's the people who think it's a good idea to use it for anything beyond
simple conditional compilation, some debugging, and perhaps for #including
header files. I will admit that I still find the use of header files
bothersome. They represented one of the biggest obsticles I encountered
when first learning C++.

> C++ doesn't make such decisions for us, instead it gives us the tools
> to make abstractions that do it for us. In other words, it isn't the
> result of arrogance propelled by limited vision.

Leaving some things to choice serves no usful purpose beyond pleasing
multiple constituents. There are places where a lack of rule is not
empowering, it is restricting. I hear diving in Rome is not what one could
properly call a civilized affair. Personally, I like the idea that people
stop at stoplights, use trunsignals appropriatly, stay in one lane under
normal circumstances, etc. 

-- 
"[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.

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: trouble creating array of objects
    ... > programming would want to take that approach. ... Someone learning for any ... How to write template classes ... Using pointers and new is not advanced memory management it's the language ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Snow Leopard: A 64-bit Observation
    ... thing could be a lot faster and a lot more error-free than typing ASCII ... template functions. ... I'd be interested in a programming language that worked ONLY this way, ...
    (comp.sys.mac.advocacy)
  • Re: Index a #define string
    ... >> The two are quite different, and the bad uses of macros do not ... > to be used in daily application programming. ... yes--unless it is needed by the preprocessor for a good reason. ... > every macro demonstrates a flaw in the programming language, ...
    (comp.lang.cpp)
Loading