2008/6/3 Emil Dotchevski <emil@revergestudios.com>:

On Tue, Jun 3, 2008 at 8:05 AM, Zack S <zck501@yahoo.com> wrote:

...

Hi folks,

Why doesn't the Boost code, in the cases where it needs to throw an exception under Windows, offer the option to display a dialog window? Something like a #define'able option could be useful.

There is a Visual Studio option which does just what you want. It's in the Debug/Exceptions dialog box.

It can be really difficult to get exceptions instead of dialogs, see the old thread: http://lists.boost.org/Archives/boost/2007/11/130336.php /$

Hi, The mirror library which I happen to be developing ;-) does (among other stuff) a similar thing. The library is still in early stages of development, but if you're interested, the current version can be found both in the sandbox and in the vault. My implementation has some drawbacks, like the need to do type/template registering before they can be reflected so I would definitelly like to look at your implementation. On Fri, Jun 6, 2008 at 6:15 PM, Joel FALCOU <joel.falcou@u-psud.fr> wrote:

Hello,

during the past years, I stumbled across various bugs in template meta-programms and found useful to have a small tools that is able to display at runtime the exact type of a given object or template type as a basic std::string in code fragments like :

template<class T, template<class,class> class X > struct { static inline DoSomething( T const & x) { // soem code std::cout << "Currently instanciating : " << identify< X<T,typename T::type> >::Name() << std::endl; } };

Basically this small library replace typeid and its non-standard name() method by a meta-programmed class (identify) which is able to handle various classic types (being template or not themselves). I was wondering if such a library could be of interest and be submitted as a possible addition to Boost or if this scope (type name display) was too mundane.

If the former, I'll be glad to post some more material and discuss a possible rationale.

Regards

-- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France

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

best regards, -- ________________ ::matus_chochlik

I myself have also implemented a class that has these features within a "traited" framework (explanation to follow). The challenge I have seen, that I'm not clear if it is expressed here, is what if the type whose name you want to dump is also dependent on some template parameter that a frameword user is in charge of? // potential forward declaration to be specialized template < typename SomeType_ > struct TypeName; template < typename Traits_ > void DoSomething( const TraitedClass< Traits_ >& t ) { std::coit << TypeName< TraitedClass< Traits_ > >::Name() << "\n"; } //Doesn't seem to me the following works and I want this so // I can have some general name that reflects a traited class // with no full specialization. This is expressing the fact that // I can not apriori tell what all future traits will be template < typename Traits_ > struct TypeName< typename TraitedClass< Traits_ > > { }; So, what I really have to do is template < typename Traits_, typename T_ > struct TypeName; template < typename Traits_ > void DoSomething( const TraitedClass< Traits_ >& t ) { std::cout << TypeName< Traits_, TraitedClass< Traits_ > >::Name() << "\n"; } template < typename Traits_ > struct TypeName< Traits_, TraitedClass< Traits > > { }; These things being said, I realize this is specific to my framework but it illustrates some issues a boost supported solution could provide. We should be able to debug types like std::vector< SomeTypeTheDebugLibraryIsCluelessAbout > w/o requiring the user do a similar amount of work to writing the facility him/herself. --aj On 6/6/08 10:26 AM, "Matus Chochlik" <chochlik@gmail.com> wrote: Hi, The mirror library which I happen to be developing ;-) does (among other stuff) a similar thing. The library is still in early stages of development, but if you're interested, the current version can be found both in the sandbox and in the vault. My implementation has some drawbacks, like the need to do type/template registering before they can be reflected so I would definitelly like to look at your implementation. On Fri, Jun 6, 2008 at 6:15 PM, Joel FALCOU <joel.falcou@u-psud.fr> wrote:

Hello,

during the past years, I stumbled across various bugs in template meta-programms and found useful to have a small tools that is able to display at runtime the exact type of a given object or template type as a basic std::string in code fragments like :

template<class T, template<class,class> class X > struct { static inline DoSomething( T const & x) { // soem code std::cout << "Currently instanciating : " << identify< X<T,typename T::type> >::Name() << std::endl; } };

Basically this small library replace typeid and its non-standard name() method by a meta-programmed class (identify) which is able to handle various classic types (being template or not themselves). I was wondering if such a library could be of interest and be submitted as a possible addition to Boost or if this scope (type name display) was too mundane.

If the former, I'll be glad to post some more material and discuss a possible rationale.

Regards

-- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France

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

best regards, -- ________________ ::matus_chochlik _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Fri, Jun 6, 2008 at 10:21 PM, Joel FALCOU <joel.falcou@u-psud.fr> wrote:

Andrew James a écrit :

...

I myself have also implemented a class that has these features within a "traited" framework (explanation to follow). The challenge I have seen, that I'm not clear if it is expressed here, is what if the type whose name you want to dump is also dependent on some template parameter that a frameword user is in charge of? [...] These things being said, I realize this is specific to my framework but it illustrates some issues a boost supported solution could provide. We should be able to debug types like std::vector< SomeTypeTheDebugLibraryIsCluelessAbout > w/o requiring the user do a similar amount of work to writing the facility him/herself.

I'm not sure if I understood the problem but currently my identify<> class can take care of user defined type or user_defined tempalte by using a simple register macro. I also have a on going list of pre-registered type for STD and parts of BOOST.

Here is a small example :

#include <boost/identify/identify.hpp> #include <boost/identify/support/std.hpp>

// Some user template classes template<class A1,class A2,class A3,class A4,size_t A5> struct foo {}; template<class A1,class A2> struct chu{};

// some class struct coin {};

BOOST_IDENTIFY_REGISTER_TYPE_ID(coin) BOOST_IDENTIFY_REGISTER_CUSTOM_TEMPLATE_TYPE_ID( (class)(class)(class)(class)(size_t), foo) BOOST_IDENTIFY_REGISTER_TEMPLATE_TYPE_ID(chu,2)

template<class T> struct Test { static inline void Do() { cout << boost::identify<T>::Name() << endl; } };

int main() { Test<char>::Do(); Test<coin>::Do(); Test<chu<float,coin> >::Do(); Test< std::vector< chu<void,void*>& > >::Do(); Test<foo<float,long*,volatile double,coin,3> >::Do(); }

The results are :

char coin chu<float, coin> std::vector< chu<void,void*>& foo< float, signed long*, volatile double, coin, 3 >

the identify.hpp grants the main identify class ans supports for basic types (POD, pointer, reference, cv qualified types, function types, function pointers and array mostly) while the support/std.hpp provides pre-registered identify overload for STD types.

The macro BOOST_IDENTIFY_REGISTER_TYPE_ID declares a new user types to be displayed. BOOST_IDENTIFY_REGISTER_TEMPLATE_TYPE_ID does the same for template class with less than 5 tempalte parameters which are all of tpye class. BOOST_IDENTIFY_REGISTER_CUSTOM_TEMPLATE_TYPE_ID allows registering tempalte class with more than 5 parameters and with integralk parameters by specifying a BOOST_PP_SEQ of the arguments. The burden is no greater for me than registering a type for BOOST_TYPEOF and is fairly acceptable.

Not sure if other cases are needed. My main concern is being able to display non-instanciated template class, eg:

identify<std::vector>::Name() displaying std::vector

but this may need another class (like incomplete_identify<> maybe).

-- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France

The mirror library works from the programmer's point of view this way: // define a rather complex type T // typedef tuple<int, double, const string*> T1; typedef tuple<const bool, volatile float, void * const, char> T2; typedef pair<T1, T2> T3; typedef tuple<void*, const wstring& , const string&> T4; typedef tuple<char, wchar_t, short int const> T5; typedef pair<T4, T5> T6; typedef vector<tuple<T1, T2, T3, T4, T5, T6> > T7; typedef set<map<list<T1>, T7> > T; // // reflect the class using mirror. the "result" is a meta_class typedef BOOST_MIRROR_REFLECT_CLASS(T) meta_T; // // among many other things there are member functions // that return the typename of the reflected type // // the base_name returns the type/class/template // names without nested-name-specifiers // i.e. vector<pair<int, string> > // bcout << "The type name is: "<< meta_T::base_name() << endl; // // this version returns the fully qualified name like // ::std::vector<::std::pair<int, ::std::string> > bcout << "The full type name is: "<< meta_T::full_name() << endl; there are several examples showing this in the sandbox: http://svn.boost.org/svn/boost/sandbox/mirror/libs/mirror/example/ especially http://svn.boost.org/svn/boost/sandbox/mirror/libs/mirror/example/special/st... http://svn.boost.org/svn/boost/sandbox/mirror/libs/mirror/example/special/bo... (sry for the long links) the meta_class specializations for the templates like pair, vector, tuple, etc. are currently hand-coded, and using some common boilerplate to handle the template param names, but I'm working on some registering macros similar to Joel's. see for example: http://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/meta_classes/std_... -- ________________ ::matus_chochlik

On Sat, Jun 7, 2008 at 10:53 AM, Joel FALCOU <joel.falcou@u-psud.fr> wrote:

...

the meta_class specializations for the templates like pair, vector, tuple, etc. are currently hand-coded, and using some common boilerplate to handle the template param names, but I'm working on some registering macros similar to Joel's. see for example: http://svn.boost.org/svn/boost/sandbox/mirror/boost/mirror/meta_classes/std_...

Seems mirror has a far broader usage than my humnle identify<> ! I like the possibility of reflecting any parts of a type adn I also understand the gap between this task and mine.

My macro in fact really simple, I "cheat" by using MPL_AUX_LAMBDA_ARITY to detect the number of tempalte parameters and generate the proper specialisation. When it fails, I use a small preprocessor macro using sequence to generate the proper display.

Other difference is my use of std::string as a return type. Seems you have a complex system to compute string length and use char*. Not sure which one is the best but I'm willing to hear the rationale behind this choice.

Well there is no bulletproof ;) rationale behind this. I've made some performance tests with both char* buffer and with ::std::string and char* buffer did better. When formatting the type name of a complicated template there is a lot of string copying and realocation. Calculating the type-name string lenght was not a big issue. The problem with the current implementation is that there are some memory leaks at the program exit but they are not cumulative, but still, fixing this is on my TODO list ;)

-- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France

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

-- ________________ ::matus_chochlik

On Tue, Jun 10, 2008 at 1:31 AM, Frank Birbacher <bloodymir.crap@gmx.net> wrote:

Hi!

Matus Chochlik schrieb:

...

...

Other difference is my use of std::string as a return type. Seems you have a complex system to compute string length and use char*. Not sure which one is the best but I'm willing to hear the rationale behind this choice.

Well there is no bulletproof ;) rationale behind this. I've made some performance tests with both char* buffer and with ::std::string and char* buffer did better. When formatting the type name of a complicated template there is a lot of string copying and realocation.

Which is why there is a stringstream. You won't return anything but instead write into a ostream& directly. This reduces the complexity of the algorithm.

Well, unless you want to do something else with the type name besides writing it into an ostream ;)

Frank

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

-- ________________ ::matus_chochlik

Hi! Matus Chochlik schrieb:

...

Which is why there is a stringstream. You won't return anything but instead write into a ostream& directly. This reduces the complexity of the algorithm.

Well, unless you want to do something else with the type name besides writing it into an ostream ;)

Nah, I'm talking of asymptotic complexity. Say you have a nested type, n levels deep. And each level would add some characters to a string, then return it to the next higher level, like: string getStr(const unsigned n) { if(n==0) return "inner"; return "(-" + getStr(n-1) + "-)"; } Then a call to getStr(n) has complexity O(n*n). Compared to: void putStr(const unsigned n, ostream& stream) { if(n==0) stream << "inner"; else { stream << "(-"; putStr(n-1, stream); stream << "-)"; } } Now a call to putStr(n, somestream) only has complexity O(n). Frank

Mathias Gaunard a écrit :

Several platforms provide functions to demangle the result of std::type_info::name().

Are those functions standard ? Cause well, it can be used to leverage the work I do already by matching if the current platform provide them. ANy more insight on those ? -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France