The worst thing about C++

[Steven T. Hatton]

#
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Steven T. Hatton]

#

<rant>
And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
<osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
what else. It makes managing a code base extremely difficult(manually, or
with automated tools), and adds nothing useful to the language.
</rant>
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Alvin]

<rant>
And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
<osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
what else. It makes managing a code base extremely difficult(manually, or
with automated tools), and adds nothing useful to the language.
</rant>

That's the beauty of the 'rename' command.

 

[Phlip]

#

?

Is this an effort to recite the "don't lean on the preprocessor" admonitions
from all the C++ tutorials that don't suck?

Finding the real worst thing about C++ would require many lifetimes of
careful, painstaking research. I'm certain the inventor of the language
didn't realize the copy construction rules and the exception propagation
rules would collude to make assignment operators depend on an
exception-proof swap() method. But don't quote me on that.

 

[Richard Herring]

<rant>
And a close second and closely related flaw is .h, .H .hh, .HH .h++, .H++,
<osg/NoExtension>, .c, .C, .cc, .CC, .cpp, .CPP .c++, .C++, and who knows
what else. It makes managing a code base extremely difficult(manually, or
with automated tools), and adds nothing useful to the language.
</rant>

None of which is a flaw of, or indeed anything to do with, the standard
C++ language we're supposed to discuss here.

 

[Steven T. Hatton]

That's the beauty of the 'rename' command.

IIRC RENAME is a DOS command. Suppose I have hundreds of files that
#include files using various extension for the file names.

#!/bin/bash

function backupCPlusPlus()
{
local BACKUP=$STH/"backup-c++"/$PWD-$(date +%F-%H-%M-%S)/
test -d $BACKUP || mkdir -p $BACKUP;
cp -r * $BACKUP;
}

function kdev2emacs()
{
for f in *.h; do
test -f $f && cat $f | sed -e /"#include "/s/"\.h\([\"\>]\)"/.hh\\1/

${f%%.h}.hh;

mv $f old;
done

for f in *.cpp; do
test -f $f && cat $f | sed -e /"#include "/s/"\.h\([\"\>]\)"/.hh\\1/

${f%%.cpp}.cc;

mv $f old;
done
}


Works great if everything in the emacs code base uses .hh. But that won't
happen if I build against boost and OSG. Boost uses .hpp and OSG uses no
extension. Further more, I don't want boost and OSG #includs modified. I
guess I could go through my code base and find all the filenames I use, and
check each #include against that list, before I make a modification.

But that's only one problem. There is also a problem of telling the tool
(e.g., Emacs speedbar) which files contain C++ source code. OSG include
files contain an Emacs mode specification line which works for determining
the type of the file being loaded, but is not used by tools such as
speedbar to determine the type of files in the current directory. Sure,
someone can write code to check each file in the current directory for a
mode specification line, but that means that every tool that is going to
use extensionless headers with mode specification lines has to do that.

It's much easier just to specify that .el means Emacs Lisp, .java means Java
source, .c means 'C' source, etc.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Steven T. Hatton]

None of which is a flaw of, or indeed anything to do with, the standard
C++ language we're supposed to discuss here.

It has to do with the usability of the C++ programming language.

--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Ioannis Vranos]

It has to do with the usability of the C++ programming language.

Meaning? (I think I am going to see how "C# handles this" yet another time. C++ handles
the .NET dlls the same under .NET. Dlls are not the same as source code files).

 

[Richard Herring]

It has to do with the usability of the C++ programming language.

No, it has to do with how C++ IDEs and other development tools integrate
into the environment provided by your chosen OS. That has nothing to do
with the language itself.

 

[Steven T. Hatton]

No, it has to do with how C++ IDEs and other development tools integrate
into the environment provided by your chosen OS. That has nothing to do
with the language itself.

This is not the case. The problems I am describing are not platform
specific. I can emulate a DOS shell under Linux, and I can run a posix
compliant shell under NT(AKA XP). Almost all tools I use are platform
independent. A person who does not have a reason to deal with the issues
related to using different tools at different times to work on the same
code base will probably not appreciate the nature of my concerns. If a
person has never studied the problem of parsing C++ source code to extract
useful information to provide to the programmer at edit time, he will
probably not appreciate the difficulties introduced by the use of the
preprocessor. If I were to restrict myself to using only one set of tools
in a clearly defined environment such as NT user space where I could, more
or less, predict all the variables, much of the problems I am describing
would be non-issues. That is not the spirit in which C++ was created, and
it is not good for the longterm health of the computing field.

Nonetheless, some of this goes beyond using multiple tools. It is utterly
absurd to have a langue support features that cause a compiler to detect
errors in code located in "header files" the programmer did not write, and
which contain no errors, because there is a minor syntax error in code the
programmer did write. But this happens with C++.

I understand the advantage the preprocessor provides to C++ programmers. It
allows for the crossing of the boundary between the language and the
observer of the language. This is a form of selfreferential recursion that
we might call selfawareness, or introspection. Stringification demonstrates
this very well. If I want my program to contain both the product of
compiling a function definition, and the human readable information
contained in the function definition, I have to have a way to access that
human readable information at runtime. Stringizing such information with a
Macro is a way to generate both the source and a characters representation
of the source to be included in the program at runtime.

With some languages such as Mathematica, Lisp, Java, ECMAScript, C#(?), that
is simply part of the way the language works. With the interpreted
languages, it is rather straight forward. The source code *is* the
executable. With compiled languages, it takes more intentional thought to
support such a feature.

I understand that C++ would incur costs in both space and time if such
introspection were required of all executable code. Introducing support
for it into the core language might add excessive complexity to an already
dauntingly complex specification.

All that being said, I believe much use of the preprocessor to generate
cookiecutter code is a way for the programmer to avoid correctly solving
the underlying programming problem. Virtually every use of the
preprocessor that I have seen that could not be replaced with a native C++
construct has to do with storing information about the source code to be
available at runtime.
--
"If our hypothesis is about anything and not about some one or more
particular things, then our deductions constitute mathematics. Thus
mathematics may be defined as the subject in which we never know what we
are talking about, nor whether what we are saying is true." - Bertrand
Russell

 

[Richard Herring]

This is not the case. The problems I am describing are not platform
specific.

Then your <rant> </rant> was obscurely worded. I interpreted it as a
complaint about (the lack of) file naming conventions, or possibly the
separation of interface and implementation into separate files, but you
seem to be talking about something entirely different.