[boost] Re: RC_1_30_0 still broken -- More lexical_cast
In article <[EMAIL PROTECTED]>, Beman Dawes <[EMAIL PROTECTED]> writes >At 03:40 PM 3/17/2003, Terje Slettebø wrote: >> >>BOOST_NO_STRINGSTREAM >>BOOST_NO_STD_WSTRING >>BOOST_NO_INTRINSIC_WCHAR_T > >Are you sure disabling wide character support is really the solution, or >that it is really fully disabled? > >For the 2.95.x test at >http://boost.sourceforge.net/regression-logs/cs-linux-RC_1_30_0-links.html#confi >g_info%20gcc2953, >BOOST_NO_STD_WSTRING is already defined, so presumably wide character >support is already disabled. > >Look at the error messages from date_time testperiod below, and the source >code lines they refer to. At least directly, they don't seem releated to >wide character support. They are not, but the question is what is meant by BOOST_NO_STRINGSTREAM? Does it mean that std::stringstream is not supported and/or that std::basic_stringstream is not supported? The lexical_cast code assumes that is not standard if BOOST_NO_STRINGSTREAM is defined, and that it is standard if it is not defined. Clearly, the contents of are not standard otherwise the code would compile. Either we need to clarify the intent of BOOST_NO_STRINGSTREAM or we need to added another feature test macro, eg BOOST_NO_BASIC_STRINGSTREAM or no BOOST_NO_STD_SSTREAM. My preference is that we generalise the meaning of BOOST_NO_STRINGSTREAM, so that if that macro is defined the programmer cannot assume standard string stream support, which -- judging by the error messages -- which is the case. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0: gcc 2.96 boost/libs/python/test/opaque.cpp failure
There are gcc 2.96 (Redhat 7.3) compilation error for boost/libs/python/test/opaque.cpp: http://cci.lbl.gov/~rwgk/tmp/rc_1_30_0_opaque_fail.txt More recent gcc's don't seems to suffer from this problem. I am not sure this is important enough to delay the release any further. David? Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RC_1_30_0: minor patch:boost/test/detail/wrap_stringstream.hpp
I've just checked in a small patch to address this warning: cc-1460 CC: WARNING File = boost/boost/test/detail/wrap_stringstream.hpp, Line = 90 Function function "boost::wrap_stringstream::str" is redeclared "inline" after being called. wrap_stringstream::str() ^ Here is the patch: Index: wrap_stringstream.hpp === RCS file: /cvsroot/boost/boost/boost/test/detail/wrap_stringstream.hpp,v retrieving revision 1.2 diff -r1.2 wrap_stringstream.hpp 42,44c42,44 < wrap_stringstream& ref(); < wrapped_stream& stream(); < std::string const& str(); --- > inline wrap_stringstream& ref(); > inline wrapped_stream& stream(); > inline std::string const& str(); I've tested with gcc 2.69, Tru64/cxx and IRIX/CC (MIPSpro). I'll monitor our auto-builds (next run in about 2 hours) to check that this doesn't unexpectedly cause any problems somewhere else. Ralf __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Regex and STLPMT.LIB
Thanks for that. Malcolm Smith Analyst Programmer Comvision Pty Ltd http://www.comvision.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Douglas Paul Gregor Sent: Tuesday, 18 March 2003 15:07 To: Boost mailing list Subject: RE: [boost] Re: Re: Regex and STLPMT.LIB On Tue, 18 Mar 2003, Malcolm Smith wrote: > I've been to http://sourceforge.net/projects/boost/ but 1.30.0 is not listed > (or I'm blind). Where is the beta ? Carefully hidden here :) http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Regex and STLPMT.LIB
On Tue, 18 Mar 2003, Malcolm Smith wrote: > I've been to http://sourceforge.net/projects/boost/ but 1.30.0 is not listed > (or I'm blind). Where is the beta ? Carefully hidden here :) http://boost.sourceforge.net/regression-logs/boost_1_30_0_b1.zip Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Regex and STLPMT.LIB
I've been to http://sourceforge.net/projects/boost/ but 1.30.0 is not listed (or I'm blind). Where is the beta ? Malcolm Smith Analyst Programmer Comvision Pty Ltd http://www.comvision.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Edward Diener Sent: Tuesday, 18 March 2003 13:21 To: [EMAIL PROTECTED] Subject: [boost] Re: Re: Regex and STLPMT.LIB Malcolm Smith wrote: > I cannot find 1.30. Where ? The 1.30 release is the upcoming one but one could download it from SourceForge as a beta. I thought you might be trying that. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Another borland (mis)feature detection macro
"Chris Trengove" <[EMAIL PROTECTED]> writes: > I think you can get rid of the compilation error just be qualifying the use > of "value". For example, > >typedef X::type type; > > I have recently been attempting to port Boost.Python to BCC and have come > across lots of examples of this. The compilation errors all go away when the > static member is expilcitly qualified. Please let me know as you find patches; I'd be very happy to see Borland supported (but, I'm afraid, reluctant to invest the effort myself). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Another borland (mis)feature detection macro
"Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Several of the boost libraries select functionality based on the result
> of some compile-time test. The result is usually stored in a
> BOOST_STATIC_CONST( bool, test::value );
>
> The current Borland compiler does not allow these values to be used as
> template parameters though.
Are you referring to the compiler message
E2231 "Member ... cannot be used without an object" ?
For example, this is produced whenever you have something like
template
struct Y {
static const bool value = ...// some test here.
typedef X::type type;// X is some other template
};
I think you can get rid of the compilation error just be qualifying the use
of "value". For example,
typedef X::type type;
I have recently been attempting to port Boost.Python to BCC and have come
across lots of examples of this. The compilation errors all go away when the
static member is expilcitly qualified.
I also note that random/uniform_int.hpp and random/uniform_smallint.hpp have
just been patched to get around this problem, but just explictly qualifying
the member also fixes the compilation errors.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost in commercial software
I have received an inquiry asking for a list of companies that are using Boost to develop commercial software. If your company is using Boost libraries in its products and is willing to have it be known, I'd appreciate it if you post something or send me a private email to that effect. Thanks in advance, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Regex and STLPMT.LIB
Malcolm Smith wrote: > I cannot find 1.30. Where ? The 1.30 release is the upcoming one but one could download it from SourceForge as a beta. I thought you might be trying that. Evidently you are building with 1.29 or earlier. I don't see any STLPMT.LIB in the bcb5.mak so you are picking it up from somewhere strange for bcb5 and not from the regex make file for bcb5. > > I may have not used an explicit path for the MAKE operation. I will > rebuild it again. > > Thanks. > > Malcolm Smith > Analyst Programmer > Comvision Pty Ltd > http://www.comvision.org > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Edward Diener > Sent: Tuesday, 18 March 2003 13:01 > To: [EMAIL PROTECTED] > Subject: [boost] Re: Regex and STLPMT.LIB > > > Malcolm Smith wrote: >> Hi all, >> >> >> I just compiled the regex library under C++Builder 5. >> >> I've tried to compile an application and it complains about not being >> able >> to find STLPMT.LIB - I can find no information on this LIB. > > It's a BCB6 library for the stlPort implementation of the C++ standard > library. You shouldn't be getting it for a BCB5 regex build, however. > In the Boost 1.29 implementation, the bcb5.mak has no mention of > STLPMT.LIB. Are you using the Boost 1.30 implementation ? If so and > bcb5.mak does have STLPMT.LIB in it, it may be an error in the file. > > > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > ___ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Regex and STLPMT.LIB
I cannot find 1.30. Where ? I may have not used an explicit path for the MAKE operation. I will rebuild it again. Thanks. Malcolm Smith Analyst Programmer Comvision Pty Ltd http://www.comvision.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Edward Diener Sent: Tuesday, 18 March 2003 13:01 To: [EMAIL PROTECTED] Subject: [boost] Re: Regex and STLPMT.LIB Malcolm Smith wrote: > Hi all, > > > I just compiled the regex library under C++Builder 5. > > I've tried to compile an application and it complains about not being > able > to find STLPMT.LIB - I can find no information on this LIB. It's a BCB6 library for the stlPort implementation of the C++ standard library. You shouldn't be getting it for a BCB5 regex build, however. In the Boost 1.29 implementation, the bcb5.mak has no mention of STLPMT.LIB. Are you using the Boost 1.30 implementation ? If so and bcb5.mak does have STLPMT.LIB in it, it may be an error in the file. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Regex and STLPMT.LIB
Malcolm Smith wrote: > Hi all, > > > I just compiled the regex library under C++Builder 5. > > I've tried to compile an application and it complains about not being > able > to find STLPMT.LIB - I can find no information on this LIB. It's a BCB6 library for the stlPort implementation of the C++ standard library. You shouldn't be getting it for a BCB5 regex build, however. In the Boost 1.29 implementation, the bcb5.mak has no mention of STLPMT.LIB. Are you using the Boost 1.30 implementation ? If so and bcb5.mak does have STLPMT.LIB in it, it may be an error in the file. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Before we get too carried away...
On Thursday, March 13, 2003, at 8:32 AM, Beman Dawes wrote: At 02:24 AM 3/13/2003, Daryle Walker wrote: 4. My testing was with a stock Boost 1.29.0 from a zip file. If the CVS version of Boost already has fixes for CW-DS and/or CWP8.3, I'll switch to that and apologize for wasting everyone's time. Daryle, with all the current focus on 1.30.0, I'm not sure anyone even remembers what worked and what didn't work config-wise for 1.29.0. I know all my responses to you assumed you were working with current CVS state. So, yes, I think you should either switch to the CVS main trunk, branch RC_1_30_0, or just wait until 1.30.0 release. This is what I got when I switch from using my Boost 1.29 directory to my Boost-CVS directory (last updated on March 9th, no tags used [don't know how]): //= Metrowerks CodeWarrior C++ version 8.3 __cplusplus =199711L __STDC__=1 __STDC_VERSION__=199901L __MWERKS__ =0x3003 __MSL__ =0x8003 __MSL_CPP__ =0x8300 __embedded_cplusplus=0 __fourbyteints__=1 __IEEEdoubles__ =1 __profile__ =0 __powerc=1 __POWERPC__ =1 __MACH__=1 __APPLE__ =1 powerc =1 __STDC_HOSTED__ =0 * Metrowerks Standard Library version 0x8300 * Detected Platform: Mac OS Type char is signed Type wchar_t is signed byte order for type short =8 0 byte order for type int =24 16 8 0 byte order for type long=24 16 8 0 sizeof(wchar_t) =4 sizeof(short) =2 sizeof(int) =4 sizeof(long)=4 sizeof(float) =4 sizeof(double) =8 sizeof(long double) =8 CHAR_BIT=8 CHAR_MAX=0x7f WCHAR_MAX =0x7FFFU SHRT_MAX=0x7fff INT_MAX =0x7fff LONG_MAX=0x7fffL LLONG_MAX =0x7fffLL _POSIX_CHOWN_RESTRICTED =1 _POSIX_JOB_CONTROL [no value] _POSIX_NO_TRUNC =1 _POSIX_THREAD_ATTR_STACKADDR [no value] _POSIX_THREAD_ATTR_STACKSIZE [no value] _POSIX_THREAD_PRIO_INHERIT [no value] _POSIX_THREAD_PRIO_PROTECT [no value] _POSIX_THREAD_PRIORITY_SCHEDULING[no value] _POSIX_THREADS [no value] _POSIX_VDISABLE =((unsigned char)'\377') _POSIX_VERSION =198808L _POSIX2_VERSION =199212L * Boost version 103000 BOOST_USER_CONFIG = BOOST_COMPILER_CONFIG ="boost/config/compiler/metrowerks.hpp" BOOST_STDLIB_CONFIG ="boost/config/stdlib/msl.hpp" BOOST_PLATFORM_CONFIG ="boost/config/platform/macos.hpp" BOOST_DEDUCED_TYPENAME =typename BOOST_HAS_HASH [no value] BOOST_HAS_LONG_LONG [no value] BOOST_HAS_PTHREADS [no value] BOOST_HAS_STDINT_H [no value] BOOST_HAS_SLIST [no value] BOOST_HAS_THREADS[no value] BOOST_HAS_UNISTD_H [no value] BOOST_MSVC6_MEMBER_TEMPLATES [no value] BOOST_NESTED_TEMPLATE =template BOOST_NO_MEMBER_TEMPLATE_FRIENDS [no value] BOOST_NO_MS_INT64_NUMERIC_LIMITS [no value] BOOST_STD_EXTENSION_NAMESPACE =Metrowerks BOOST_UNREACHABLE_RETURN(0) [no value] //= I couldn't compile the config-test file. I got errors like: //= Error : undefined identifier 'empty_boost' config_test.cpp line 63 namespace boost_deduced_typename = empty_boost; Error : undefined identifie
RE: [boost] Regex and STLPMT.LIB
Additionally, this LIB is referenced in the LIB/DLL produced by the BCB5.MAK file supplied with boost. Malcolm Smith Analyst Programmer Comvision Pty Ltd http://www.comvision.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes Sent: Tuesday, 18 March 2003 11:59 To: Boost mailing list; Boost Subject: Re: [boost] Regex and STLPMT.LIB At 06:51 PM 3/17/2003, Malcolm Smith wrote: >I just compiled the regex library under C++Builder 5. > >I've tried to compile an application and it complains about not being able >to find STLPMT.LIB - I can find no information on this LIB. That's not a Boost library. It's a Borland library. On my machine, it is in a directory called \Program Files\Borland\CBuilder6\Lib. You might want to ask this sort of question on the Boost users list - [EMAIL PROTECTED] --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Regex and STLPMT.LIB
Strange. I've been using C++Builder (1-6) for YEARS and never come across it. I'll check further. Malcolm Smith Analyst Programmer Comvision Pty Ltd http://www.comvision.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Beman Dawes Sent: Tuesday, 18 March 2003 11:59 To: Boost mailing list; Boost Subject: Re: [boost] Regex and STLPMT.LIB At 06:51 PM 3/17/2003, Malcolm Smith wrote: >I just compiled the regex library under C++Builder 5. > >I've tried to compile an application and it complains about not being able >to find STLPMT.LIB - I can find no information on this LIB. That's not a Boost library. It's a Borland library. On my machine, it is in a directory called \Program Files\Borland\CBuilder6\Lib. You might want to ask this sort of question on the Boost users list - [EMAIL PROTECTED] --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Regex and STLPMT.LIB
At 06:51 PM 3/17/2003, Malcolm Smith wrote: >I just compiled the regex library under C++Builder 5. > >I've tried to compile an application and it complains about not being able >to find STLPMT.LIB - I can find no information on this LIB. That's not a Boost library. It's a Borland library. On my machine, it is in a directory called \Program Files\Borland\CBuilder6\Lib. You might want to ask this sort of question on the Boost users list - [EMAIL PROTECTED] --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regex and STLPMT.LIB
Hi all, I just compiled the regex library under C++Builder 5. I've tried to compile an application and it complains about not being able to find STLPMT.LIB - I can find no information on this LIB. Help ? Malcolm Smith Analyst Programmer Comvision Pty Ltd http://www.comvision.org ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken (apologies and help!)
Aleksey Gurtovoy wrote: Daniel Frey wrote: Still looks broken over here: http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 I think it's OK to revert the patch to get 1.30.0 out, Which patch? John said the changes that caused the disturbance were never intended to be checked in. Sorry, by "patch" I meant the CVS update from 1.5 -> 1.6/1.7. but for the future, I think we should keep in mind that it's actually is_function that is broken and needs to be fixed AFAICS. I'm still wondering what happened. Please check everything what I say, as I already made too many errors wrt type-traits: John added the test for is_function to the code that was intended for compilers that don't have partial specialization - which is why it failed as is_function needs partial specialization to work with references. But is_class also calls is_reference, so it seems that this does work, thus I think an implementation could be possible. But there is another point: AFAIK the GCC does support partial specialization, right? Given that this is true, the change in CVS can't fix something (as it is not used for the GCC) or the config for the GCC is broken - or I missed something obvious (again) :-} Even if we don't take the last point into account as it was maybe just an overlook from John when he accidentially committed the code to CVS, it's still the question whether is_function could be "fixed" given that is_reference seems to be available for compilers without partial specialization. If it was easy enough it would be fixed long before the release. In any case, I would be strongly opposite to sticking in a new implementation just now. It's bad enough "the patch" got us delayed for more than a day. I don't really wanted to suppose changes that defer the 1.30.0, I just tried to find a way to work around the lock-problem of SourceForge. OK, I think I should leave it to the experts now... :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: RC_1_30_0 still broken (apologies and help!)
At 05:01 PM 3/17/2003, Aleksey Gurtovoy wrote: >> The patch to is_class would work if is_function could be called with >> a reference, so I think it's worth to consider fixing is_function. As >> John is the expert, I think he can decide whether it's better to wait >> for the SourceForge-folks to fix he lock-problem or if it's easy >> enought (and thus faster) to fix is_function... > >If it was easy enough it would be fixed long before the release. In any >case, I would be strongly opposite to sticking in a new implementation >just now. It's bad enough "the patch" got us delayed for more than a >day. Aleksey has done the revert and the tests that were failing are now passing. AFAICS, the only outstanding issue is lexical_cast on g++ 2.95.x causing date_time library failures. As soon as that is dealt with, we will release. In the meantime, no other changes should be made to RC_1_30_0 please. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_0 still broken -- More lexical_cast
>From: "Beman Dawes" <[EMAIL PROTECTED]> > At 03:40 PM 3/17/2003, Terje Slettebø wrote: > > >Well, I think this reinforces the suggestion to define > >BOOST_NO_STRINGSTREAM > >for 2.95.x. Comments? > > > >Either that, or to have some way to detect where > std::basic_stringstream<> > >is not supported, and turn off wide character support for that, in > >lexical_cast. Currently, it disables wide character support if one of the > >following macros are set: > > > >BOOST_NO_STRINGSTREAM > >BOOST_NO_STD_WSTRING > >BOOST_NO_INTRINSIC_WCHAR_T > > Are you sure disabling wide character support is really the solution, or > that it is really fully disabled? Well, as was shown with the earlier lexical_cast, g++ 2.95 does have std::stringstream, but not std::basic_stringstream. This shows that even if it has stringstream, it doesn't have the wide character version of it. This means it can't be used with wide characters with lexical_cast. So this has to be signalled somehow to lexical_cast. Any macro might do, but as it has only partial stringstream support, defining BOOST_NO_STRINGSTREAM seems reasonable. An alternative is to create a macro for partial support, but the end result is the same for lexical_cast: No wide character support for that compiler version. > For the 2.95.x test at > http://boost.sourceforge.net/regression-logs/cs-linux-RC_1_30_0-links.html#c onfig_info%20gcc2953, > BOOST_NO_STD_WSTRING is already defined, so presumably wide character > support is already disabled. > > Look at the error messages from date_time testperiod below, and the source > code lines they refer to. At least directly, they don't seem releated to > wide character support. > > /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp:173: > syntax error before `;' Line 173 has: std::basic_stringstream stream; I think the evidence can't be much clearer. :) The rest appears to be cascading errors, but this is the first reported one. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: io operations for stl containers?
>From: "Jason House" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> > typedef std::vector vector_char;
> >
> > vector_char values;
> >
> > // Fill with 'A', 'B', 'C'
> >
> > std::cout << io::format("[", "]", ", ", "\'", "\'") <<
values;
> >
> > Output:
> >
> > ['A', 'B', 'C']
> >
> > However, is this overkill?
>
> It seems that way, especially considering that if it was a vector of
> anything other than a fundamental type with std::cout << already defined
> for it, you could add a second io::format("\'","\'","") and it
> would work.
Right. However, I've already implemented it, anyway, as an experimental
feature. :) Besides, the two extra strings default to empty strings.
> > Feedback is most welcome.
>
> Would possibly a function object for outputting the contained item be
> better?
[I first thought you meant a function object for outputting the _container_,
not the elements, so I wrote the following section, before realising that
you had meant for the elements. I address it afterwards]
I've been thinking of the same, with regard to outputting the _container_
(not the element, itself). In an earlier posting, I mentioned the
possibility of using function objects, as a way to generalising the handling
of output. I also mentioned having the kind of function objects like BGL,
i.e. "visitors". That is, rather than only overloading the operator(), it
may provide several member functions, e.g.:
class stream_visitor
{
public:
void start();
void end();
void delimiter();
};
std::cout << format(stream_visitor(...));
One could then provide a function object which does what it currently does.
There are issues with this, however. I've been thinking long and hard about
how to provide this functionality. The issue is that the functors has to be
stored somewhere, and being accessible. With the current version, all the
format objects are the same type, so you know its type when it's stored and
retrieved. However, if arbitrary (generic) functors are stored, you don't
know its type, when you access it, when performing output. It's similar to
trying to store different types in the same std::vector.
There are solutions to this, and one is to use a common interface, and all
functors inherit from that interface, and override the virtual functions.
That would let you store them using a pointer to the interface. However,
this means the overhead of a virtual function call per call to the member
functions above. This may not be that much, but it's still also the issue
that generic functors can't be used - they all have to inherit from the same
interface.
For this reason, I found that this could be a possible later addition, if we
find that the added flexibility is worth it.
Also, the current syntax could still be kept as a convenience, by having an
overloaded constructor taking the strings, and creating the functor. So a
change may be backwards compatible.
> Here's a possibly mutilated example (I've never actually used
> function objects before):
>
> std::ostream delimitted_char(std::ostream out, char x, std::string
> first, std::string last);
>
> std::cout << io::format("[", "]", ", ",
> bind("\'", 4, bind("\'", 3, delimitted_char)))
Yes, it's possible, but I this seems to make it more complex than simply
using io::format("[", "]", ",", "\'", "\'"), with the two last
strings defaulted to empty strings.
> > There's yet another alternative way this may be done, using
"placeholder"
> > types, i.e.:
> >
> > std::cout << io::format >(...); // Sets the format for
all
> > vectors
> > std::cout << io::format<_>(...); // Sets the format for all types
(defaults)
> >
> > This would avoid hardcoding any defaults, as the user could change it.
> >
> > The output routines could then check the formats in the following order,
> > e.g. for "std::vector":
> >
> > If there's a format set for std::vector, use it, else
> > if there's a format set for std::vector<_> (all vectors), use it, else
> > use format for _.
> >
> > Comments?
>
> I like it :)
I found it quite neat, as well. :) Interestingly, one important contribution
of libraries are concepts and idioms. Since "_" is used as placeholder other
places, making it mean "any type" here is reasonably intuitive, as well.
> Using just _ scares me a bit... It would have to have a good default :)
Well, it doesn't matter that much, as all the formats are user-settable. The
library may provide a setting for _, but it can easily be set to something
else by the user, in the same way.
In fact, the current version in the Files (the first upload), has as
"defaults" that all strings are empty. So the defaults have existed from the
beginning, anyway. After all, you have to use _some_ format to print types
for which no explicit format has been set. Being able to set this default
explicitly, rather than hardcoding it in the library, should therefore be a
good thing.
In fact, I've made an implementation of the above, yesterday, and I'll just
make some more tests, and upload it to the Files
RE: [boost] Re: RC_1_30_0 still broken (apologies and help!)
Daniel Frey wrote: > > Still looks broken over here: > > > > http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 > > I think it's OK to revert the patch to get 1.30.0 out, Which patch? John said the changes that caused the disturbance were never intended to be checked in. > but for the > future, I think we should keep in mind that it's actually is_function > that is broken and needs to be fixed AFAICS. It's not "broken", it doesn't work for reference types on compilers without partial template specialization because at the time it wasn't clear how to make it work. If you have an implementation in mind that would perform better, please post it. > The patch to is_class would work if is_function could be called with > a reference, so I think it's worth to consider fixing is_function. As > John is the expert, I think he can decide whether it's better to wait > for the SourceForge-folks to fix he lock-problem or if it's easy > enought (and thus faster) to fix is_function... If it was easy enough it would be fixed long before the release. In any case, I would be strongly opposite to sticking in a new implementation just now. It's bad enough "the patch" got us delayed for more than a day. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_0 still broken -- More lexical_cast
At 03:40 PM 3/17/2003, Terje Slettebø wrote: >Well, I think this reinforces the suggestion to define >BOOST_NO_STRINGSTREAM >for 2.95.x. Comments? > >Either that, or to have some way to detect where std::basic_stringstream<> >is not supported, and turn off wide character support for that, in >lexical_cast. Currently, it disables wide character support if one of the >following macros are set: > >BOOST_NO_STRINGSTREAM >BOOST_NO_STD_WSTRING >BOOST_NO_INTRINSIC_WCHAR_T Are you sure disabling wide character support is really the solution, or that it is really fully disabled? For the 2.95.x test at http://boost.sourceforge.net/regression-logs/cs-linux-RC_1_30_0-links.html#config_info%20gcc2953, BOOST_NO_STD_WSTRING is already defined, so presumably wide character support is already disabled. Look at the error messages from date_time testperiod below, and the source code lines they refer to. At least directly, they don't seem releated to wide character support. --Beman In file included from /home/boost/boost-regress-RC_1_30_0/boost/boost/date_time/date_parsing.hpp:10, from /home/boost/boost-regress-RC_1_30_0/boost/boost/date_time/gregorian/parsers.hpp:9, from /home/boost/boost-regress-RC_1_30_0/boost/boost/date_time/gregorian/gregorian.hpp:17, from ../libs/date_time/test/gregorian/testperiod.cpp:6: /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp:173: syntax error before `;' /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp: In method `bool boost::detail::lexical_stream::operator >>(InputStreamable &)': /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp:146: parse error before `>' /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp: In function `Target boost::lexical_cast(Source)': /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp:181: parse error before `::' /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp:185: parse error before `::' /home/boost/boost-regress-RC_1_30_0/boost/boost/lexical_cast.hpp:187: confused by earlier errors, bailing out ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: bidirectional map
At 12:27 PM 3/17/2003, Joaquín Mª López Muñoz wrote: > > >Jeff Garland ha escrito: > >> > OK, so how I ask for preliminary review? Posting a mail here? >> >> Yes, you can just ask for preliminary feedback on this list. >> Another thing you can do is put the code in the boost-sandbox. >> This helps get things into the boost structure and allows other >> boosters to keep up with changes as the library is evolving >> towards formal submission. Ask one of the moderators of the >> boost sandbox for CVS access if you want to do this. >> > >OK, I don't know if uploading non-boostified code to the sandbox >is a proper way to do. If so, please some moderator help me do it >(if not, the code is in the Files section aka the vault). I'd say wait until you have Boostified code before putting it in the sandbox. >So, I guess I'll have to wait for comments about the library to pour >in :) Maybe when the dust of 1.30.0 has settled down. Yes:-) --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_0 still broken -- More lexical_cast
>From: "Gennaro Prota" <[EMAIL PROTECTED]> > On Mon, 17 Mar 2003 14:47:20 +0300, Vladimir Prus <[EMAIL PROTECTED]> > wrote: > > >Gennaro Prota wrote: > > > >>>Ok. I've forwarded this to Kevlin. > >> > >> Maybe there's more than one problem here. I see that Vladimir talks > >> about warnings while Jeff about errors. Also maybe it helps to see the > >> exact condition to define BOOST_NO_STRINGSTREAM in > >> config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a > >> hand... > > > >I'm sorry, "warning" in my post is typo. It should have been "error", and > >the error message is precisely the same as previously reported. I just > >wanted to note that lexical_cast was not broken with gcc 2.95.4 until > >recently. > > Ok. That compiler has always used the new header. I think > the problem is that while the old lexical_cast just used > std::stringstream the new version uses the more general > std::basic_stringstream<>. Aha. I think this may be the key. Thanks a lot. :) I was really wondering what the heck was different. :) Well, I think this reinforces the suggestion to define BOOST_NO_STRINGSTREAM for 2.95.x. Comments? Either that, or to have some way to detect where std::basic_stringstream<> is not supported, and turn off wide character support for that, in lexical_cast. Currently, it disables wide character support if one of the following macros are set: BOOST_NO_STRINGSTREAM BOOST_NO_STD_WSTRING BOOST_NO_INTRINSIC_WCHAR_T even though it may work partially or fully with wide characters, despite one of these set. For example, Intel C++ 7.0 on Windows has intrinsic wchar_t, and passes all the lexical_cast tests, but as the intrinsic characters have to be turned on with a switch (for compatibility with MSVC 6/7), and there appears to be no macro to detect the switch, the config sets BOOST_NO_INTRINSIC_WCHAR_T. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: bidirectional map
Jeff Garland ha escrito: > > OK, so how I ask for preliminary review? Posting a mail here? > > Yes, you can just ask for preliminary feedback on this list. > Another thing you can do is put the code in the boost-sandbox. > This helps get things into the boost structure and allows other > boosters to keep up with changes as the library is evolving > towards formal submission. Ask one of the moderators of the > boost sandbox for CVS access if you want to do this. > OK, I don't know if uploading non-boostified code to the sandbox is a proper way to do. If so, please some moderator help me do it (if not, the code is in the Files section aka the vault). So, I guess I'll have to wait for comments about the library to pour in :) Maybe when the dust of 1.30.0 has settled down. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken (apologies and help!)
David Abrahams wrote: "Andreas Huber" <[EMAIL PROTECTED]> writes: Still looks broken over here: http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 I think it's OK to revert the patch to get 1.30.0 out, but for the future, I think we should keep in mind that it's actually is_function that is broken and needs to be fixed AFAICS. The patch to is_class would work if is_function could be called with a reference, so I think it's worth to consider fixing is_function. As John is the expert, I think he can decide whether it's better to wait for the SourceForge-folks to fix the lock-problem or if it's easy enought (and thus faster) to fix is_function... Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] filesystem library name RC_1_30_0
At 07:17 AM 3/17/2003, Thomas Witt wrote: >the library name is still "fs". I was under the impression that this was >only temporary and should be changed to a more boost compatible >"boost_filesystem" before release. From a pratical point of view "fs" >seems like begging for a nameclash. Good point. OK, fixed in CVS main trunk and RC_1_30_0. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: io operations for stl containers?
Terje Slettebø wrote:
> typedef std::vector vector_char;
>
> vector_char values;
>
> // Fill with 'A', 'B', 'C'
>
> std::cout << io::format("[", "]", ", ", "\'", "\'") << values;
>
> Output:
>
> ['A', 'B', 'C']
>
> However, is this overkill?
It seems that way, especially considering that if it was a vector of
anything other than a fundamental type with std::cout << already defined
for it, you could add a second io::format("\'","\'","") and it
would work.
>
> Feedback is most welcome.
Would possibly a function object for outputting the contained item be
better? Here's a possibly mutilated example (I've never actually used
function objects before):
std::ostream delimitted_char(std::ostream out, char x, std::string
first, std::string last);
std::cout << io::format("[", "]", ", ",
bind("\'", 4, bind("\'", 3, delimitted_char)))
Of course, the function object parameter should have a nice default to
the << operator.
> > > There was a suggestion for allowing generic formats, though, using
> > > the same format for all instantiations of a template. The question is
> how to
> > > do it. The current version stores the format for each specific type, as
> you
> > > say. Volodya suggested a couple of ways it could be done, partial
> > > specialisation, or storing the template name in a map.
>
> There's yet another alternative way this may be done, using "placeholder"
> types, i.e.:
>
> std::cout << io::format >(...); // Sets the format for all
> vectors
> std::cout << io::format<_>(...); // Sets the format for all types (defaults)
>
> This would avoid hardcoding any defaults, as the user could change it.
>
> The output routines could then check the formats in the following order,
> e.g. for "std::vector":
>
> If there's a format set for std::vector, use it, else
> if there's a format set for std::vector<_> (all vectors), use it, else
> use format for _.
>
> Comments?
I like it :)
Using just _ scares me a bit... It would have to have a good default :)
The result would be intuitive, so I guess a use at your own risk is ok.
In some ways, maybe it's good that items like char wouldn't use it :)
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_0 still broken (apologies and help!)
At 08:16 AM 3/17/2003, David Abrahams wrote: >Still looks broken over here: > >http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 We are still waiting for SourceForge to clear an errant lock. It can't be fixed until then. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Outstanding patches and fixes - Sunday night update
At 07:14 AM 3/17/2003, John Maddock wrote: >* [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes. >Awaiting response from John Maddock. >(Since this one just eliminates warnings, the release won't be held >for it.) > >That one will have to wait - gcc 3.3 hasn't been released yet anyway. OK, I've cleared it off the 1.30.0 list. Thanks. > >* [type_traits] is_class.hpp problems >Awaiting response from John Maddock. > >I still can't commit to is_class.hpp - we'll have to wait for sourceforge >by the looks of it - I had thought the problem would have timed out by >now :-( > >* [type_traits] is_polymorphic_test and stateless_test failures. >Awaiting response from John Maddock. > >Reverting is_class.hpp will fix those. > >I'll go and hide now before I mess something else up! Hey, it isn't your fault that SourceForge can't get their locking straight. The last time this caused Boost trouble, I put in a support request for them to time out locks. Other's supported that request, but still no action from them. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> [...]
> What monster are you creating, man? :-)
I must be the only one here that actually writes application code,
because it never ceases to amaze me how everyone else can follow
all these neat and tidy rules for writing "pure" code. I happen to
have a business app where a lot of business data gets stored in each
object, and really, 10 fields isn't that large, and hardly a "monster".
By comparison, open up your favorite contact manager, and look
how many fields each contact has, and imagine that being
encapsulated as an object. ;)
> Ok, assuming that you need so much parameters, and that there's
> a speed gain with using call_traits,
Considering that some of the fields are std::vector<>s, and some
of them are bools, you tell me. ;)
> [...]
> foo f(x1, x2, x3, (void(*)(X1, X2, X3))0 );
Clever, but I don't need call_traits<> that badly. ;) I'll just make
everything a const&. If you could take the address of a c'tor, this
actually might be possible. Consider this code, which illustrates
what I want to do:
#define PARAM(t) boost::call_traits::param_type
template
class wrapper
{
template
wrapper(int v, PARAM(U1) v1, PARAM(U2) v2, ...,
void (*)(U1, U2, ...) = &T::T)
: value_added_member_(v), data(v1, v2, ...) { }
private:
int value_added_member_;
T data_;
};
Unfortunately, &T::T isn't allowed. I understand why (sort of), but
it might actually make your trick be useful (or maybe not, I don't
know). On the other hand, I suppose I could create a Create()
function for each T, and use that instead (except that then I lose
value semantics, which are more important than some syntax
sugar).
> [...]
> As ugly as sin, but shouldn't make your Frankenstein appear
> much worse than it already is :-)
LOL! Well, I don't like the large number of parameters any more
than you do, but considering the alternatives, it's really not a bad
solution.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: bidirectional map
> OK, so how I ask for preliminary review? Posting a mail here? Yes, you can just ask for preliminary feedback on this list. Another thing you can do is put the code in the boost-sandbox. This helps get things into the boost structure and allows other boosters to keep up with changes as the library is evolving towards formal submission. Ask one of the moderators of the boost sandbox for CVS access if you want to do this. > I don't really know how to start this process, whether some formality > is required or not. Nope. > To the best of my knowledge, it is very difficult to fit an n-key container, where > > n>2, into the interface of a map. IMHO such a container resembles more a set > (I'm slowly working on this BTW). So, I guess I'll try to Boost this alone. Sounds good. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: RC_1_30_0 still broken (apologies and help!)
"Andreas Huber" <[EMAIL PROTECTED]> writes: > Beman & John, > >> Both the main trunk and RC_1_30_0 are working fine for me as of Sunday 6PM >> US Eastern time. > > Douglas Gregor has already fixed the is_class.hpp problem, please see > > http://lists.boost.org/MailArchives/boost/msg45230.php > >> Today's Win32 RC_1_30_0 regression tests (just posted) are showing new >> fails for VC++ 6 and VC++ 7 on is_polymorphic_test and is_reference_test. >> Are these related to the is_class problem? > > I don't think so, is_class.hpp is working just fine for me now with CVS > state from 2 hours ago... Still looks broken over here: http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Outstanding patches and fixes - Sunday nightupdate
"John Maddock" <[EMAIL PROTECTED]> writes: | * [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes. | Awaiting response from John Maddock. | (Since this one just eliminates warnings, the release won't be held | for it.) | | That one will have to wait - gcc 3.3 hasn't been released yet anyway. It was mostly indended as a heads-up, so no prob. -- Lgb ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
On Mon, 17 Mar 2003 14:47:20 +0300, Vladimir Prus <[EMAIL PROTECTED]> wrote: >Gennaro Prota wrote: > >>>Ok. I've forwarded this to Kevlin. >> >> Maybe there's more than one problem here. I see that Vladimir talks >> about warnings while Jeff about errors. Also maybe it helps to see the >> exact condition to define BOOST_NO_STRINGSTREAM in >> config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a >> hand... > >I'm sorry, "warning" in my post is typo. It should have been "error", and >the error message is precisely the same as previously reported. I just >wanted to note that lexical_cast was not broken with gcc 2.95.4 until >recently. Ok. That compiler has always used the new header. I think the problem is that while the old lexical_cast just used std::stringstream the new version uses the more general std::basic_stringstream<>. To say, it is a bit more exigent as to what to take out from , and the config system doesn't tell it that the header is actually broken. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] filesystem library name RC_1_30_0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Beman, the library name is still "fs". I was under the impression that this was only temporary and should be changed to a more boost compatible "boost_filesystem" before release. From a pratical point of view "fs" seems like begging for a nameclash. Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+dbzj0ds/gS3XsBoRAv8AAJ9P0UYTuzG3PhFMNoUFEQBenIfLJQCcDb1A rhx1Fbk5gxR7f3oQpxAvCSU= =8TnF -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Outstanding patches and fixes - Sunday nightupdate
* [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes. Awaiting response from John Maddock. (Since this one just eliminates warnings, the release won't be held for it.) That one will have to wait - gcc 3.3 hasn't been released yet anyway. * [type_traits] is_class.hpp problems Awaiting response from John Maddock. I still can't commit to is_class.hpp - we'll have to wait for sourceforge by the looks of it - I had thought the problem would have timed out by now :-( * [type_traits] is_polymorphic_test and stateless_test failures. Awaiting response from John Maddock. Reverting is_class.hpp will fix those. I'll go and hide now before I mess something else up! John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
Gennaro Prota wrote: >>Ok. I've forwarded this to Kevlin. > > Maybe there's more than one problem here. I see that Vladimir talks > about warnings while Jeff about errors. Also maybe it helps to see the > exact condition to define BOOST_NO_STRINGSTREAM in > config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a > hand... I'm sorry, "warning" in my post is typo. It should have been "error", and the error message is precisely the same as previously reported. I just wanted to note that lexical_cast was not broken with gcc 2.95.4 until recently. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Outstanding patches and fixes - Sunday night update
At 10:40 PM 3/16/2003, Giovanni Bajo wrote:
>Could this patch be accepted in time for 1.30.0? I asked yesterday for a
>fix to array.hpp that allows it to be used when exceptions are disabled,
>and this looks legit to me.
The change looks innocuous to me. Would anyone object if I go ahead an
apply it? (I'll test with Win32 compilers and only commit if it causes no
problems.)
--Beman
> array.hpp.diff --
>*** array_cvs.hpp Mon Mar 17 04:31:25 2003
>--- array.hpp Mon Mar 17 04:33:27 2003
>***
>*** 31,36
>--- 31,37
>
> // FIXES for broken compilers
> #include
>+ #include
>
> namespace boost {
>
>***
>*** 126,132
> #endif
> // check range (may be private because it is static)
> static void rangecheck (size_type i) {
>! if (i >= size()) { throw std::range_error("array"); }
> }
>
> };
>--- 127,133
> #endif
> // check range (may be private because it is static)
> static void rangecheck (size_type i) {
>! if (i >= size()) {
>boost::throw_exception(std::range_error("array")); }
> }
>
> };
>
> array.hpp.diff --
>
>Thanks
>Giovanni Bajo
>
>___
>Unsubscribe & other changes:
>http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: RC_1_30_0 still broken -- More lexical_cast
On Mon, 17 Mar 2003 09:35:11 +0100, Terje Slettebø <[EMAIL PROTECTED]> wrote: >>From: "Vladimir Prus" <[EMAIL PROTECTED]> >> I don't have much to say, but lexical_cast was broken just now. My code >which >> was compiling a week ago and wasn't changed since now produces the same >> warning, after updating to RC_1_30_0. > >Ok. I've forwarded this to Kevlin. Maybe there's more than one problem here. I see that Vladimir talks about warnings while Jeff about errors. Also maybe it helps to see the exact condition to define BOOST_NO_STRINGSTREAM in config/stdlib/sgi.hpp, with the comment therein? Just trying to lend a hand... Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] filesystem RC_1_30_0
At 01:38 AM 3/17/2003, Victor A. Wagner, Jr. wrote: >I finally got simple_ls to compile and link. > >The build now correctly builds two libraries (one release, one debug) and >if you point to the right place (shouldn't there be some way to marshall >the libraries instead of leaving them scattered throughout the build >area?). Yes, but the problem is non-trivial. There is a whole mailing list devoted to trying to solve the "install" problem. See http://lists.boost.org/mailman/listinfo.cgi/boost-install >You also, with VC++, need to know what parameters were used in the code >generation options, or you'll get some weird looking "multiple defines". >These parameters are >for release: Multi-threaded DLL (/MD) >for debug: Multi-threaded Debug DLL (/MDd) Yes, but that's a general build issue that applies to all built libraries. It should really be reported to the [EMAIL PROTECTED] mailing list. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [call_traits] bcc failure
On Sun, 16 Mar 2003 11:47:57 -0600, "David B. Held"
<[EMAIL PROTECTED]> wrote:
>"Gennaro Prota" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>> [...]
>> I don't know if it's useful or not but it's certainly usable. The fact
>> that deduction fails in your case doesn't mean it fails always; and
>> for named templates there's still the possibility to explicit specify
>> template arguments. In your case, you could do:
>> [...]
>> foo f(x, (X*)0 );
>> [...]
>
>The problem is that it doesn't scale very well. I would like to
>forward c'tors that take around 8-10 arguments.
What monster are you creating, man? :-) Ok, assuming that you need so
much parameters, and that there's a speed gain with using call_traits,
it's enough to add one more of them to deduce all the template
arguments. Example:
class X1 {};
class X2 {};
class X3 {};
class foo
{
public:
template
foo(typename boost::call_traits::param_type v1,
typename boost::call_traits::param_type v2,
typename boost::call_traits::param_type v3,
void(*)(U1, U2, U3)
)
{ }
};
int main()
{
X1 x1;
X2 x2;
X3 x3;
foo f(x1, x2, x3, (void(*)(X1, X2, X3))0 );
}
As ugly as sin, but shouldn't make your Frankenstein appear much worse
than it already is :-)
PS: I'm just joking!
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: bidirectional map
jeff ha escrito: > On Wed, 12 Mar 2003 17:07:54 -0600, David B. Held wrote > > > I'd say 6 or 7 people expressing interest is more than enough to justify > > Boostifying the code at this stage. > > I agree. Since you have written an article which clearly describes > the concept and provides an example it seems to me that you should > be able to as for preliminary review from interested parties before > you boostify the documentation. OK, so how I ask for preliminary review? Posting a mail here? I don't really know how to start this process, whether some formality is required or not. [stuff deleted] > > Also, it looks like the early consensus is that multi-key/value > > support is desired, so I think we should have a good look at your > > implementation/design to see if it is general enough. > > While a few folks have asked for this, it is up to you if you really want to > take on the additional burden. Submitting, going thru the review, porting and > maintaining a boost library is a huge amount of effort. While I think a > generic multi-key container would be really cool, it is up to you to accept > that scope. I, for one, would rather see a good bi-directional map sooner > rather than waiting for a more general solution. I honestly can't think of a > case where I would have needed the more general solution and I there is always > a complexity tradeoff. To the best of my knowledge, it is very difficult to fit an n-key container, where n>2, into the interface of a map. IMHO such a container resembles more a set (I'm slowly working on this BTW). So, I guess I'll try to Boost this alone. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo > > > Jeff > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 still broken -- More lexical_cast
>From: "Vladimir Prus" <[EMAIL PROTECTED]> > Terje Slettebø wrote: > > > > /home/boost/boost-regress/boost/boost/lexical_cast.hpp:173: syntax error > > > before `;' > > > > Looking at the CVS, it appears the reason for this is that > > config/compiler/gcc.hpp no longer defines BOOST_NO_STRINGSTREAM, even > > though it should, at least for 2.95.x and below, as is shown with the above > > errors.. > > > > The change was done about a year ago, though, so it appears lexical_cast > > hasn't been working on g++ 2.95.x for a long time. > > I don't have much to say, but lexical_cast was broken just now. My code which > was compiling a week ago and wasn't changed since now produces the same > warning, after updating to RC_1_30_0. Ok. I've forwarded this to Kevlin. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 still broken -- More lexical_cast
Terje Slettebø wrote: > > /home/boost/boost-regress/boost/boost/lexical_cast.hpp:173: syntax error > > before `;' > > Looking at the CVS, it appears the reason for this is that > config/compiler/gcc.hpp no longer defines BOOST_NO_STRINGSTREAM, even > though it should, at least for 2.95.x and below, as is shown with the above > errors.. > > The change was done about a year ago, though, so it appears lexical_cast > hasn't been working on g++ 2.95.x for a long time. I don't have much to say, but lexical_cast was broken just now. My code which was compiling a week ago and wasn't changed since now produces the same warning, after updating to RC_1_30_0. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
