Hello David, thanks for your clean and simple answer. I also thought about something similar to your answer but I was wondering if there exist some way to calculate that index at compile-time. Looking at the assembly code generated, it doesn't make a big difference to my version where the index values are hard-coded but still... In fact, the question I'm really trying to answer is: what is the price to pay (in term of performance and space) for using an mpl based solution compared to have my array elements initialized by a totally hard-coded function? Up to now what I've found is that my executable is 10% larger and the code is about 4 times slower (again by looking at the assembly code generated). So, if you can think of a more efficient solution I'm still interested. Thanks, Istvan On Monday 26 July 2004 03:36, David Abrahams wrote:

Istvan Buki writes:

...

Hello mpl experts,

I'm trying to initialize the elements of an array using rules defined in a list of structures. The code below illustrate what I'm trying to achieve.

The problem I have with this code is that the First_Descriptor structure contain this index member that will be used to access the right item of the array. This is not nice because it force the writer of this structure to deal with implementation details. Is there a way to get rid of this index typedef in the *_Descriptor structures by using another construct from the mpl that would generate it ?

The easiest thing to do is just to embed the index as a data member in the Initializer object, which can be stateful. Just bump the index each time the Initializer is invoked.

HTH, Dave

I modified my sample code to take advantage of your suggestion to calculate the index at compile time. It works perfectly well and the code generated is faster than my previous version but I still have questions: 1) I'm not sure if this is the right place to ask, if not somebody will certainly be able to point me into the right direction. In the assembly code generated (file attached to this mail), there are two 'call' instructions that seem useless to me. Why not inline the single 'movl' instruction executed as the result of the call? I'm using g++ 3.3.3 with O2 optimization flag and it is probably a very compiler-specific question but perhaps I'm missing something obvious here. 2) By now you probably guessed that my goal is to produce code for embedded use. In this environment standard libraries would not be available. Could you give me some idea how hard it would be to modify the mpl library not to rely on any standard include and lib? Any pointer on where to start are welcome. Thank you for your help, Istvan On Tuesday 03 August 2004 13:56, David Abrahams wrote:

Istvan Buki writes:

...

Hello David,

thanks for your clean and simple answer. I also thought about something similar to your answer but I was wondering if there exist some way to calculate that index at compile-time.

Yes there is.

...

Looking at the assembly code generated, it doesn't make a big difference to my version where the index values are hard-coded but still... In fact, the question I'm really trying to answer is: what is the price to pay (in term of performance and space) for using an mpl based solution compared to have my array elements initialized by a totally hard-coded function? Up to now what I've found is that my executable is 10% larger and the code is about 4 times slower (again by looking at the assembly code generated).

Have you got all optimizations enabled with full inlining? What compiler are you using?

...

So, if you can think of a more efficient solution I'm still interested.

You could use

mpl::zip_view< mpl::vector2< mpl::range_c<0, mpl::size<Descriptors>::value> , Descriptors

as the sequence in your for_each; then each element would contain a compile-time index and a descriptor.

HTH,

On Wednesday 04 August 2004 2:55 pm, Delfin Rojas wrote:

Hi everybody,

I would like to implement C++ reflection for a product I'm building. The C++ reflection is meant for serializing an object in XML, database, etc. Any recommendation of libraries out there that would help me with this reflection effort?

The next release of Boost will include the serialization library. You might look into that before embarking on your own reflection/serialization library... Doug

Istvan Buki writes:

I modified my sample code to take advantage of your suggestion to calculate the index at compile time. It works perfectly well and the code generated is faster than my previous version but I still have questions:

1) I'm not sure if this is the right place to ask, if not somebody will certainly be able to point me into the right direction. In the assembly code generated (file attached to this mail), there are two 'call' instructions that seem useless to me. Why not inline the single 'movl' instruction executed as the result of the call? I'm using g++ 3.3.3 with O2 optimization flag and it is probably a very compiler-specific question but perhaps I'm missing something obvious here.

2) By now you probably guessed that my goal is to produce code for embedded use. In this environment standard libraries would not be available. Could you give me some idea how hard it would be to modify the mpl library not to rely on any standard include and lib?

Should be trivial -- the library has very little dependencies on the standard headers. In fact, 'std::size_t' and LONG_MAX are likely to be the only ones. You'd need to replace the default Boost config headers with your own, though, because those do depend on the presence of various std headers. Please see http://www.boost.org/libs/config/config.htm#advanced_config for the instructions on how to do that. HTH, -- Aleksey Gurtovoy MetaCommunications Engineering