This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ and static data members...
- To: Joe Buck <jbuck at synopsys dot com>
- Subject: Re: C++ and static data members...
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Date: Sat, 04 Sep 1999 01:16:03 +0200
- cc: gcc at gcc dot gnu dot org, martin at mira dot isdn dot cs dot tu-berlin dot de
First, let me be clear. I do not want a new feature. I just find the current
behaviour strange and non-natural from the programmer's view. If there is no
way to improve that at small cost, too bad...
> No, the purpose of a standard is to standardize existing practice, not
> to introduce new stuff that's never been seen before unless it fills
> a vital need. You seem to want g++ to ignore all existing practice
> and include any .o file that has a static object with a constructor.
Well to most users (with a strong C predjudice, I must agree (but I'm n
ot a C++ beginner either)), if something works compiling a set of .o then
if you put part of your .o into a library and recompile with it instead,
it still works. That's existing practice also...
AFAICT, the static members initialization is the feature that makes
this behaviour to appear, so in some way it is a C++ ``concern'' (I'm
trying to avoid the word problem).
As is by the way the concern of the order of such initializations across
translation units. In fine, static members are not so easy to use !!!
Too bad :-(
> This would be a disaster; executable sizes would bloat, and programs
> that depend on the existing behavior would break.
Size of executables might indeed be a problem.
I'm not sure to see programs that would rely on such a strange
behaviour (.o vs .a link properties)... but I have certainly not
seen everything :-)
> (example: use of static constructors to register information about what
> code has been included, or to implement the "object factory" pattern. If
> this scheme is used, your proposed change would require that every file in
> every library be included in every executable).
The funny thing is that it is exactly what I wanted to do (register various
file formats readers/writers).... Everything worked well untill I created the library...
I worked around my problem by putting the static variable definitions
into the file that registers the information. That's a modularity
disaster but it works fine. It is just more tricky to extend than it should
have been...
> You always have the option of specifying the .o files you want explicitly
> on the linker command line.
IMHO, offer a library and then ask to people to link with a given .o plus
the library is a no-no....
Actually, creating a dynamic library instead of a static one is maybe
the easiest solution from both the implementer and the user point of
view. Boy, I wanted to learn how to use libtool, it is an
occasion...
Thank's anyhow for all your clarifications...
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------