April 2004 - Boost - lists.boost.org

Date-Time, microsec_time_clock.hpp, bug?
by Val Samko 23 Apr '04

23 Apr '04

What is the type of timeval, used in class microsec_clock? It is not declared anywhere, and thus a compile time error in microsec_time_clock.hpp. Val Samko http://val.digiways.com

2 2

Re: Re: [boost] Serialization Formal Review #2
by Robert Ramey 23 Apr '04

23 Apr '04

Matthias Troyer > On Apr 13, 2004, at 9:42 PM, Robert Ramey wrote: >> Making a new archive class is described in the section "New Archives - >> Implementation". The model for an archive class is: > >> ////////////////////////////////////////////////////////////////////// >> /// >> // class trivial_iarchive - read serialized objects from a input text >> stream >> class trivial_iarchive > >> : public boost::archive::common_iarchive<trivial_iarchive> >> { >> // permit serialization system priledged access to permit >> // implementation of inline templates for maximum speed. >> friend class boost::serialization::load_access; > >> // member template for loading primitive types. >> // Override for any types/templates that special treatment >> template<class T> >> void load(T & t); > >> public: >> ////////////////////////////////////////////////////////// >> // public interface used by programs that use the >> // serialization library > >> // the >>> operator >> template<class T> >> trivial_iarchive & operator>>(T & t){ >> boost::serialization::load(* This(), t); >> return * This(); >> } > >> // archives are expected to support this function >> void load_binary(void *address, size_t count); > >> }; > >> So in theory one has to implement the two undefined functions. > >> For each primitive data type, int, float, etc. or any type designated >> as primitive define a "load" template for function to read them from the >> file. > >> For each data type that you want to treat specially - rather than >> allowing the serialization library to do the job - define an overload >> for operator. > Just a quick question: what should the default load (I mean > template<class T>> void load(T & t);) function do? Do I guess correctly > that it should never be called and is thus undefined to cause link-time > errors? It should handle all primitives not otherwise handled specifically. For example the default load for text archives resolves to input_stream >> t While for binary archives it resolves to load_binary(sizeof(t), t). > Looking through the documentation I find references to virtual > functions: And? >> class trivial_iarchive >> // all input archives must be derived from this base class. This base >> // class defines the virtual functions necessary for the serialization >> // library to handle special types for the serialization system. > I guess that these are incorrect comments left over from an old version? Correct. Robert Ramey

3 2

"typeof" implementation idea
by Arkadiy Vertleyb 22 Apr '04

22 Apr '04

"David Abrahams" <dave(a)boost-consulting.com> wrote > That's the basic idea behind all typeof() emulations that I've ever > seen. They all require some type registration to associate a > compile-time integral constant with a type. The innovation that Steve > brought, IIUC, was that with the registration of only class types, the > rest of the transformations possible in the type system could be > encoded by the library automatically. For example, if you register > class Foo, then the library can generate encodings for Foo*, Foo[2], > Foo**, int (Foo), Foo(*)(Foo,Foo), etc., so you don't have to register > those types. The problem is that those numbers can get very large... Right. What I am even more interested in, is the ability to generate encodings of complicated templates. Say I registered int, std::vector, and mpl::vector2, and the library should be able to work with std::vector<int>, mpl::vector2<std::vector<int>, mpl::vector2<int, int> >, etc. It looks like this can be solved pretty easily. I imagine that Boost.Lambda, for example might also benefit from the ability to encode/decode templates (and maybe Spirit, but I am not sure). > My guess is that manipulating array types in that way has a lower > cost at compile-time than using a vector_c, though using mpl probably > yields much nicer library code and vector_c is more portable. I don't suspect my solution is very compile-time efficient. But I don't have enough knowledge of compilers internals to estimate this. I believe the real advantage is in is simplicity. Anyway, here it is... Let's recall that to achieve our goal we have to: 1) Pass our expression to a function template, like: template<class T> SOMETHING foo(const T&); 2) inside foo() encode our type into a compile-time list of integers; 3) somehow manage to pass this list through the function boundaries; 4) decode the type. The most chalanging is 3. Let's define the following template: template<class N> struct sizer { char_[N::value]; }; The whole purpose of this is to create classes with a given sizeof (to be completely accurate we have to then divide this by sizeof(char)). Next template is what it is all about: template<class IntList> struct multi_int { typedef IntList int_list; template<class T> sizer<typename mpl::apply_if< typename mpl::less<T, typename mpl::size<int_list>::type>, mpl::at<IntList, T>, mpl::identity<mpl::int_<1> > >::type> get(const T&); }; So, if we have an object of this class, x, then sizeof(x.get(mpl::int_<n>())) defines the nth element of the list, and out-of-range values produce 1. The list can be reproduced like, say: #define BOOST_RTL_TYPEITEM(Expr, N)\ mpl::int_<sizeof(Expr.get(mpl::int_<N>()))> mpl::vector<\ BOOST_RTL_TYPEITEM(x, 0) , BOOST_RTL_TYPEITEM(x, 1) ... , BOOST_RTL_TYPEITEM(x, N) > Where it can be generated by the preprocessor for a fairly large N. The reproduced list is larger than the original one, and is 1-padded. The encoding scheme I use does not require to know where the list ends, so this doesn't matter. This is basically it. The return type of the function foo above (sorry for such name) is going to be multi_int<encode<T>::type>, where T is the original type, and encode template works accordingly to some encoding scheme. The encoding scheme to choose is a separate issue. In my example I encode templates by adding the encodings of its parameters to the code of template itself. So, if int is 1, std::vector is 2, and mpl::vector2 is 3, the above example: mpl::vector2<std::vector<int>, mpl::vector2<int, int> > becomes 3 2 1 3 1 1 Also note that all templates with one parameter behave similarly, so only one registration macro is required. Another macro is required to register templates with two parameters, etc. > For what it's worth, I'm pretty sure I know how to solve the problem > that most typeof() implementations strip top-level references. See > boost/iterator/is_lvalue_iterator.hpp for a demonstration. Cool. I imagine pointers are pretty easy, but references surely represent a big problem... I will follow up with the working sketch... Regards, Arkadiy

4 8

thread API
by Christophe Meessen 22 Apr '04

22 Apr '04

Hello, I have axamined the thread_dev header file. Unfortunately the cpp file doesn't seem to correspond. I must admit that the proposed change is a great improvement and removes many objections I had regarding boost thread. Changing the thread object into a handle allows now to copy it. It is then possible to add a thread member variable to a class. A start method can then assign the started thread instance to it. So the gap between boost threads and start&run model gets narrow. The source is one year old. What is the time plan to release it ? -- Bien cordialement, Ch. Meessen

2 1

boost on HPUX
by Toon Knapen 22 Apr '04

22 Apr '04

I'm trying to get the regression tests on HPUX up to date again. However, the 'random_test' loops indefinitly (in the kreutzler1986 test) when compiled with gcc 3.2 (20020329). Additionally I can't debug it since there are no precompiled gdb's available from HP and gdb 6.1 is AFAICT not supported on HPUXi 11.22. So before starting commenting parts out of the random_test to find the line where it hangs, anybody (who's familiar with the implementation of this test) any idea where I should start looking ? toon

1 0

Re:[boost] Re:Formal review: serialization
by Robert Ramey 22 Apr '04

22 Apr '04

Vladimir Prus wrote: > Robert Ramey wrote: > > >> -- (critical) The primary issue with the library is lack of reference > >> documentation > ... OK I don't see a problem with this - Thanks to Dave for the hint on how to handle this. > For those stubs, requirements docs that Dave mentioned would be nice. > However, there's code that user calls, and I'd like to see docs for that, > too. > > For example: > > binary_object make_binary_object(void* ptr, unsigned size); > Returns: binary_object(ptr, size); > > binary_object::save(Archive& ar, unsigned version) > Effects: Calls ar.save_binary(m_ptr, m_size); > > binary_object::load(Archive& ar, unsigned version) > Effects: Calls ar.load_binary(m_ptr, m_size); > Aside - I wouldn't expect load/save/load_binary/save_binary to ever be invoked by a library user. > It would be nice to avoid asking the user to do BOOST_CLASS_EXPORT for all > possible argument types. What's desirable is: > > template<class T> > void register_rpc_function(const char* name, void (*f)(const T&)) > { > functions[name] = ... ; > boost::serialization::export_class< function_call_1<T> > >::instantiate(); > } > > I can't put BOOST_CLASS_EXPORT in register_rpc function now. This situation is discussed in the documentation under the heading "Template Serialization Traits". There is an example that uses assignation of traits to the nvp<T> template. BOOST_CLASS_EXPORT is just a syntactic short hand to for the specialization above. Uh-oh - I just looked at the definition of BOOST_CLASS_EXPORT and I see it's not that obvious as it is in the other traits. I'll take a look at this. > I'm afraid the no matter how smart XML reader is, it still would have to > scan the entire file. > So what's wrong with that? I would guess that such an XML reader already exists somewhere and you cat get everything thing for free. Assuming this doesn't address your need, and you want to do some programming, one can create another XML archive version. This would create two output files. One exactly as it is now will another "index". When I was considering the options regarding XML output I briefly considered the possibility of creating two files - one like we have the one now - along with an optional parallel file containing the corresponding XML schema describing the XML archive. I decided to keep things simpler. But I think you see the idea. > > I can expand the doc a bit. binary_object is just a wrapper around a > size > > and pointer to permit them to be handled as pair. It presumes the > pointer > > already points to allocated storage. > > This last sentence is exactly what I'd like added to docs. > OK that's easy. Sorry for the confusion. > > It also presumes that the the size > > of thing its pointing to is the same on save and load. Its very > > lightweight. > > > > I don't see a need for the others, but of course any user can make the > > wrappers he needs. > > The reason why I think the other is important, it that's it's actually > saving/loading support for plain C++ array -- which is rather basic thing. > Hmmm - the library already implements serialization of plane C++ arrays by serializing each element. This is the more general solution as it calls serialization for each element. The only time one might want to do save/load for a whole array is for a non-portable binary file. Re: save/load asymmetry for polymorphic pointers. > As I've said previously, this is a bug which is easy to make and very hard > to debug. I think we can only wait for others to express an opinion, as we > fail to convince each other. Well, THAT we can agree on. > > BTW, one usage of XML archives did occur to me. By checking the name > tag > > on input, we can implement a crude check that save and load operations > are > > synchronized. This would effectively a debug mode for archives and > might > > be useful. > > But you won't catch a case where you save one type and load another. True, but I think it would help a lot - and practically free to implement. > So, the get zero overhead I need to tweak base class an disable tracking > of > pointers. Let me try that... yea, the results are nice. One one extra > element (class id) per saved item. If your not serializing pointers, the class_id isn't written to the archive even once. Object id is required for tracking, class id is required for pointers. If versioning is used, class-id is used once. I do not believe that there is any information stored in an archive which is not used. > > BTW, how to I set tracking level and implementation level for a template > class. I think I can partially specialize 'tracking_level', but it should > be mentioned in the docs. See docs section "Template Serialization Traits" > > >> - The documentation should really state the minimal set of > 'load'/'save' > >> overloads which will make archive usable. For example, it's probably > not > >> necessary to provide separate overload for 'bool', right? > > > > The document states: > > > > " However, we're not quite done. The above code addresses serialization > of > > all non-primitive types. To be complete, each primitive type must either > > be covered by a definition of template<typename T> void load(T & t); or > an > > overload of the >> operator" > > It also necessary to provide overload for char*. Does not count as > primitive > type? Default implementation for char * will work as it does for other pointers. Which is probably not what one has in mind. I have code in there for handling it as a c string (Its commented out). I tested it and it worked but I came to conclude it presented a big security risk. The problem is the following: char * str = "abc" ar << str; // no problem the (text) archive looks like 3 abc later: char str[MAX_STRING_SIZE] ar >> static_cast<char *>(str); // to avoid str being treated as an array suppose the text archive gets corrupted to: 3000 abc............ The archive will load with a buffer overrun - a security risk. So then one should dynamically allocate the storage according to the size - that is one should be using the std::string . So I decided to comment out the code that handles char *. > > > " If all primitive types have been accounted for, any program with > > serialization defined should work with the new archive." > > > > Maybe I can expand upon that a little to something like: > > > > "Any program with serialization defined should work with the new archive > > as long as every primitive type has a matching save/load function > > prototype or template." > > Can I define only one 'load' for unsigned int? As oppose to ? They way I implemented the included archives I specified load for those requiring special treatment and used a template as a fall back for the rest. BTW this provided a huge benefit. In the original version of last year I got into a never-ending battle to specify virtual functions which was dependent on the compiler - long long, etc. It was hopeless - moving to templates solved that. > > > > I've concluded this myself. Its pretty easy given the bjam setup. > Maybe > > it can be made even easier with a bjam argument or environmental > variable. > > It > > just needs to be explained. > > Right. BTW as a bjam expert, you might want to suggest how to do this in cool way. I would love to have a shell script which lets me do test_archive <toolset> <archive> But I don't see how to fix up the bjam files to support this. As a bjam expert, maybe you could look into this. > Do you mean you plan to always serialize char* as arrays and remove > 'load'/'save' overloads for char*? Again, I'm not sure I understand the > motivation. See above Robert Ramey

2 1

Serialization - access control
by Matthew Vogt 22 Apr '04

22 Apr '04

Previously, I posted that I was unhappy with the way access to an archive's save methods could be controlled. This was because the class the eventually invokes the 'save' method of an oarchive is a library class, and has to be given friend access. I have now realised that this was trying to control access the wrong way; instead of making the type-specific 'save' method private, the type-specific overload of 'operator<<' should made private to prevent general access for saving a given type. Here is a basic test that shows what I had been trying to achieve, now working correctly: //--------------------------------------------------------------------------- #include <boost/serialization/access.hpp> #include <boost/archive/common_oarchive.hpp> class float_storer { friend class boost::serialization::access; private: float f; template<class Archive> void serialize(Archive& archive, const unsigned int version) { archive & f; } }; namespace archive = boost::archive; class simple_oarchive : public archive::common_oarchive<simple_oarchive> { friend class archive::common_oarchive<simple_oarchive>; friend class archive::save_access; // Do nothing with library internal types simple_oarchive& operator<< (const archive::class_id_type&) { return *this; } simple_oarchive& operator<< (const archive::class_id_optional_type&) { return *this; } simple_oarchive& operator<< (const archive::class_id_reference_type&) { return *this; } simple_oarchive& operator<< (const archive::class_name_type&) { return *this; } simple_oarchive& operator<< (const archive::version_type&) { return *this; } simple_oarchive& operator<< (const archive::object_id_type&) { return *this; } simple_oarchive& operator<< (const archive::object_reference_type&) { return *this; } // Save any type that gets here template<typename T> void save(const T& t) {} // Only allow 'float_storer' to store floats friend class float_storer; simple_oarchive& operator<< (const float& t) { archive::save(*This(), t); return *This(); } public: // Allow anyone to store ints simple_oarchive& operator<< (const int& t) { archive::save(*This(), t); return *This(); } simple_oarchive& operator<< (const float_storer& t) { archive::save(*This(), t); return *This(); } }; int main(int, char**) { simple_oarchive oa; int i; oa << i; float f; oa << f; // I want this to fail float_storer fs; oa << fs; // I want this to succeed return 0; }

1 1

Re: Re: Re: numeric_cast
by Dill, John 21 Apr '04

21 Apr '04

"Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404211327.i3LDRov09314(a)lawrencewelk.systems.susq.com>... > From: "Dill, John" <john-dill(a)uiowa.edu> > > "Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404202049.i3KKnwe25029(a)lawrencewelk.systems.susq.com>... > > > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > "Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404201905.i3KJ55e08992(a)lawrencewelk.systems.susq.com>... > > > > > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > > > > > > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > > > > > > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > > > > > char schar_value = 0; > > > > > > > > > > > > try { > > > > > > schar_value = boost::numeric_cast<char>( uchar_max ); > > > > > > } > > > > > > catch ( boost::bad_numeric_cast ) > > > > > > { std::cout << "Overflow occurred..." << std::endl; } > > > > > > > > > > > > When I execute this sample, I don't get the exception. What's > > > > > > the background on this behavior? I'm using gcc 3.3.1. > > > > > > > > > > Your char is unsigned. > > > > > > > > I'd like to know why conceptually the exception isn't thrown. > > > > > > As I said, in too few words, is that your "char" is unsigned, so > > > "char" and "unsigned char" are essentially the same type. > > > Technically, they are distinct types (for overloading purposes, > > > for example), but they are both unsigned and the same size, so: > > > > > > assert(std::numeric_limits<char>::max() > > > == std::numeric_limits<unsigned char>::max()); > > > > > > on your system. > > > > Actually that is not the case. The max defined for unsigned > > char is 255, while for char is 127. Actually, char is > > supposedly equivalent to signed char, not to unsigned char. > > Based upon the evidence you presented, I concluded that your char > is equivalent to unsigned char. On what basis do you conclude > that your char is equivalent to signed char? Did you check > std::numeric_limits<char>::is_signed? Yes. Both char and signed char have identical is_signed and max, min. Unsigned char min, max and is_signed is different. Does the standard say that char can be either signed char or unsigned char, or is that just an implementation issue? Best, John

3 2

Re: numeric_cast
by Dill, John 21 Apr '04

21 Apr '04

"Fernando Cacciola" <fernando_cacciola(a)hotmail.com> wrote in message news:<c64iag$bes$1(a)sea.gmane.org>... > > "David Abrahams" <dave(a)boost-consulting.com> escribió en el mensaje > news:u3c6ywa5w.fsf@boost-consulting.com... > > "Dill, John" <john-dill(a)uiowa.edu> writes: > > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > > char schar_value = 0; > > > > > > try { > > > schar_value = boost::numeric_cast<char>( uchar_max ); > > > } > > > catch ( boost::bad_numeric_cast ) > > > { std::cout << "Overflow occurred..." << std::endl; } > > > > > > When I execute this sample, I don't get the exception. What's the > > > background on this behavior? I'm using gcc 3.3.1. > > > > FWIW, there are known problems with numeric_cast, but a numeric > > conversion library that replaces the existing implementation has been > > accepted into Boost. We are just waiting for Fernando Cacciola to > > check it in. Fernando? > > > Indeed. The accepted numeric conversions library handles this case properly > (throwing). > Right now I'm technically on vacation until next Monday. I'll start working > with the review comments right next week. I'll check it in on CVS after I > made the neccesary changes. > > Anyway, users can download the review version from here: > > http://personales.ciudad.com.ar/fernando_cacciola/numeric_conversions.zip > > or > > http://groups.yahoo.com/group/boost/files/numeric_conversions.zip > > > Fernando Cacciola Thanks. Well, I didn't know this was out there so I wrote my own numeric_cast which works for those cases I described. It's not boost oriented, but all of the concepts should be convertible to mpl. Maybe it will be useful to someone. Best, John /*! * \file numeric_cast.hpp * \brief A cast which protects against silent underflow or overflow casts. */ #include <uiro/type/ct_if.hpp> #include <uiro/type/typelist.hpp> #include <uiro/utility/limits.hpp> namespace uiro { //! Exception used to indicate underflow in a numeric cast. class bad_numeric_cast : public std::bad_cast { public: virtual const char* what() const throw() { return "bad numeric cast"; } }; //! Exception used to indicate underflow in a numeric cast. class numeric_cast_underflow : public bad_numeric_cast { public: virtual const char* what() const throw() { return "underflow in numeric_cast"; } }; //! Exception used to indicate overflow in a numeric cast. class numeric_cast_overflow : public bad_numeric_cast { public: virtual const char* what() const throw() { return "overflow in numeric_cast"; } }; namespace internal { //! Selects the type with the largest minimum value. template <typename T1, typename T2> struct promote_min_traits { typedef TYPELIST_10(unsigned char, unsigned short, unsigned int, unsigned long, char, short, int, long, float, double) promote_order_typelist; enum { index1 = uiro::type::index_of<promote_order_typelist, T1>::value }; enum { index2 = uiro::type::index_of<promote_order_typelist, T2>::value }; typedef typename uiro::type::ct_if< uiro::type::greater_than_equal<index1,index2>::result, T1, T2>::result result; }; //! Selects the type with the largest maximum value. template <typename T1, typename T2> struct promote_max_traits { // May run into issues if sizeof(int) != sizeof(long) typedef TYPELIST_10(char, unsigned char, short, unsigned short, int, long, unsigned int, unsigned long, float, double) promote_order_typelist; enum { index1 = uiro::type::index_of<promote_order_typelist, T1>::value }; enum { index2 = uiro::type::index_of<promote_order_typelist, T2>::value }; typedef typename uiro::type::ct_if< uiro::type::greater_than_equal<index1,index2>::result, T1, T2>::result result; }; struct unsigned_tag {}; struct signed_tag {}; //! A numeric cast helper which handles the an unsigned source type //! without generating compiler warnings. template <typename Target, typename Source> inline Target numeric_cast_helper( Source arg, unsigned_tag ) { // An overflow condition. if ( static_cast<typename promote_max_traits<Source, Target>::result>( arg ) > static_cast<typename promote_max_traits<Source, Target>::result>( std::numeric_limits<Target>::max() ) ) { throw numeric_cast_overflow(); } return static_cast<Target>(arg); } //! A numeric cast helper which handles the an signed source type. template <typename Target, typename Source> inline Target numeric_cast_helper( Source arg, signed_tag ) { // A loss of negative range, or more generally an underflow. if ( ( arg < 0 && !std::numeric_limits<Target>::is_signed ) || ( static_cast<typename promote_min_traits<Source, Target>::result>( arg ) < static_cast<typename promote_min_traits<Source, Target>::result>( std::numeric_limits<Target>::min() ) ) ) { throw numeric_cast_underflow(); } // A loss of positive range. if ( static_cast<typename promote_max_traits<Source, Target>::result>( arg ) > static_cast<typename promote_max_traits<Source, Target>::result>( std::numeric_limits<Target>::max() ) ) { throw numeric_cast_overflow(); } return static_cast<Target>(arg); } } // end of namespace internal //! A numeric cast which throws on overflow or underflow. template <typename Target, typename Source> inline Target numeric_cast( Source arg ) { typedef typename uiro::type::ct_if<std::numeric_limits<Source>::is_signed, typename internal::signed_tag, typename internal::unsigned_tag>::result tag; return internal::numeric_cast_helper<Target>( arg, tag() ); } } // end of namespace uiro

1 0

Re: Re: numeric_cast
by Dill, John 21 Apr '04

21 Apr '04

"Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404202049.i3KKnwe25029(a)lawrencewelk.systems.susq.com>... > From: "Dill, John" <john-dill(a)uiowa.edu> > > "Rob Stewart" <stewart(a)sig.com> wrote in message news:<200404201905.i3KJ55e08992(a)lawrencewelk.systems.susq.com>... > > > From: "Dill, John" <john-dill(a)uiowa.edu> > > > > > > > > I am wondering about the use-case of numeric_cast in this sample. > > > > > > > > unsigned char uchar_max = std::numeric_limits<unsigned char>::max(); > > > > char schar_value = 0; > > > > > > > > try { > > > > schar_value = boost::numeric_cast<char>( uchar_max ); > > > > } > > > > catch ( boost::bad_numeric_cast ) > > > > { std::cout << "Overflow occurred..." << std::endl; } > > > > > > > > When I execute this sample, I don't get the exception. What's > > > > the background on this behavior? I'm using gcc 3.3.1. > > > > > > Your char is unsigned. > > > > I'd like to know why conceptually the exception isn't thrown. > > As I said, in too few words, is that your "char" is unsigned, so > "char" and "unsigned char" are essentially the same type. > Technically, they are distinct types (for overloading purposes, > for example), but they are both unsigned and the same size, so: > > assert(std::numeric_limits<char>::max() > == std::numeric_limits<unsigned char>::max()); > > on your system. Actually that is not the case. The max defined for unsigned char is 255, while for char is 127. Actually, char is supposedly equivalent to signed char, not to unsigned char. > > Why is it beneficial to have unsigned T to signed T overflows > > not be detected? It is not just char, but short, int, and long > > as well. > > Now that's another story. Changing "unsigned char" to > "unsigned" and "char" to "int" should cause an exception. If > that's not happening, I don't understand since > std::numeric_limits<unsigned>::max() is greater than > std::numeric_limits<int>::max(). Actually, I think those type conversions shouldn't cause an exception. Converting char to int for example should be no problem since the range of char is within the range of int. Should be similar for unsigned char and unsigned. > > If this was the intended behavior, then what is the reasoning > > behind it? > > What you describe isn't the intended behavior other than the char > problem. I think it is a problem when you have an unsigned char, range 0 to 255, put into a char, range -128 to 127, when you are converting an unsigned char value of 255 (the numeric_limits::max()) into a [signed] char. It is an overflow problem, and it doesn't generate an exception. From what you seem to say, this should be a bug. Best, John

2 1