Boost exceptions under Windows

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. Zack

Zack S wrote:
Boost shouldn't be concerned about how to handle uncaught exceptions (and only those you could possibly be talking about), as this is a business for end-users, who do in fact have some control over this, as I'm told. (Don't let me get started on how angry I get each time I start a long command-line driven build on a remote windows machine, only to find out after a day the process got stuck in a displayed error dialog, visible on some machine in a distant data center on the other end of the planet...) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

On Tue, Jun 3, 2008 at 8:05 AM, Zack S <zck501@yahoo.com> wrote:
There is a Visual Studio option which does just what you want. It's in the Debug/Exceptions dialog box. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2008/6/3 Emil Dotchevski <emil@revergestudios.com>:
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 /$

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

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:
best regards, -- ________________ ::matus_chochlik

Matus Chochlik a écrit :
Well, I'll be glad to collaborate then. If you want we can share our respective appraoch and try to build up something. My regular email is in my signature :) Feel free to contact me -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI -- France joel.falcou@u-psud.fr

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:
best regards, -- ________________ ::matus_chochlik _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Andrew James a écrit :
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

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

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. -- Joel FALCOU Research Engineer @ Institut d'Electronique Fondamentale Université PARIS SUD XI France

On Sat, Jun 7, 2008 at 10:53 AM, Joel FALCOU <joel.falcou@u-psud.fr> wrote:
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 ;)
-- ________________ ::matus_chochlik

On Tue, Jun 10, 2008 at 1:31 AM, Frank Birbacher <bloodymir.crap@gmx.net> wrote:
Well, unless you want to do something else with the type name besides writing it into an ostream ;)
-- ________________ ::matus_chochlik

Matus Chochlik a écrit :
Well, unless you want to do something else with the type name besides writing it into an ostream ;)
Well, then, the type of return of the function shoudl be parametrizable in some way. In my version, I just have a : #ifndef BOOST_IDENTIFY_CONFIG_STRING_TYPE #define BOOST_IDENTIFY_CONFIG_STRING_TYPE std::string #endif and I assume thsi type has the proper = and + operator but it should be better to define those as policies.

Hi! Matus Chochlik schrieb:
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
participants (10)
-
Andrew James
-
Emil Dotchevski
-
Frank Birbacher
-
Henrik Sundberg
-
Joel Falcou
-
Joel FALCOU
-
Mathias Gaunard
-
Matus Chochlik
-
Stefan Seefeld
-
Zack S