This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ and static data members...


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]