Re: Cpp Considered Harmful

From: Paul Mensonides (leavings_at_comcast.net)
Date: 08/30/04 

Date: Mon, 30 Aug 2004 14:37:58 -0700

Steven T. Hatton wrote:
> Paul Mensonides wrote:
>
>> "Steven T. Hatton" <susudata@setidava.kushan.aa> wrote in message
>> news:ss6dnTV3AuAIiK_cRVn-rw@speakeasy.net...
>>
>>> Perhaps you could simply provide a definition for the term. My
>>> attempting to extract a definition from an example has the
>>> significant potential for my arriving at a different definition
>>> than the one you intend.
>>
>> Stringizing is a macro operator that converts a macro argument to a
>> string literal. E.g.
>>
>> #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.

> I've given this issue some consideration, and I've also observed the
> behavior of KDevelop. I agree that templates throw the IDE a curve
> ball.
> I suspect this is (in part) what Stroustrup was addressing when he
> mentioned incremental compilation and a C++ interpreter. There are at
> least two options for dealing with templates and edit-time error
> detection and code completion. They are not mutually exclusive.
>
> 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? 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.

> 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 */
}

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

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

> It's that way with JBuilder and Java.
> JBuilder balks at providing error detection and code completion in
> some cases in which the code has not been compiled, and it gets it
> wrong sometimes when the code has changed, and has not been
> recompiled.
>
> 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'.

> This is a perfect example of how the CPP undermines the integrity of
> C++.

No, it is an example of code that *may* be misusing the preprocessor. Even if
it is, so what? If I wanted to produce asinine and unreadable code, use of the
preprocessor is not required. In fact, it is possible in *any* language with
*any* feature-set.

> It's from the xerces C++ samples:
> CreateDOMDocument.cpp
> http://tinyurl.com/3wt4x
>
> #include <xercesc/util/PlatformUtils.hpp>
> #include <xercesc/util/XMLString.hpp>
> #include <xercesc/dom/DOM.hpp>
> #if defined(XERCES_NEW_IOSTREAMS)
> #include <iostream>
> #else
> #include <iostream.h>
> #endif
>
> XERCES_CPP_NAMESPACE_USE
> ...
>
> #define X(str) XStr(str).unicodeForm()
>
> ...
>
> unsigned int elementCount =
> doc->getElementsByTagName(X("*"))->getLength(); XERCES_STD_QUALIFIER
> cout << "The tree just created contains: " << elementCount << "
> elements." << XERCES_STD_QUALIFIER endl; ...
>
> Using JBuilder, and the Java counterpart, I can fly through XML
> coding. It's a pleasure to work with. The above excerpt is a mangled
> and tangled maze of inelegant kludgery. There are historical reasons
> for the code being the way it is. 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 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.

> 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. 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).

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

Regarding C++ (in general)... C++ is more powerful--that is unquestionable.
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.

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

Regards,
Paul Mensonides

Relevant Pages

  • Re: Cpp Considered Harmful
    ... you just parse the template and show the user code ... > that a tool, to be at all effective in modern programming, has to do near ... > much easier than they can parse the underlying language itself. ... > resulting from the preprocessor, it merely has to preprocess it. ...
    (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: Cpp Considered Harmful
    ... That is why assertions are preproccessed away in production code. ... What I've seen done with Java IDEs has shown me that they can ... In C++, because of the preprocessor, you cannot really be sure that what ... that you apparently want to enforce coding policy by language design. ...
    (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: is "using namespace std" good style?
    ... >> as well just replace the directive with those three using declarations in ... >> the template file... ... I wish it weren't part of the language. ... On-Site Training in C/C++, Java, Perl and Unix C++ users: download BD Software's free STL Error Message Decryptor at: www.bdsoft.com/tools/stlfilt.html ...
    (comp.lang.cpp)