Good morning Krzysztof Zelechowski,

Krzysztof Zelechowski wrote:
> Uzytkownik <rgetov@gmail.com> napisal w wiadomosci
>>d) singleton-like initialization, e.g.:
>>  Table* getTable()
>>  {
>>     Table[100] table;
>>     static bool initialized;
>>     if (!initialized)
>>     {
>>        ...do the table initialization
>>        initialize = true;
>>     }
>>     return table;
>>  }
>>
>
>
> Thou shalt not return an address to an automatic object.

You are right, of course. But I assume, the OP actually **meant**

static Table[100] table;


> I would rather prefer a pragmatic directive here.  Borland C++ does have
> one, AFAIK.  Otherwise, you can do it in a constructor of the first object
> with the internal linkage.

I assume that you mean the initialization/finalization parts? AFAIK
these exist in Borland C++ to make C++ programmers the corresponding
initialization/finalization blocks of Borlands Object Pascal (aka
Delphi) available. These exist on a per-module-base, because Pascal
indeed has real modules.
Vandevoorde's module proposal fortunately does take into account similar
startup/shutdown functions wittedly named main() and ~main(),
see

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1778.pdf

Greetings from Bremen,

Daniel

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi all,

Let me give an example.

A program uses a table of POD values. Before used, the table has to be
initialized, and then it never changes.

I can do several things:

a) static initialization, e.g
   const Table[] table = { 1, 2, 3, 5, 8.. };

This is only practical in cases when the table is relatively small.
When the table is large and/or the calculations needed to fill it are
complicated, this a separate program to calculate the values might be
required.


b) explicit initialization
   Table[100] table;
   void InitializeTable()
   {
   ...initialize 'table'
   }

and then:
   InitializeTable();
   ...
   use 'table'

This requires special attention in order to initialize the table before
using it.


c) static object constructor, e.g.
   Table[100] table;
   struct Initializer
   {
      Initializer()
      {
          ....initialize table
      }
   } initializer;

This is of limited utility since the initialization order of file-scope
objects is generally undefined.


d) singleton-like initialization, e.g.:
   Table* getTable()
   {
      Table[100] table;
      static bool initialized;
      if (!initialized)
      {
         ...do the table initialization
         initialize = true;
      }
      return table;
   }

This solution has the drawback that the usage of my table is
inevitably acompanied by a check if it has already been initialized. In
(admitedly rare) cases it might cause be the cause of somewhat poor
performance, compared to e.g. some other methods.

It looks like the best solution is to be able to execute some user code
*before* the file-scope constructors are run.

One way to do that is to define a special function name. If the user
code defined such a function, it would be called before the file-scope
objects are initialized.

Even now, various implementations allow easy hooking of user functions
before the dynamic initialization phase. For instance, my linker allows
specifying of an 'entry-point symbol' (i.e. a function name). I can
supply my function there, and do whatever I want in it and then call
the original 'startup' function (which will call dynamic
initializations and eventually call main()). It is not stanard, though.

So, do you think that such a facility is useful enough so that it makes
into the Standard some day?

Radoslav Getov

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

* rgetov@gmail.com:
> A program uses a table of POD values. Before used, the table has to be
> initialized, and then it never changes.
>
> a) static initialization, e.g
>    const Table[] table = { 1, 2, 3, 5, 8.. };
>
>
> b) explicit initialization
>    Table[100] table;
>    void InitializeTable()
>    {
>    ...initialize 'table'
>    }
>
> and then:
>    InitializeTable();
>    ...
>    use 'table'
>
> c) static object constructor, e.g.
>    Table[100] table;
>    struct Initializer
>    {
>       Initializer()
>       {
>           ....initialize table
>       }
>    } initializer;
>
> d) singleton-like initialization, e.g.:
>    Table* getTable()
>    {
>       Table[100] table;
>       static bool initialized;
>       if (!initialized)
>       {
>          ...do the table initialization
>          initialize = true;
>       }
>       return table;
>    }

e) The usual:
    Table* const table = newTable();

f) The unusual:
    std::vector<Table> table = newTable();
   relying on return-value optimization.

g) The even-more-unusual:
    std::vector<Table> table;
   relying on the Table constructor to do some magic (i.e. keeping
   a static instance count).

.)


> So, do you think that such a facility is useful enough so that it makes
> into the Standard some day?

Nope.

The idea of "before other things" is inifinitely recursive.

Also, re my own pet idea in this direction, I think that in spite of
partial established practice it will not come to pass that we get a
generalized notion of function attributes where we could _declare_ them
as never-returning, having this or that calling convention, add in DBC
constraints and so on, and (the relevant thing here) state and guarantee
that a function is a function in the mathematical sense, one with no
side-effects, so that with a notion of dynamic libraries it could be
used in the initialization of compile time constants.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> A program uses a table of POD values. Before used, the table has to be
> initialized, and then it never changes.

*snip examples*

I don't think what you're suggesting is a good idea because it only
adds syntax sugar over writing a function to call and a copy
constructor (which can be elided) and it isn't that useful beyond that.
A much better idea would be some sort of metacode functionality along
the lines of:

http://www.vandevoorde.com/Daveed/News/Archives/000015.html

(specifically the type querying abilities and the scope injection
abilities) But rather than wait forever for something like that to be
created, standardized, and implemented, you can always do a custom
build step to generate code as a preprocessing step during build time
either by using perl or some language to create a file to include or a
more powerful macro system like m4. You just don't get to play with
C++'s type system with this sort of solution though.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Uzytkownik <rgetov@gmail.com> napisal w wiadomosci
news:1120171345.358859.308650@f14g2000cwb.googlegroups.com...
> Hi all,
>
> Let me give an example.
>
> A program uses a table of POD values. Before used, the table has to be
> initialized, and then it never changes.
>
> I can do several things:
>
> b) explicit initialization
>   Table[100] table;
>   void InitializeTable()
>   {
>   ...initialize 'table'
>   }
>
> and then:
>   InitializeTable();
>   ...
>   use 'table'
>
> This requires special attention in order to initialize the table before
> using it.
>
>
> c) static object constructor, e.g.
>   Table[100] table;
>   struct Initializer
>   {
>      Initializer()
>      {
>          ....initialize table
>      }
>   } initializer;
>

You can do better by making the table a member of the initializer

> This is of limited utility since the initialization order of file-scope
> objects is generally undefined.
>

first, it is defined in
3.6.2

; second, see above.
>
> d) singleton-like initialization, e.g.:
>   Table* getTable()
>   {
>      Table[100] table;
>      static bool initialized;
>      if (!initialized)
>      {
>         ...do the table initialization
>         initialize = true;
>      }
>      return table;
>   }
>

Thou shalt not return an address to an automatic object.

> This solution has the drawback that the usage of my table is
> inevitably acompanied by a check if it has already been initialized. In
> (admitedly rare) cases it might cause be the cause of somewhat poor
> performance, compared to e.g. some other methods.
>

But it has the advantage that it does not depend on the order of
initialization.

> It looks like the best solution is to be able to execute some user code
> *before* the file-scope constructors are run.
>
> One way to do that is to define a special function name. If the user
> code defined such a function, it would be called before the file-scope
> objects are initialized.

I would rather prefer a pragmatic directive here.  Borland C++ does have
one, AFAIK.  Otherwise, you can do it in a constructor of the first object
with the internal linkage.

> Even now, various implementations allow easy hooking of user functions
> before the dynamic initialization phase. For instance, my linker allows
> specifying of an 'entry-point symbol' (i.e. a function name). I can
> supply my function there, and do whatever I want in it and then call
> the original 'startup' function (which will call dynamic
> initializations and eventually call main()). It is not stanard, though.
>

And it applies to the whole programme, not to a single translation unit.
And it is rather easy to get things wrong here.

> So, do you think that such a facility is useful enough so that it makes
> into the Standard some day?

It can be done without extending the standard.  And BTW, read the FAQ
<http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12>.
Chris


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]