C++ and header files

• Previous message: Stefan Brozinski: "STL implementation with exception-specification"
• Next in thread: Pete Vidler: "Re: C++ and header files"
• Reply: Pete Vidler: "Re: C++ and header files"
• Reply: Howard: "Re: C++ and header files"
• Reply: Peter Gregory: "Re: C++ and header files"
• Reply: Mike Wahler: "Re: C++ and header files"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Thu, 18 Mar 2004 15:18:30 +0100

Hi all,

Although the post might look off-topic at first, it is not.

On Microsoft website I've recently run across future feature set of
Microsoft Visual Studio .NET 2005. One of the new features I liked
especially: in the right-click menu in the editor the following options are
available in 'Refactor' submenu:

Extract method
Encapsulate field
Extract interface
Change method signature
Rename

In my opinion this kind of IDE functionality is a great help for every
maintainer of a large system.

So, what does this have to do with C++? The problem is, that this extension
is only for C#, not for C++. Microsoft will not make this functionality
available for C++. Why? Not because they want to promote C#. It will not be
done because, sadly, it cannot be done with C++.

Imagine how could the simplest of all these - the 'Rename' function work?
The name to be changed can be declared in many files, some of them being
included in various places throughout the project. To find all of them, in
presence of #ifdefs and #includes in-the-middle-of-file, is virtually
impossible. Or at least impractical. But even if we find all of them, we
cannot know it the name really means what it looks like. Perhaps it is in a
different namespace (the namespace definition is enclosed in #ifdefs),
perhaps it is a macro defined to mean something else. Perhaps it is
#included inside definition of some class, which totally changes its
meaning?

Even if we completely drop #ifdefs and #defines, and leave only #includes
the evil is still here:

namespace X
{
#include "somedefs.h"
}

namespace Y
{
#include "somedefs.h"
}

Although this may not be the usual practice, it is legal C++. Now, what the
automated tool could do if we told it to rename some identifier in X that is
defined in 'somedefs.h'?

In presence of #ifdefs and #defines the problem becomes practically
unsolvable. Actually, the full set of preprocessor definitions should be
exactly known to even try to do something like that correctly. Alas, this is
impossible - beause this set changes with every build type. So, at best, we
could be refactoring a single build type. But it would destroy the rest. And
so on...

C++ relies on preprocessor functionality too much. Stroustrup has done a lot
to remove it. He succeeded in many minor cases (like making literals-macros
obsolete with const, and function-macros obsolete with inline). But on the
other hand the major case is still there: whole language relies on the
#include directive. It is used everywhere, and it's impossible to create
even the simplest 'hello world' program without it.

This is deadly and should be, in my opinion, rethought sooner or later. I
fear that C++ may be marginalized someday because of that, in favor of
languages that manage dependencies between translation units in a more
consistent way.

regards,
Marcin

• Previous message: Stefan Brozinski: "STL implementation with exception-specification"
• Next in thread: Pete Vidler: "Re: C++ and header files"
• Reply: Pete Vidler: "Re: C++ and header files"
• Reply: Howard: "Re: C++ and header files"
• Reply: Peter Gregory: "Re: C++ and header files"
• Reply: Mike Wahler: "Re: C++ and header files"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]