v2.0 of Identification library

[Joel Falcou-3]

I've uploaded an updated version of the identification library in the
Vault some weeks ago and IIRC I forgot to mention it.

 From the doc :
"Boost.Identification is a library which aims at providing a simple
solution for building a textual representation of a type as a string
that can be manipulated at run-time. Such a feature is often desirable
when someone wants to dynamically debug large template class
instantiation or use a easy to use `type string representation` to use
in serialization process or exception display. Those tasks are often
done using the typeid operator but its output is compiler dependant and
often produce strings which are usually hard to decipher."

Comments and remarks are most welcome.
I'll also ask vicente to add it to the Library In Progress wiki page.
Thanks in advance.

--
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Steven Watanabe-4]

AMDG

joel wrote:

> I've uploaded an updated version of the identification library in the
> Vault some weeks ago and IIRC I forgot to mention it.
>
> From the doc :
> "Boost.Identification is a library which aims at providing a simple
> solution for building a textual representation of a type as a string
> that can be manipulated at run-time. Such a feature is often desirable
> when someone wants to dynamically debug large template class
> instantiation or use a easy to use `type string representation` to use
> in serialization process or exception display. Those tasks are often
> done using the typeid operator but its output is compiler dependant
> and often produce strings which are usually hard to decipher."
>
> Comments and remarks are most welcome.
> I'll also ask vicente to add it to the Library In Progress wiki page.
> Thanks in advance.

* Most files fail to #include their in-library dependencies.
* names containing double underscores are reserved
* in pod.hpp, char should always be a distinct type from signed char
* pod.hpp should really be called builtin.hpp or arithmetic.hpp, since
  UDTs can be POD.

In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

Steven Watanabe wrote:
> * Most files fail to #include their in-library dependencies.
I've movd some more to detaisl and fixed the user interface one.
> * names containing double underscores are reserved
Fixed.
> * in pod.hpp, char should always be a distinct type from signed char
I remember having problem with gcc 3.3 on MAC OS X  10.4 with this,
complaining that template overloaded for char and signed char were
ambiguous.
> * pod.hpp should really be called builtin.hpp or arithmetic.hpp,
> since  UDTs can be POD.
Fixed.

v0.3 is uploaded on the Vault.

--
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

Hi,
----- Original Message -----
From: "joel" <joel.falcou@...>
To: <boost@...>
Sent: Friday, June 26, 2009 11:23 PM
Subject: [boost] v2.0 of Identification library


>
> I've uploaded an updated version of the identification library in the
> Vault some weeks ago and IIRC I forgot to mention it.
>
> I'll also ask vicente to add it to the Library In Progress wiki page.
> Thanks in advance.

Done

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

vicente.botet wrote:
> Done
Thanks.
Side note, the Introspection entry is linking to an incorrect Sandbox
library. As it seems there's alreayd a introspection stuff, I will maybe
change the name of mine to something else.

--
___________________________________________
Joel Falcou - Assistant Professor
PARALL Team - LRI - Universite Paris Sud XI
Tel : [phone]


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

----- Original Message -----
From: "joel" <joel.falcou@...>
To: <boost@...>
Sent: Saturday, June 27, 2009 2:04 PM
Subject: Re: [boost] v2.0 of Identification library


>
> vicente.botet wrote:
>> Done
> Thanks.
> Side note, the Introspection entry is linking to an incorrect Sandbox
> library. As it seems there's alreayd a introspection stuff, I will maybe
> change the name of mine to something else.

Sorry for the bad link. I was not checked the contents matched.
The author is Jean-Louis Leroy <jl@...>. For the moment I have added a Boost.Introspection2 pointing to the Boos Sandbox.

Best,
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Joel Falcou-3]

Ok, some questions.

I thought it could have been nice to have pre-registered identification
informations for things like :
 * stl components
 * major boost component (MPl, fusion, proto, array, containers ?)

However I think this has to be done on a 'optionnal' basis like

#include <boost/identification/registration/<component_name>.hpp>

Dos this looks right or not ? Then, for stuff like MPL and such, should
I pre-register internal elements ?

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Vicente Botet Escriba]

Joel Falcou-3 wrote:

Ok, some questions.

I thought it could have been nice to have pre-registered identification
informations for things like :
 * stl components
 * major boost component (MPl, fusion, proto, array, containers ?)

However I think this has to be done on a 'optionnal' basis like

#include <boost/identification/registration/<component_name>.hpp>

Dos this looks right or not ?

Hi,

What about using the same file name as the original one and put them in a specific directory as stl or boost?

#include <boost/identification/std/<file_name>.hpp>
#include <boost/identification/boost/<specific_lib>/<file_name>.hpp>

The typeof library follows already this schema for the STD files.

Later on when a library wants to provide a registration for its own types, it could use the following pattern

#include <boost/<specific_lib>/identification/<file_name>.hpp>

I have used this to add typeof registration to the types in my Boost.Async library.

#include <boost/async/typeof/threader.hpp>

Joel Falcou-3 wrote:

Then, for stuff like MPL and such, should
I pre-register internal elements ?

I don't think any implicit pre-registration will be useful. The user needing a given registration need to include the corresponding file.

HTH,
Vicente

[Matus Chochlik]

On Fri, Jul 3, 2009 at 2:58 PM, Vicente Botet
Escriba<vicente.botet@...> wrote:

>
>
> Joel Falcou-3 wrote:
>>
>> Ok, some questions.
>>
>> I thought it could have been nice to have pre-registered identification
>> informations for things like :
>>  * stl components
>>  * major boost component (MPl, fusion, proto, array, containers ?)
>>
>> However I think this has to be done on a 'optionnal' basis like
>>
>> #include <boost/identification/registration/<component_name>.hpp>
>>
>> Dos this looks right or not ?
>>
> Hi,
>
> What about using the same file name as the original one and put them in a
> specific directory as stl or boost?

The Mirror library uses a similar approach for including preregistered
STL/Boost-related meta-classes an it seems to be working fine.

For example to use meta-type for ::std::list<> it is necessary to
#include <boost/mirror/meta_type/std/list.hpp>,
to use meta-type for ::boost::variant you need to
#include <boost/mirror/meta_type/boost/variant.hpp>, etc.



>
[snip]
--
________________
::matus_chochlik
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost