- Boost - lists.boost.org

Boost.Test: update 1
by Gennadiy Rozental 20 Dec '05

20 Dec '05

Hi everybody I finished the first update to the 1.33 release of Boost.Test. This update includes several bug fixes and series on new features. Once this updates settles for next update I will invest my efforts exclusively in documentation making it up to date and more convenient to use. The last update should finalize runtime parameter framework and testing by name feature. I don't think most of below modification require any (semi-)formal review, but I would really appreciate any comments and reviews for new features. Here is an itemized list of modifications/innovations included in update 1 (in no particular order): * Autolinking support is implemented To employ autolinking with Program Execution Monitor and Test Execution Monitor one need to include new headers test_exec_monitor.hpp and prg_exec_monitor.hpp * DLL support is implemented Now it's possible to build Boost.Test as DLL. In addition this allows to use Boost.Test from within dll. See separate post on this topic for more details. * Auto-registration test tree facilities integration Starting next release auto registration facilities becoming a natural part of primary Boost.Test interface. Header auto_unit_test is deprecated and unit_test.hpp is now includes everything. All examples for unit test framework are reworked to advertise these facilities as easiest way to facilitate testing. I will post a separate message giving a short introduction for all self-registration facilities including new ones: BOOST_FIXTURE_TEST_SUITE, BOOST_GLOBAL_FIXTURE. * Mix of auto registered and explicitly registered test cases allowed Now within the same test module one may have both auto registered and explicitly registered test cases. * Interaction based testing is introduced This branch of testing was not covered by Boost.Test before. See separate post with more detailed on the topic. * Exception safety testing is introduced Based on interaction based testing these facilities mostly useful for generic components testing. See separate post with more details on this topic. * Existing init API twicks In existing API init function for unit test usually look like this: test_suite* init_unit_test_suite( int argc, char* argv[] ) { test_suite* test = BOOST_TEST_SUITE( "abc" ); .... return test; } If this function returns NULL test tree treated as non initialized. With this update master test suite is now always exist and test tree treated as non initialized if it doesn't have any test cases. NULL is not treated as failure anymore. To report initialization failure with existent API one should use an exceptions (preferably std::logic_error). It's recommended for init function to look like this: test_suite init_unit_test_suite( int argc, char* argv[] ) { framework::master_test_suite().p_name.value = "abc"; .... return 0; } * Alternative init API introduced There several drawbacks in existent init API for unit test: - argc. argv soon there wouldn't be the only source for runtime parameters (config file, environment, and other source one would be able to use) - it's unsafe: if user doesn't allocate resulting test suite in heap coredump will occur - there is no way to indicate now initialization failure without exceptions. NULL results could mean that we failed to initialize or that we don't have any non-auto registered test cases I've introduced an alternative init API: bool init_unit_test(); Here false return value designate init failure. TO access runtime parameters one would use special (separate) API. To employ this alternative API one should define BOOST_TEST_ALTERNATIVE_INIT_API both during library and test compilation. This API is required for any user willing to use DLL build of the library. * framework::deregister_observer is introduced Now one could use temporary observers * observers priority is introduced Framework invokes a test observers callback in order of observer priority * unit_test_log API slightly simplified File and line of log entry passed as part of entry begin processing. * BOOST_MESSAGE and BOOST_CHECKPOINT are deprecated I found these names too generic for testing framework. New names are BOOST_TEST_MESSAGE and BOOST_TEST_CHECKPOINT. In addition I moved this faculties in their proper place: from Test Tools to Unit Test Log since they only responsible for logging. * BOOST_TEST_PASSPOINT() is introduced In addition to BOOST_TEST_CHECKPOINT which require a message to mark a check point this new facility mark a place test is passing through without any message (just file,line - being there). All Test Tools now invoke BOOST_TEST_PASSPOINT() before tool is started. This allows to detect the failure point in case if exception or crash more effectively (I would use the same name BOOST_TEST_CHECKPOIINT, but this would require variable num of args in macro) * BOOST_<level>_CLOSE_FRACTION This update introduce an ability to test on closeness based on either percentage driven tolerance or fraction driven one. This new tool will test on closeness based on fraction tolerance. (Note: The second request in the same domain: printing actual difference in fractions is not implemented. It's not clear what needs to be printed) * Test collector and Test reporter are modified to report proper number of test cases that gets aborted in cases of fatal failure * output_test_stream now allows matching in binary mode * framework::master_test_suite() interface is introduced for access to the test tree master test suite. * framework::test_unit_aborted() modified to include a test_unit that is being aborted Regards, Gennadiy

3 14

Re: [boost] [Review] Boost.Logging: formal review
by Richard Glanmark 20 Dec '05

20 Dec '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org] On Behalf Of Caleb Epstein > Sent: den 19 december 2005 16:41 > To: boost(a)lists.boost.org; Gennadiy Rozental; John Torjo > Subject: Re: [boost] [Review] Boost.Logging: formal review > > I personally prefer the all-enclosed macro style for this > reason as well as others. But I think one of Gennadiy's > points is that the primary interface to the Log should not be > defined in terms of macros. A standard set of macros can be > provided by the Boost.Log implementation for the sake of > convenience and casual use. But there should be a well > documented public interface that users with more complex > requirements can use to write their own logging macros, in > whichever style they prefer. Yes, this is a must. The "basic" interface should be quite minimalistic and simple to use. The interface should not have any domain specific nor "too much preferred logging styles". For instance, I don't think that Gennadiy's entry keywords belong directly in this interface. There would always be a domain or user that wants specific details to be added, details that might not be a concern at all in my application. However, an entry keyword should still be very simple to "implement/use" on top of the basic interface. > I don't think it makes sense to require a user to have > separate loggers to handle e.g. DEBUG, WARNING, and ERROR > levels. I also don't think it makes sense to require > separate logs for different logging keywords (I think thats > the term Gennadiy used). The user may use separate loggers > for each of these separate logical channels, but it should > not be a requirement. I'm not saying that this is required. I'm saying that it should be possible. I guess what I am saying is (like my paragraph above) style should be left to programmers and not be enforced. Especially, a logger must be able to have zero, one, or several, sinks (appenders) attached to it, and I think that that is something that you have addressed later in your post. > IMO it is very important for an administrator/programmer of a > system to > > be able to enable/disable logs, know what loggers and > appenders exists > > and be able to configure said entities. > > > But if the programmer has to provide a separate logger for > each logging level and conceptual channel of log information, > each of which is configured independently, isn't this > management problem far worse? I suppose it could be a management nightmare and if this is the case, one would need to have fewer loggers (or one if you like), in which case a logger is not tied to a specific log level (e.g.). And in this case, the programmer would use whater log functions deemed necessary to make the job simple(r). However, I'm not sure such functions should be part of the logger interface, but could be functions/macros that depend on the loggers and not vice versa in order to minimize the logger's interface. > If filter is only done on a per log statement, how do you > even know as a > > administrator of a system what log filters exists? Which filter > > criteria should be enabled and which filter criteria should > be disabled? > > > > Can you expound a bit on what you mean by this? Well, with a development team of 20+ people I might want to tightly control what is being logged and that all "important" log messages are sent to a specific sink. If entry keywords are used, for instance, I'm quite sure that the number of keywords in use probably would explode. Which of these are important and which are not so important? Which are warnings, which messages should be filtered and so on. Perhaps I want to enable all log messages with a the specific entry keyword "my_special_condition", but what happens when a programer misspelled this keyword. This could also turn into a management nightmare IMO (unless I'm totally misunderstanding the concept). If a systems architect would like to send specific log message to specific sinks, wouldn't this be a management problem as well? I would still have to setup and configure loggers/filter/sink combinations. I'm not sure there is a "better" solution to this general problem. It's a difficult problem and should be treated as such. IMO, there must be several ways to solve the issue, chosen by programmers and teams that suits their specific "design" choice. This boils down to, IMO, to simplistic loggers and sinks, and a more "complex" extensible layer on top of this, perhaps provided by the library for common situations.. > I see the central concepts as: > > Entry (or Message): the set of information that makes up a > single message to log. Might include a "level" (e.g. debug, > info, warning, error), a "category" (e.g. arguments, > program_flow, etc), a "keyword" (e.g. "Network", "UI", "Disk > Cache", etc) and of course a text string. Could be more or it could be less in specific situations. But other than that I agree with you. > Filter: determines whether or not an Entry should be logged. > Probably implemented as a relatively simple functor. > Sink: ultimate destination for Entries. Implementations for > wirting to files, system log facilities, etc can be provided. > Log: provides logging methods. Implements the Filter concept > and contains zero or more Sinks which are the targets of > Entries for which the Filter returns true. I aggree with you on a conceptual level. However, the Filter concept shouldn't be part of, IMO, the logger. Or if it is, at least, there should be an alternative interface in the logger, or possibly, the filtering concept should be very simple if I don't want entry keywords and such. Fundementally, I think that writing log statements and filtering log statements are two different and orthogonal concepts. Filtering is an efficiency decision at the conceptual level. With that I mean if we had infinite computing power (which we don't) filtering wouldn't be necessary at all when sending log entries to sinks. Filtering is however something the target audience does when looking for, or at, log statements. That is, with infinite computing power, the filtering mechanism could be done at the time when administrators/programmers are looking/searching logs. But since we don't have infinite computing power, log entries need to be filter before sending them to sinks (I suppose one could argue that there are other reasons for filtering before sending entries to sinks; but I don't see a difference). So the interface for enabling/disabling log entries should be a fundemental concept to a logging library and obviously as well designed as the actual log entry interface. Especially, wether to send a log entry to a sink should incur minimal overhead, or else risk efficiency even if the log statement are not sent to the sinks. This is especially true if programers use many log statements. IMO at the most fundemental layer, a logger is either enabled or disabled. If it is enabled, log entries are sent to its attached sinks. Filtering should be implemented on top of loggers. The filtering concept determines wether to send the log entry to the logger or not. > I've been sketching up a very simple implementation of some > of these ideas in my spare time. Is there interest in > fleshing these ideas out more fully on or off-list? Cool! Yes, very interested (I have myself an implementation... who doesn't ;-)) /Richard The content of this e-mail is intended only for the confidential use of the person(s) to whom it is addressed. If the reader of this message is not such a person, you are hereby notified that you have received this communication in error and that reading it, copying it, or in any way disseminating its content to any other person, is strictly prohibited. If you have received this message in error, please notify the author by replying to the e-mail immediately. NeoNet AB and its subsidiaries (NeoNet Securities AB, NeoNet Securities Inc. and NeoNet Technology AB) are unable to exercise control over the content of information contained in transmissions made via the Internet and hereby excludes any warranty as to the quality or accuracy of any information contained in this message and any liability of any kind for the information contained in it, or for its transmission, reception, storage or use in any way whatsoever.

4 3

[asio] + [test] problem with asio used together with boost.test program exec monitor
by Andreas Willich 20 Dec '05

20 Dec '05

Hi Boost- Devs I noticed a problem with the use of asio together with the test program exec monitor. If you include the prg_exec_monitor.hpp before the asio.hpp the boost.test lib includes winsock.h. In the next step asio includes the winsock2.h. The result is that there are many redefinition errors like these: d:\librarys\boost\include\boost-1_33\boost\asio\detail\socket_types.hpp(41) : warning C4005: 'FD_SETSIZE' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(51) : see previous definition of 'FD_SETSIZE' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(112) : error C2011: 'fd_set' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(54) : see declaration of 'fd_set' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(147) : warning C4005: 'FD_SET' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(88) : see previous definition of 'FD_SET' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(156) : error C2011: 'timeval' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(97) : see declaration of 'timeval' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(212) : error C2011: 'hostent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(153) : see declaration of 'hostent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(225) : error C2011: 'netent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(166) : see declaration of 'netent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(232) : error C2011: 'servent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(173) : see declaration of 'servent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(244) : error C2011: 'protoent' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(185) : see declaration of 'protoent' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(400) : error C2011: 'sockaddr_in' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(321) : see declaration of 'sockaddr_in' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(410) : error C2011: 'WSAData' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(331) : see declaration of 'WSAData' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(470) : warning C4005: 'SO_DONTLINGER' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(411) : see previous definition of 'SO_DONTLINGER' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(527) : warning C4005: 'AF_IPX' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(469) : see previous definition of 'AF_IPX' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(555) : warning C4005: 'AF_MAX' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(488) : see previous definition of 'AF_MAX' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(561) : error C2011: 'sockaddr' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(494) : see declaration of 'sockaddr' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(601) : error C2011: 'sockproto' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(503) : see declaration of 'sockproto' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(640) : error C2011: 'linger' : 'struct' type redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(540) : see declaration of 'linger' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(653) : warning C4005: 'SOMAXCONN' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(553) : see previous definition of 'SOMAXCONN' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(679) : warning C4005: 'FD_READ' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(571) : see previous definition of 'FD_READ' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(682) : warning C4005: 'FD_WRITE' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(572) : see previous definition of 'FD_WRITE' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(685) : warning C4005: 'FD_OOB' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(573) : see previous definition of 'FD_OOB' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(688) : warning C4005: 'FD_ACCEPT' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(574) : see previous definition of 'FD_ACCEPT' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(691) : warning C4005: 'FD_CONNECT' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(575) : see previous definition of 'FD_CONNECT' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(694) : warning C4005: 'FD_CLOSE' : macro redefinition d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(576) : see previous definition of 'FD_CLOSE' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1626) : error C2375: 'accept' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(744) : see declaration of 'accept' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1647) : error C2375: 'bind' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(749) : see declaration of 'bind' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1666) : error C2375: 'closesocket' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(754) : see declaration of 'closesocket' d:\microsoft visual studio 8\vc\platformsdk\include\winsock2.h(1685) : error C2375: 'connect' : redefinition; different linkage d:\microsoft visual studio 8\vc\platformsdk\include\winsock.h(756) : see declaration of 'connect' ... Perhaps someone can add a notice about this situation to the docs. Andreas

3 4

typeof tests hanging tru64cxx71-006
by Arkadiy Vertleyb 20 Dec '05

20 Dec '05

Rene Rivera wrote: > Markus Schöpflin wrote: > > Hello, > > > > is it possible to disable specific tests for certain compiler/platform > > combinations? > > Yes. Add a <build>no to the requirements of the test. > > > I have the problem that currently the typeof tests are hanging CXX 6.5 on > > Tru64, the compiler just compiles forever. > > For the HP TestDrive toolset it would be "<tru64cxx71-006><*><build>no". > If you need to do some more complicated matching logic to determine when > to add the no-build option you'll need to use a requirement rule. See > the serialization test Jamfiles for an example. Sorry for the late response. Is this still a problem? Should I disable the typeof tests for this tool? Regards, Arkadiy

2 3

[QNX6] [1.33.1] Provisional "unofficial branch site" up for approval
by Jim Douglas 20 Dec '05

20 Dec '05

My website for QNX6 programmers wishing to use Boost is now up for approval at: http://www.dramatec.co.uk/boost-qnx6/ Comments, criticisms (constructive), corrections or congratulations ;-) are welcome. Jim Douglas

3 4

updating the references page?
by Esther Schindler 20 Dec '05

20 Dec '05

Informit has several articles related to Boost, many of which are much newer than listed on the boost reference page. To whom should I send a list? Esther Schindler editor, Informit.com (among other things)

2 1

Rational comparison w/ continued fractions
by Daryle Walker 20 Dec '05

20 Dec '05

I interrupted some thread about how Wave processed numbers it read. I mentioned using bignums someday. The thread drifted to bignum representations, including "exact reals." One of the exact-real library web sites mentioned continued fractions, which lead me to the HAKMEM paper. You can find out more at <http://en.wikipedia.org/wiki/HACKMEM>. I was thinking of creating a continued fraction class for us, but then I saw a note about how continued fraction comparison is easier than regular fraction comparison. More importantly, c.f. comparison is just list entry checking, no arithmetic operations. Conversion from r.f. to c.f. involves only division and remainders. These facts combine to make a r.f. comparison that doesn't need multiplications, and therefore avoids overflow. Continued fractions have a form like: p0 + q0 / (p1 + q1 / (p2 + q2 / ... )) where all the p's and q's are integers. We usually simplify the representation by factoring out all the q's to 1's: r0 + 1 / (r1 + 1 / (r2 + 1 / ... )) (The p's change values, except for p0, because of the re-factoring.) We can type out these simplified fractions easily with "[r0; r1, r2, ...]". Rational and irrational numbers map to finite- and infinite-length fraction lists, respectively. Irrational numbers have a unique representation; rational numbers are unique to two forms, where the minor form reduces the last number by 1 and appends a 1 to the list. [x0; x1, x2, ..., xn] == [x0; x1, x2, ..., (xn - 1), 1] Continued fractions are typically difficult to manipulate, but two operations are very easy. 1. Reciprocal [0; x1, x2, x3, ...] <-> [x1; x2, x3, ...] 2. Comparison of two values (as represented by their lists) a. Make sure to normalize the fraction 1. Convert away from the trailing-1 minor form (if rational) 2. Remove any interior zeros with [... x, 0, y, ...] <-> [... (x + y) ...] But note that if x == -y, you'll create another zero and you'll have to do another round. 3. Keep the sign consistent, make sure every integer in the series is non-negative or non-positive. (Keeping the previous rule in mind, only the first list entry can be a zero.) I don't know how to correct lists that violate this. I don't think that normal conversion from a numerator & denominator pair will cause these problems; a conversion will create a list that's already normalized. The conversion involves applying Euclid's GCD algorithm, which needs the "%" operator, which is iffy for negative values, so it would be better to take the absolute values, track the signs separately, and flip the result as appropriate. (Lists with these problems could occur if the list is generated from a rule formula.) b. (I'm assuming that you're using absolute values.) If every element of the two numbers' lists are equal, then the numbers are equal. Otherwise stop at the pair of list entries that are different, using infinity as the place-holder if one list is shorter than another. For that list index K, if K mod 2 is the same as the index for the first (i.e. the whole number part) entry's mod-2, then the less/greater-than status of the two entries is the same as the lists' status, else the statuses are reversed. Example 1: 7/6 (i.e. 1+1/6) vs. 1/2 7/6: [1; 6] 1/2: [0; 2] Difference at first entry 1 > 0 with odd# entry; so 7/6 > 1/2 Example 2: 1/4 vs. 1/3 1/4: [0; 4] 1/3: [0; 3] Difference at second entry 4 > 3 with even# entry; so 1/4 < 1/3 Example 3: 47/21: [2; 4, 5] 9/4: [2; 4] Difference at third entry 5 < Inf with odd# entry; so 47/21 < 9/4 Normal decimal fractions have even faster comparisons, but forming enough digits is harder, especially if they repeat. I'll try to come up with an actual improved member function for boost::rational in few days. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

3 5

[test] como doesn't like #warning
by Eric Niebler 20 Dec '05

20 Dec '05

This from the regression results for como- 4_3_3- vc7_1: "G:\boost\boost/test/impl/execution_monitor.ipp", line 60: warning #11-D: unrecognized preprocessing directive # warning Debugger check disabled. Either define _WIN32_WINNT or include Boost.Test header in front of winbase.h ^ -- Eric Niebler Boost Consulting www.boost-consulting.com

6 14

Re: [boost] [filesystem] problem with filename length (bug?)
by Allmen, Michael-P57512 20 Dec '05

20 Dec '05

Sorry, forgot that information. Solaris 9 Boost 1.33 -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Thursday, December 15, 2005 7:45 PM To: boost(a)lists.boost.org Subject: Re: [boost] [filesystem] problem with filename length (bug?) "Allmen, Michael-P57512" <Michael.Allmen(a)gdc4s.com> wrote in message news:C7FCC5C93630AB4E80049ED163FFD224B5ED0B@AZ25EXM04.gddsi.com... > Here is the code I am using (the problem also occurs with the > simple_ls.cpp sample)... > > #include <iostream> > #include "boost/filesystem/operations.hpp" > #include "boost/filesystem/path.hpp" > > namespace fs = boost::filesystem; > > int main( int argc, char* argv[] ) > { > fs::path dir( "somedir" ); > > fs::directory_iterator end; > for( fs::directory_iterator i( dir ); i != end; ++i ) { > std::cout << dir->leaf() << std::endl; } > > return 0; > } > > The problem is that once the program finds a file at least 22 > characters long, it will not print any filenames longer than first file correctly. What operating system are you using? What version of Boost? Thanks, --Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[bug] Visual Studio 2003 versus polymorphic_downcast
by Mat Marcus 20 Dec '05

20 Dec '05

Visual studio 2003 seems to be buggy in a way that can break boost::polymorphic_downcast. Unless I am missing something, it's a rather scary silent failure: ### # include <cassert> class left {}; class right {}; class derived : public left, public right {}; int _tmain(int argc, _TCHAR* argv[]) { derived x; const derived *xp=&x; right *yp=&x; // assert(const_cast<derived*>(xp)==yp); no bug assert(xp==yp); //bug: this fires return 0; } ### This bug causes the assert in polymorphic_downcast to fire when it shouldn't. Here is one possible patched version: template <class Target, class Source> inline Target polymorphic_downcast(Source* x BOOST_EXPLICIT_DEFAULT_TARGET) { #if BOOST_WORKAROUND(BOOST_MSVC, <= 1310) assert( static_cast<const Source*>(dynamic_cast<Target>(x)) == x ); // detect logic error #else assert( dynamic_cast<Target>(x) == x ); // detect logic error #endif return static_cast<Target>(x); } ### The problem is not present in VS 2005. Thoughts? Mat

1 0