Re: namespaces and main()

From: poiuz24 (poiuz24_at_web.de)
Date: 07/23/04 

Date: 23 Jul 2004 04:41:49 -0700

> >another background was this: i do lot of templated stuff which
> >needs to be included with definitions anyway (when export is not
> >there ..). so i thought maybe i can rid of those nasty header
> >files altogether. i hate header files. why write code twice?
>
> You're not writing code twice, just declarations. The separation is

with writing code i meant writing C++ surface syntax, may it be
declarations or definitions. writing declarations twice all over
the place "just" because the build environment is lacking _is_ a pain
in the ass at least for me ..

so you say stop whining and write a new C++ build environment? ugh;)

> quite important in very large projects, since .h files should rarely
> be modified.

in an ideal world (from my POV), the compiler would generate
an object file for a translation unit which contains enough
information for the linker to check if any exported type information
changed. a recompiled library A would mean a new modification date
for the object file of library A. a linker would then see the new
mod date, but would have to look into the file to check if only
"internal information" changed or if exported type information
changed. this last step "checking if exported type info has changed"
is classically done via header files. but thats a hack around the
compiler/linker system unable to figure out stuff themselfes which
they clearly could (in theory).

>
> problem
> >of course with above example is that namespace scoped non-templated
> >functions may only be defined once (the obnoxious "One Definition Rule").
>
> Not true if any of the following is true:

> a) They are defined inside a class body.
i meant "namespace { .." scoped rather than namespace in the
sense namespace = {"namespace { ..", "class {..", ..}

> b) They are declared inline.
> c) They are in an anonymous namespace.
> d) They are declared static.
right, ok.

>
> >this one i don't understand either: with namespace scoped templated
> >functions, having multiple (of course identical) definitions is
> >_separate_ translation units is allowed by the standard as far as
> >I know and no problem for the linker to sort out.
>
> Actually it's quite a big problem for the linker to sort out - some

again lack of adequate information passed from the compiler to
the linker. a reoccurring theme it seems.

> linkers can't do it (including one I have used on QNX - .exes ended up
> containing multiple definitions of template functions, causing
> horrendous bloat). Some compilers have complicated prelinkers that get

i'm in the comfortable position to have no requirement to
support such broken/incapable build envs

> around this problem, by assigning each template instantiation to a
> particular translation unit, but this requires multiple compilation
> passes to find out all the required instantiations. This is what
> Comeau C++ does by default.

it becomes clearer and clearer to me that the real legacy are the
object file formats used to communicate between compiler and linker

>
> If you have multiple definitions of a function, either the
> compiler/linker has to compile them all, assume they are the same and
> discard all but one, or it has to assign the definition to a single
> translation unit and not compile it in any of the others. You can
> imagine the number of passes that would require!
>
> One way around the bloat issue is just to have a single compilation
> unit for your whole program! This might suit you.

puh, yes that might be a practical workaround for the broken
object file format

>
> > same goes for const
> >vars, structs, classes, typedef, ... but NOT plain functions. why?
>
> const vars have static linkage, so you haven't got multiple
> definitions, rather each translation unit gets a separate copy. For
> static functions this will obviously lead to major code bloat.

pain everywhere.

>
> >IOW: how do i get rid of headers;)
>
> Well, I suggested some ways above, but none of them are recommended
> since they all lead to bloated executables - the linker knows to merge
> different instantations of template functions, but not normal ones.

probably i go the "one system in one translation unit" road until
it doesn't scale anymore.

>
> >sideconditions:
> >i dont care a lot on compilation speed .. i don't develop
> >million line programs .. i just go buy more Ghz
>
> It's not just compilation speed. It's the fact that any change at all
> means you have to recompile absolutely everything.

so what? if that is fast enough (e.g. <2min), i don't care about
"wasted" CPU cycles computing stuff over and over again, if that helps.

>
> >i also dont care about "users" seeing ugly definitions instead
> >of a "pure" interface in separate headers. users should consult
> >the (doxygen generated) docs anyway .. not look at code.
>
> Yes, I don't strongly disagree with that, but the biggest problem is
> the dependency bottleneck. You will have major problems with circular

which dependency bottleneck? from my POV, there a logical dependencies
(class A needs class B). thats my design work. all other dependencies
i see as artificial and imposed by a specific build env.

> dependencies if you're not careful.
>
> >in java, nobody complaints ..
>
> Actually, they do. Look up posts by James Kanze on the subject, for
> one.
>
> It's best not to fight the language - in Java do what it wants, in C++
> do what it wants.

i always try to keep an open mind and look out for nice stuff
available to other languages. e.g. javadoc triggered doxygen which
is arguable a good thing. attributes in C# i find useful too. also,
i guess i'm not fighting C++ but it's arcane build env. i hate it
as much as i love C++.

>
> Tom

Relevant Pages

  • Re: namespaces and main()
    ... >> You're not writing code twice, just declarations. ... > in an ideal world, the compiler would generate ... > information for the linker to check if any exported type information ...
    (comp.lang.cpp)
  • Re: gcc questions
    ... It is equivalent to putting declarations like: ... > because it will get them right), telling the compiler you are going ... The standard says what sqrt does. ... would tell the linker to look for the standard math library. ...
    (Fedora)
  • Re: How to identify a pointer to a string literal
    ... so if a compiler or lint can determine that the string is not ... > platform, your compiler, etc, etc) and then write the functions to check ... compiler, linker, or operating system, or when you invoke your ... place by not writing code that depends on this. ...
    (comp.lang.c)
  • RE: Compile and gone! (Was: Re: VMS>7.3 Linker Manual - I64 Short Data restriction)
    ... Don't know what happened between 8.1 and 8.3 with the Linker or whether ... the compiler requested address constants. ... This form of the 'add' instruction ... relocations that would let the linker fill in the 64-bit literal of a ...
    (comp.os.vms)
  • Re: Fortran Guru requested
    ... > In 20 odd years of VMS Fortran programming, I have never yet seen a compiler ... > at the linker if wires have crossed in this example. ... If you have received the email in error, please notify TransGrid ... individual sender except where the sender expressly and with ...
    (comp.os.vms)