- Boost - lists.boost.org

[Boost-bugs] [ boost-Bugs-917070 ] Bug in lexical_cast.hpp
by SourceForge.net 16 Mar '04

16 Mar '04

Bugs item #917070, was opened at 2004-03-15 21:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=917070&group_i… Category: lexical_cast Group: None Status: Open Resolution: None Priority: 5 Submitted By: John F Meinel Jr (jfmeinel) Assigned to: Kevlin Henney (kevlin) Summary: Bug in lexical_cast.hpp Initial Comment: In boost-1_31_0, I believe there is a typo in lexical_cast.hpp The line Target lexical_cast(Source arg) should be Target lexical_cast(Source& arg) Otherwise it actually creates a copy of the argument before doing the lexical cast. This causes problems if you try to lexical_cast() a virtual object. Here is code that shows the bug. By just adding the '&', the code performs as you would expect it to. #include <iostream> #include <string> #include <boost/lexical_cast.hpp> struct A { virtual int f() const = 0; }; struct B : A { virtual int f() const { return 1; } }; struct C : B { virtual int f() const { return 2; } }; std::ostream& operator<<(std::ostream& os, const A& a) { return os << a.f(); } int main() { C c; std::string s; std::cout << c << std::endl; //This should print 2 s = boost::lexical_cast<std::string>(c); std::cout << s << std::endl; //This should print 2 s = boost::lexical_cast<std::string, B>(c); std::cout << s << std::endl; //This returns 1, not 2 //This fails because it tries to instantiate an object of type A. Why??? s = boost::lexical_cast<std::string, A>(c); std::cout << s << std::endl; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=917070&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

Proposal for a <stdfwd> header
by Javier Estrada 15 Mar '04

15 Mar '04

A couple of weeks ago I posted in c++ moderated: It seems natural that if there is a <iosfwd> to forward declare the I/O related classes, there should be a header for the classes contained in the std namespace. In the trenches, often times I come across classes that can be simply defined in terms of references and pointers to other classes. An example is defining interfaces or "protocol classes." Granted, with a small project, using an <stdfwd> header does not provide a big advantage, but I deal with 500+ files in a framework... I believe that the rationale is so simple that I even feel lazy about explaining the benefits, but oh well: // needlessly including the definition of string (or basic_string) and vector #include <string> #include <vector> class ISeek{ public: virtual void seek_knowledge(const std::string& token) = 0; virtual void seek_advice(const std::vector<std::string>& advisers) = 0; }; // using the proposed header... #include <stdfwd> class ISeek{ public: virtual void seek_knowledge(const std::string& token) = 0; virtual void seek_advice(const std::vector<std::string>& advisers) = 0; }; Please ready your darts and fire at will. I'd like to know if there is enough support that it could fly in a proposal to the std committee. Javier jestrada at developeer dot com

3 4

RE: [boost] Re: Explicit instantiation of boost::shared_ptr<SomeClasss>
by Greg Clayton 15 Mar '04

15 Mar '04

> -----Original Message----- > From: David Abrahams [mailto:dave@boost-consulting.com] > Sent: Friday, March 12, 2004 1:19 PM > To: boost(a)lists.boost.org > Subject: [boost] Re: Explicit instantiation of > boost::shared_ptr<SomeClasss> > > > "Greg Clayton" <Greg.Clayton(a)palmsource.com> writes: > > >> Greg Clayton wrote: > >> > I am trying to do explicitly instantiate specific > shared_ptr class > >> > for export from a Win32 DLL (currently with MSVC6, and eventually > > in > >> > VS2003). > >> > >> First things first. Why do you need to do that? Have you > >> tried not exporting it, have you encountered any problems? > > > > Yes, shared pointers can't be created and handed off from DLL to DLL > > the way they are currently implemented. > > I don't understand why people keep making this claim. As long as you > don't unload DLL B, you're golden. The only other alternative > prohibits unloading DLL A. I don't think that dynamically generating > a fake DLL to hold the destructors would be appropriate, so IMO > shared_ptr is as well-behaved as it can be wrt DLLs. In my case I have a main DLL that is the brains of the entire app (the model is removed from the view and controller). I also have many other DLLs that are all dynamically loaded, and that can be unloaded at any time when they are no longer needed. These extra DLLs can "register" information with this main DLL, and then go away (sometimes this info is classes that are passed across DLL boundaries using shared pointers). These extra DLLs can also ask for information from the main DLL as well. The main DLL in my case never gets unloaded until the end (actually all other DLLs link to this main DLL), but all other DLLs can be unloaded. The main issue is the virtual function table, since when you pass off ownership of the shared pointer to another DLL, the code for that vtable lives within the contributing DLL, unless you explicitly instantiate it. I have no problem with the way shared_ptr's are currently implemented, I simply want to get them working with my program, and understand what I need to watch out and plan for. > > If DLL A has an STL container of shared pointers, and DLL B gets > > _dynamically_ loaded and adds an item to DLL A's container (creates > > a shared pointer to an object, and DLL B adds that shared pointer > > through an interface it to DLL A's STL container of shared > > pointers), DLL B can not be unloaded. If DLL B does get unloaded you > > will crash when your STL container goes out of scope (when it tries > > to delete the owned pointer). The virtual function table for the > > shared pointer lives in the DLL that creates it if you just use > > something like: > > > > typedef boost::shared_ptr<SomeClass> SomeClassSP; > > > > in a header file that comes from DLL A (for other DLLs to > link to). So > > I need to instantiate and export everything for that shared pointer > > from DLL A (since it is the DLL that owns the STL containers of > > objects) so that the vtable stays valid for the lifetime of > the shared > > pointer object. > > Solution: pass the objects from B to A via std::auto_ptr. That is a great idea, I will try this. > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > >

1 0

Re: mpl rational_c and fixed_c
by Aleksey Gurtovoy 15 Mar '04

15 Mar '04

Matt Calabrese wrote: > Okay, I decided before I continue with my other library, I'll fully > implement rational_c properly (and possibly fixed_c), however, doing > so without making the code horribly complex would require changes to > the current definitions of pretty much all of the operations (plus, > multiplies, etc. as well as the conditional operators). ^^^^^^^^^^^ I suppose you meant "comparison", here and below. > > The problem is that those current functions take 5 parameters, making > specialization nearly impossible for the rational and fixed templates > as you'd have to account for when the 3rd, 4th, 5th, etc parameters > are not passed (and so the default integral 0 is used). That can't be > easily done (at least I don't see how) without having to specialize > each condition separately (one for 3 rational types, one for 4 > rational types, etc ). Moreso, this applies to the conditional > operators as well, there is no easy way to account for using different > types in multiplies IE multiplying a rational and integral together, > or a fixed and rational, etc. Again, to account for these > possibilities you'd have to make an incredibly large amount of > specializations. Of course, you could always just limit them to only > work when all the parameters are the same kind of compile-time value > template, but that would be somewhat limitting,especially with other > solutions available. I pretty much agree with the analysis. > > What I propose is a way around this situation, but still have the > metafunctions declared the same way, therefore not breaking old code > and not limiting functionality. To do so, the following adjustments > would have to be made (and I have already begun to make them for my > own use): > > 1) Additional versions of all of the arithmetic operators which take 2 > parameters, each need to be defined and work like binary operators. > They should be specialized for when both the left and right operands > are of the same type. How to account for when they are different types > will be covered in the future points. Sounds good so far. > 2) A value_cast metafunction which can cast between all different > compile-time constant types. The way it is implemented is by requiring > all types to have specialized metafunctions for converting to and from > the fixed point type. When value_cast is used, it, by default, > converts the right hand operand to fixed_c, then converts that fixed_c > to the target type. Since a fixed_c can hold pretty much any real > value to a certain precision, you can be certain, to an extent, that > little, if any precision will be lost through conversion. So, with > that proposed addition, you'd be able to convert between all different > types and only require people developing new types to have to > specialize conversion to and from fixed_c. The only problem is that in > order for the value_cast to exist, it obviously needs to have a > parameter which specifies a type to convert to. The only way I can > currently see that would allow that would be to have the value_cast > take a type parameter which would be a template instantiation with a > dummy value, which would, in a way, be very similar to rebinding > allocators. The idea of avoiding a combinatorial explosion through a single user-defined conversion metafunction which will be used to even the argument types is definitely solid; however, I am afraid we cannot escape with something as simplistic as conversion to a default predefined "contains-it-all" numeric type -- simply because there is no such type (for instance, 'fixed_c' is not capable of holding compile-time complex numbers, and so on). Moreover, specializing of arithmetic metafunctions is not necessary a prerogative of numeric types -- consider, for example, random-access iterators. To summarize, IMO the idea is excellent, but it needs to be carried a little bit further -- please see below. > 3) The conditional operations and 2 operand arithmetic operations > should be redefined in the base template definition to convert both > types to fixed_c and then make a comaprison, therefore allowing > programmers to use the operations on two different types of > compile-time constants without having to manually convert them to > similar types before-hand (as I alluded in first point). The > conditional operations can then be specialized for when the types > are the same on each side to avoid the cost of a cast on each of the > operands to fixed_c. Yep to everything except the 'fixed_c' part. > 4) The current "varying length" operations which cause problems > (multiplies, plus, minus, etc) should be redefined to just call the 2 > operand version of the corresponding operation on each of the > parameters passed to the operation. This way, programmers can still > pass multiple parameters to these functions, with each parameter being > a different type, without the developer having to make an extremely > large amount of specializations for each type (including those which > have yet to be developed). Yep! Something like template< typename N1 , typename N2 , typename N3 = int_<0> , typename N4 = int_<0> , typename N5 = int_<0> > struct plus : plus2< plus2< plus2< plus2<N1,N2>,N3 >,N4 >,N5 > { }; // ... template< typename N1 , typename N2 > struct plus<N1,N2,int_<0>,int_<0>,int_<0> > : plus2<N1,N2> { }; > > I have already begun implementing all of the points I have suggested, > though with my rational_c as a the basis for conversion rather than > fixed_c (as I haven't yet developed fixed_c). Also, converting to and > from rational_c is considerably simpler than converting to and from > fixed_c. For this reason, I may end up leaving the basis for > conversion as rational_c instead of fixed_c. > > If anyone sees any other, more elegant solutions for the problems I > mentioned, please post them and I may change my approach. Additional > suggestions are also greatly appreciated. You are going in the right direction. Here are some suggestions of how to generalize the scheme to get what I would consider an ideal solution: 1) Make specializable binary templates for each arithmetic/comparison metafunctions to be tag-dispatched metafunction classes, e.g. template< typename N1 , typename N2 > struct plus2 : plus_impl< // 'plus_impl' is a point of customization typename plus_tag<N1>::type , typename plus_tag<N2>::type >::template apply<N1,N2>::type { }; // 'plus_impl' implemenation for plain integral constants template<> struct plus_impl<integral_c_tag,integral_c_tag> { template< typename N1, typename N2 > struct apply : integral_c< BOOST_MPL_AUX_TYPEOF(N1,N1::value + N2::value) , (N1::value + N2::value) > { }; }; where 'plus_tag' is something as simple as template< typename T > struct plus_tag { typedef typename T::tag type; }; 2) Provide a rank mechanism so that we know in which direction to cast in case of mixed operations; can be as simple as an integral-constant 'rank' member of the corresponding tag: plus_tag< int_<5> >::type::rank == 0 3) Provide default implementations of '*_impl' binary templates which would use ranks, tags, and 'numeric_cast' to implement a general scheme for mixed arithmetics/comparison, something along these lines: template< bool c_ , typename Tag1 , typename Tag2 > struct plus_impl_ { template< typename N1, typename N2 > struct apply : plus_impl<Tag2,Tag2>::template apply< typename apply< numeric_cast<Tag2,Tag1>, N2>::type , N2 > { }; }; template< typename Tag1 , typename Tag2 > struct plus_impl_<false,Tag1,Tag2> { template< typename N1, typename N2 > struct apply : plus_impl<Tag1,Tag1>::template apply< N1 , typename apply< numeric_cast<Tag1,Tag2>, N2>::type > { }; }; template< typename Tag1 , typename Tag2 > struct plus_impl : plus_impl_< ( Tag1::rank < Tag2::rank ),Tag1,Tag2 > { }; Does it make any sense to you? P.S. I suggest we move the discussion to the developers list (I'm going to cross-post this one). -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[circular buffer review]
by Thorsten Ottosen 14 Mar '04

14 Mar '04

Hi All, here is my review of the circular buffer class. What is your evaluation of the design? --------------------------------------- The design is good. People can easily learn to use it. There are some miner things that I would like see changed, like double versions of push_back and push_front. I don't understand why both set_capacit and resize are provided and I would like to see them merged if possible. I also think push_back should throw an exception if no element is inserted. This behavior is somewhat different push_back() from a normal std container. If there are similar cases then I think they should be looked at again too. What is your evaluation of the implementation? ----------------------------------------------- I haven't looked closely at the source code. What is your evaluation of the documentation? ---------------------------------------------- very good once the exception-safety issues are solved What is your evaluation of the potential usefulness of the library? ---------------------------------------------------------------- I'm in doubt. The library has efficiency as its hallmark. The rationale says that it gives efficient FIFO queue. So I tried to compare it with std::deque, and here is my results of an /O2 build with vc71: $ ./cbuffer_vs_deque.exe circular_buffer<int>: 2.15 s deque<int>: 2.84 s circular_buffer<string>: 20.59 s deque<string>: 18.64 s The test program is attached; I might have made an error, but if I have not, then I don't see the claim as true. In that case I need to see some more evidence about why the speed advantages should be so good. It also make me wonder if there is any need for circular_buffer_space_optimized. Did you try to use the library? With what compiler? Did you have any problems? ---------------------------------------------------------------------------- ------ yes, with vc7.1; Comeau 4.3.0 could not compile it. It worked fine on vc7.1 How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ---------------------------------------------------------------------------- ------------------- A couple of hours with both documentation and code use. Are you knowledgeable about the problem domain? ----------------------------------------------------- I don't have experience with embedded applications; I have written stuff in which performace was critical and in which specially designed datastructures was necessary. Do you think the library should be accepted as a Boost library? --------------------------------------------------------------- Yes if the author can convince me that we really get more performance. No otherwise. best regards Thorsten begin 666 cbuffer_vs_deque.cpp M(V1E9FEN92!"3T]35%]$25-!0DQ%7T-"7T1%0E5'(#$-"@T*(VEN8VQU9&4@ M(F)O;W-T+V-I<F-U;&%R7V)U9F9E<BYH<' B#0HC:6YC;'5D92 \8F]O<W0O M<')O9W)E<W,N:'!P/@T*(VEN8VQU9&4@/&)O;W-T+W1H<F5A9"]T:')E860N M:'!P/@T*(VEN8VQU9&4@/&1E<75E/@T*(VEN8VQU9&4@/'-T<FEN9SX-"B-I M;F-L=61E(#QI;W-T<F5A;3X-"@T*=7-I;F<@;F%M97-P86-E(&)O;W-T.PT* M=7-I;F<@;F%M97-P86-E('-T9#L-"@T*;75T97@@<75E=65?;75T97@[#0IC M;VYS="!I;G0@<75E=65?<VEZ92 @(" @/2 U,# [#0IC;VYS="!I;G0@=&]T M86Q?96QE;65N=',@/2!Q=65U95]S:7IE("H@,3 P,# P.PT*#0IT96UP;&%T M93P@='EP96YA;64@475E=64@/@T*:6YL:6YE(&)O;VP@:7-?9G5L;"@@8V]N M<W0@475E=64F(&,@*0T*>PT*(" @(')E='5R;B!C+G-I>F4H*2 ]/2!Q=65U M95]S:7IE.PT*?0T*#0IT96UP;&%T93P@='EP96YA;64@475E=64@/@T*8VQA M<W,@<F5A9&5R#0I[#0H@(" @='EP961E9B!T>7!E;F%M92!1=65U93HZ=F%L M=65?='EP92!4.PT*(" @(%%U975E)B @<3L-"B @(" -"G!U8FQI8SH-"B @ M("!R96%D97(H(%%U975E)B!Q("D@.B!Q*'$I('L@?0T*(" @( T*(" @('9O M:60@;W!E<F%T;W(H*2@I#0H@(" @>PT*(" @(" @("!I;G0@<F5A9%]E;&5M M96YT<R ](# [#0H@(" @(" @( T*(" @(" @("!W:&EL92@@<F5A9%]E;&5M M96YT<R \('1O=&%L7V5L96UE;G1S("D@(" -"B @(" @(" @>PT*(" @(" @ M(" @(" @:68H("%Q+F5M<'1Y*"D@*2 @( T*(" @(" @(" @(" @>PT*(" @ M(" @(" @(" @(" @('L-"B @(" @(" @(" @(" @(" @(" @;75T97@Z.G-C M;W!E9%]L;V-K(&QO8VLH(&UU=&5X("D[#0H@(" @(" @(" @(" @(" @(" @ M(%0@=" ]('$N8F%C:R@I.PT*(" @(" @(" @(" @(" @(" @("!Q+G!O<%]B M86-K*"D[#0H@(" @(" @(" @(" @(" @?0T*(" @(" @(" @(" @(" @("LK M<F5A9%]E;&5M96YT<SL-"B @(" @(" @(" @('T-"B @(" @(" @(" @(&5L M<V4-"B @(" @(" @(" @(" @("!R96%D7W1H<F5A9"@I+3YY:65L9"@I.PT* M(" @(" @("!]#0H@(" @?0T*(" @( T*(" @('-T871I8R!T:')E860J)B!R M96%D7W1H<F5A9"@I#0H@(" @>PT*(" @(" @("!S=&%T:6,@=&AR96%D*B!T M(#T@,#L-"B @(" @(" @<F5T=7)N('0[#0H@(" @?0T*?3L-"@T*=&5M<&QA M=&4\('1Y<&5N86UE(%%U975E(#X-"F-L87-S('=R:71E<@T*>PT*(" @('1Y M<&5D968@='EP96YA;64(a)475E=64Z.G9A;'5E7W1Y<&4@5#L-"B @("!1=65U M928@('$[#0H@(" @#0IP=6)L:6,Z#0H@(" @=W)I=&5R*"!1=65U928@<2 I M(#H@<2AQ*2![('T-"B @(" -"B @("!V;VED(&]P97)A=&]R*"DH*0T*(" @ M('L-"B @(" @(" @:6YT('=R:71T96Y?96QE;65N=',@/2 P.PT*(" @(" @ M("!W:&EL92@@=W)I='1E;E]E;&5M96YT<R \('1O=&%L7V5L96UE;G1S("D- M"B @(" @(" @>PT*(" @(" @(" @(" @:68H("%I<U]F=6QL*"!Q("D@*0T* M(" @(" @(" @(" @>PT*(" @(" @(" @(" @(" @('L-"B @(" @(" @(" @ M(" @(" @(" @;75T97@Z.G-C;W!E9%]L;V-K(&QO8VLH(&UU=&5X("D[#0H@ M(" @(" @(" @(" @(" @(" @('$N<'5S:%]B86-K*"!4*"D@*3L-"B @(" @ M(" @(" @(" @("!]#0H@(" @(" @(" @(" @(" @*RMW<FET=&5N7V5L96UE M;G1S.PT*(" @(" @(" @(" @?0T*(" @(" @(" @(" @96QS92 @(" -"B @ M(" @(" @(" @(" @("!W<FET95]T:')E860H*2T^>6EE;&0H*3L-"B @(" @ M(" @?0T*(" @('T-"B @(" @(" @#0H@(" @<W1A=&EC('1H<F5A9"HF('=R M:71E7W1H<F5A9"@I#0H@(" @>PT*(" @(" @("!S=&%T:6,@=&AR96%D*B!T M(#T@,#L-"B @(" @(" @<F5T=7)N('0[#0H@(" @?0T*?3L-"@T*#0IT96UP M;&%T93P@='EP96YA;64@475E=64@/@T*=F]I9"!F:69O7W1E<W0H*0T*>PT* M(" @('!R;V=R97-S7W1I;65R('0[#0H@(" @475E=64@('$H('%U975E7W-I M>F4@*3L-"B @("!R96%D97(\475E=64^(')E861E<B@@<2 I.PT*(" @('=R M:71E<CQ1=65U93X@=W)I=&5R*"!Q("D[(" @( T*(" @('1H<F5A9"!R96%D M*"!R96%D97(@*3L-"B @("!T:')E860@=W)I=&4H('=R:71E<B I.PT*(" @ M(')E861E<BYR96%D7W1H<F5A9"@I(#T@)G)E860[#0H@(" @=W)I=&5R+G=R M:71E7W1H<F5A9"@I(#T@)G=R:71E.PT*(" @(" @(" -"B @("!R96%D+FIO M:6XH*3L-"B @("!W<FET92YJ;VEN*"D[(" @(" @(" @(" -"@T*?0T*#0II M;G0@;6%I;B@I#0I[#0H@(" @8V]U=" \/" B7&X@8VER8W5L87)?8G5F9F5R M/&EN=#XZ("([#0H@(" @9FEF;U]T97-T/"!C:7)C=6QA<E]B=69F97(\:6YT M/B ^*"D[#0H@(" @#0H@(" @8V]U=" \/" B7&X@9&5Q=64\:6YT/CH@(CL- M"B @("!F:69O7W1E<W0\(&1E<75E/&EN=#X@/B@I.PT*#0H@(" @8V]U=" \ M/" B7&X@8VER8W5L87)?8G5F9F5R/'-T<FEN9SXZ("([#0H@(" @9FEF;U]T M97-T/"!C:7)C=6QA<E]B=69F97(\<W1R:6YG/B ^*"D[#0H@(" @#0H@(" @ M8V]U=" \/" B7&X@9&5Q=64\<W1R:6YG/CH@(CL-"B @("!F:69O7W1E<W0\ K(&1E<75E/'-T<FEN9SX@/B@I.PT*#0H@(" @<F5T=7)N(# [#0I]#0H-"@`` ` end

4 9

Sandbox CVS warning
by Gennaro Prota 14 Mar '04

14 Mar '04

I keep getting the following warning when committing files to the sandbox CVS: warning: cannot write to history file /cvsroot/CVSROOT/history: Permission denied Is all ok or should I be worried? Thanks in advance, Genny.

1 0

Implicitly-Callable Functions in C++0x?
by Beman Dawes 14 Mar '04

14 Mar '04

There's a proposal (N1611) "Implicitly-Callable Functions in C++0x" by Walter Brown in the C++ committee's pre-meeting papers. See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf Given all the Boost work that has gone into math constants, function issues, and to a lesser extent, properties, I'd guess several Boosters might want to comment on Walter's proposal. Strong support from library developers like Boost participants would almost be a requirement for such a proposal to be accepted, IMO. But do remember that only so many proposals can be accepted, and that every proposal that gets accepted pushes some other proposal aside. comp.std.c++ is the best place to post comments, since it is probably read by more of the committee's Evolution Working Group than read the Boost list. See http://groups.google.com/groups?q=comp.std.c%2B%2B for a web interface. A comment on comp.std.c++ should probably be like Boost review; say in plain language if you support or oppose the proposal so detailed comments don't obscure an overall view. (The Boost list is read by many active C++ committee members, but they tend to be library oriented rather than core language or evolution oriented.) An extended discussion of such a proposal would probably stray off-topic for Boost anyhow. --Beman PS: if you are interested in other proposals for the next C++ standard, http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/#pre_sydney has a wealth of interesting papers.

10 12

Re:[boost] Re: Re:Re: serialization library #17
by Robert Ramey 13 Mar '04

13 Mar '04

Jeff Flinn wrote: >Any thoughts on future serialization of boost::function even being >possible? >My use case is that I've a std::map of std::string/boost::function's that >provide user configurable filters that detemine what gets displayed in a >Table/List View. These currently are not being saved between sessions. It'd >be great to do mFilterMap & ar; Why would this not be possible, I don't see reason why it would be any kind of special case? Robert Ramey

1 0

Re:Re: Re:Re: [boost] [compatibility headers] fixes for Borland
by Robert Ramey 13 Mar '04

13 Mar '04

John Maddock wrote: >> Robert Ramey wrote: >> a) Sprinkle #ifdef BORLAND in those 14 files >> b) Tweak cpp_c_headers files >> c) Or ? what? >> >> What is the least worst way to handle this? >> >> If I have to use a) what is the point of even having cpp_c_headers? >Here's the problem: those headers were only supplied as a workaround for >compilers that don't supply new style headers at all, they all use the >following workaround: >#include <string.h> >namespace std{ using ::memcpy; } //etc >However for conforming compilers this is defective for two reasons: >It needlessly introduces C functions into the global namespace (including ><cstring> should not do that). >It shouldn't compile at all: memcpy is already declared in std, the version >in the global namespace is an alias introduced with a using declaration,and >importing it back into std *should fail*. >Now the interesting thing is, I know of only two vendors who are shipping >std conforming C headers: Borland and Metrowerks. Since you don't mention >the latter my guess is you're not testing with it ;-) >The normal workaround that Boost libs have been using is: >#include <cstring> >#include <boost/config.hpp> >#ifdef BOOST_NO_STDC_NAMESPACE >namespace std{ using ::memcpy; } >#endif OK, I can live with this. But if cpp_c_headers has conditioned on the compiler then what is the point of having it all? What use can it have? Robert Ramey

2 1

filesystem doc nit
by David Abrahams 13 Mar '04

13 Mar '04

"The Filesystem Library's fstream.hpp header simply uses the <fstream> standard library components as base classes, and then overrides the members requiring argument types of path." Technically, I don't think this is overriding, and the base classes don't require path arguments. Maybe you mean: "The Filesystem Library's fstream.hpp header simply uses the <fstream> standard library components as base classes, and then adds constructors, and overloads of the base interfaces, that accept path arguments instead of strings" -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 2