Complex objects initialized at compile time

[Arno]

Hello,

here is my problem: I have a complex data type, like a std::vector<
std::string > and need some global constant values of this type. The
type is also used non-constant throughout the program, so I do not want
to use dumb types, but rather STL things.

In the best of worlds, initialization of these constants would not
happen at runtime, but at compile time, essentially generating a
constant memory image of this type via meta-programming. Has anyone
made any attempts in this direction?

I have written some simple macros that do it in Visual C++ 2005 for
std::vector< integral_type >. Of course, it is non-portable, but the
general principle _would_ be portable, with merely the exact memory
arrangement to be non-portabel.

Any ideas?

Arno

[Jim Langston]

Re: Complex objects initialized at compile time

"Arno" <aschoedl@thi nk-cell.com> wrote in message
news:1139742794 .767822.287950@ g44g2000cwa.goo glegroups.com.. .[color=blue]
> Hello,
>
> here is my problem: I have a complex data type, like a std::vector<
> std::string > and need some global constant values of this type. The
> type is also used non-constant throughout the program, so I do not want
> to use dumb types, but rather STL things.
>
> In the best of worlds, initialization of these constants would not
> happen at runtime, but at compile time, essentially generating a
> constant memory image of this type via meta-programming. Has anyone
> made any attempts in this direction?
>
> I have written some simple macros that do it in Visual C++ 2005 for
> std::vector< integral_type >. Of course, it is non-portable, but the
> general principle _would_ be portable, with merely the exact memory
> arrangement to be non-portabel.
>
> Any ideas?
>
> Arno[/color]

I think one of the problems you will come across is the fact that
std::string does not store the character data in the class object itself,
but a pointer to the data. So at run time the memory will need to be
allocated for the char data, and the std::string pointer updated to point
to it. I don't see how this would be possible at compile time.

[Arno]

Re: Complex objects initialized at compile time

All STL containers contains pointers to allocated memory, but this
problem can be solved quite easily. I simply define the chunk (a string
for std::string or an array for std::vector) as const, and then
initialize the main structure with pointers to that chunk. It all
compiles to a constant, without run-time initialization. Since the
structure is const, the "pseudo-allocated" memory never gets
reallocated or deallocated, so the fact that the memory lies in the
code section rather than on the heap makes no difference to the
program.

The whole thing becomes tricky because complex structures would contain
many levels of such indirection. In case of std::vector< std::string >[color=blue]
>, the vector points to its internal buffer containing std::string, which in turn have buffers for their string data. This would have to be defined in an orderly fashion, first raw strings, then the array of std::string structures pointing to the strings, then the vector pointing to the array. Hence the need for template metaprogramming .[/color]

[Daniel T.]

Re: Complex objects initialized at compile time

In article <1139742794.767 822.287950@g44g 2000cwa.googleg roups.com>,
"Arno" <aschoedl@thi nk-cell.com> wrote:
[color=blue]
> Hello,
>
> here is my problem: I have a complex data type, like a std::vector<
> std::string > and need some global constant values of this type. The
> type is also used non-constant throughout the program, so I do not want
> to use dumb types, but rather STL things.
>
> In the best of worlds, initialization of these constants would not
> happen at runtime, but at compile time, essentially generating a
> constant memory image of this type via meta-programming. Has anyone
> made any attempts in this direction?
>
> I have written some simple macros that do it in Visual C++ 2005 for
> std::vector< integral_type >. Of course, it is non-portable, but the
> general principle _would_ be portable, with merely the exact memory
> arrangement to be non-portabel.
>
> Any ideas?[/color]

I suggest you look at using a class like Stroustrup's c_array (from "The
C++ Programming Language") and make a c_string class as well.

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

[Arno]

Re: Complex objects initialized at compile time

The problem with this approach is that it makes const and non-const
types incompatible with each other. Say I have a struct _numberformat,
that stores prefix and suffix to a number as a std::string. Now I want
to a) use a few constant items of this type for default _numberformats,
and b) allow user-defined _numberformats, which are non-const. But when
calling a function datafield.SetNu mberFormat( _numberformat const& ), I
want to be able to supply either const or non-const _numberformats.

[Daniel T.]

Re: Complex objects initialized at compile time

In article <1139765918.882 955.249120@g47g 2000cwa.googleg roups.com>,
"Arno" <aschoedl@thi nk-cell.com> wrote:
[color=blue]
> The problem with this approach is that it makes const and non-const
> types incompatible with each other. Say I have a struct _numberformat,
> that stores prefix and suffix to a number as a std::string. Now I want
> to a) use a few constant items of this type for default _numberformats,
> and b) allow user-defined _numberformats, which are non-const. But when
> calling a function datafield.SetNu mberFormat( _numberformat const& ), I
> want to be able to supply either const or non-const _numberformats.[/color]

Templates to the rescue. The only variability is on types, either a
c_string class or a string class...

--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.