Re: [boost] [type traits] type_with_alignment/alignment_of on GCC
> Why not do the same for other compilers? For instance, on GCC: Last time I checked __align_of didn't work with templates, which is a bit of a showstopper in this case.. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost::regex w/o exceptions?
> Also I see the existence of boost::regbase::use_except and > boost::regbase::failbit > I don't see how to use them in a way to enable/disable exceptions in > regular > expressions, dispite probably the activation of the general > BOOST_NO_EXCEPTIONS > (Shame on me!). > > Question: It seems, that boost::regbase::use_except is always active, > because it > is or'ed to the flags arguments in every(?) c'tor or assignment of > reg_expression. > Is that true? Yes. > If that is true: Why does the flag regbase::use_except (officially) > exist? It's a historical accident and should have been removed from the docs. > Lets assume, that throwing boost::bad_expression is a general policy (I > can live with that), > it would be **very** nice to have at least one (probably static) member > function, > which takes a textual regular expression and an optional bunch of > regbase flags as arguments and > returns a bool, which simply returns true in case of a valid expression, > otherwise false. What > do you think of that? You could call the undocumented member function set_expression which would return 0 on success, alternatively you're back to rolling your own, BTW why do you want this? If a regular expression is valid, then presumably at some point you would want to use it? I ask because the job of checking the expression for validity is essentially the same as compiling it to a state machine. John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [for Win] [was: Re: 1.30.0->1.30.2: nomorethreadsupportfor Linux?]
> Thanks for your reply. > I've created my own vcproj (VC++ 7.1 project) for building the libs that I > need, > and I've used the /MD flag which is the "multithread- and DLL-specific > versions" flag (used also for my application), > which means that everything is fine, right? Yep. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [for Win] [was: Re: 1.30.0->1.30.2: no more threadsupportfor Linux?]
> I haven't followed this thread completely, but I have a question. > I'm working on Win 2k, and I'm using VC++ 7.1. Building > boost with this toolset, do I need to specify something to make it > thread-safe? Actually you need to do more than that - you need to compile Boost against the same runtime library options that you use to build your application - otherwise you will get linker errors at the very least. Relevant options are: multi : multithreaded builds single> : single threaded builds dynamic : dynamic runtime static : static runtime. The default behaviour is to build against the dynamic (and thread safe) runtime, so if that's what you are using then you're OK, if you want the static runtime library versions as well then: bjam -sTOOLS=vc7.1 -sBUILD="debug release multi/single static" will do the job. Oh, and to answer your question: Boost is always as thread safe as the runtime it's built against. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
> > Threading support is on when BOOST_HAS_THREADS is defined, and off when it's > > not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both of > > these mentioned in the configure generated user.hpp (and in the config > > docs). > > So if I my program runs only on systems that I know support threads, > and I want shared_ptr to use threading support, my program can guarantee > this by defining BOOST_HAS_THREADS? No matter whether the user's Boost > install is - > > 1) Simply extracted from the tarball > 2) Configured without thread support > 3) Configured with thread support > > And I don't need to define anything about the platform thread library being > used, like BOOST_HAS_PTHREADS? OK lets start with Linux and gcc as a specific and special case - in this case I think that will work - BOOST_HAS_PTHREADS will be defined anyway, but remember that your std lib will not be thread safe unless you define _REENTRANT, and if you do that then BOOST_HAS_THREADS will get defined anyway by the config system (either the out-the-box version or the configure'd one). Of course the user could always manually configure boost in some obscure way, or deliberately disable thread support with BOOST_DISABLE_THREADS, but if they've done that then you should probably be emitting a #error not trying to work around it. In the general case though, we're back to the situation that your code will not be thread safe unless you invoke your chosen compiler with some magic special flag (or in the case of IBM Visual Age use a different compiler front end altogether), and if you do that then Boost.config will detect it's presence by whatever macros it sets (usually but not always _REENTRANT) and turn on BOOST_HAS_THREADS. You should always regard BOOST_HAS_THREADS as *information*, not as something you set yourself, in 99% of cases if you find it's not set, then it's because the compiler in it's current mode isn't capable of producing thread safe code. Note for example that Boost.config explicitly defines BOOST_DISABLE_THREADS for gcc on some platforms because we know that gcc isn't capable of producing thread safe code on those platforms yet (even though they do have a perfectly good pthread lib). Finally if you're configuring your program via autoconf then there are some nice looking autoconf macros on the net, for example: http://ac-archive.sourceforge.net/Installed_Packages/acx_pthread.html. Sorry to make this complicated, but threads _are_ complicated John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] int64_t with MSVC 7.1 & 'strict' /Za option
> Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option /Za 'disable > language extensions' it seems that > > boost::int64_t isn't available. > > After a journey through the labryinthine config modules, I have got compiling > with > > #define BOOST_HAS_MS_INT64 // required if language extensions disabled /Za. > > as the first statement. > > but I am unclear if this is a deficiency in either boost/cstdint and/or > date-time/compiler_config.hpp > > or in my understanding of the MS option > > but it might be worth documenting somewhere, perhaps as a comment in > cstdint.hpp? Apparently __int64 does work with /Za, so I've changed boost.config to enable it in that case - it should fix your date/time problems as well. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Regex compilation errors with BCB5
> As suggested by Marco Oman, the problem appears to be caused by overloading > the various operators for the enum type, which happens in match_flags.hpp > (lines 79 to 92). If these are removed for the Borland compiler, then the > conflict goes away, at the cost of a bunch of "Assigning int to ..." > warnings. Presumably, that is the main purpose of these overloads in any > case (to suppress such warnings), so it might be just as well to use a > pragma for this in the Borland case - assuming, of course, that the > generated code is the same. Got it, there is a workaround for vc6 in there already, I've enabled this for Borland as well, regex can now be mixed with . John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: 1.30.0->1.30.2: no more thread support for Linux?
> I was thinking of a view from the point of view of each individual > library. e.g., the shared_ptr docs mention what to define to > turn off thread support on a boost that was configured with thread > support on, but I didn't see a specific explanation of what to define to > turn thread support on without Boost Config. > > >> Boost Config seems to hide those details fairly effectively for developers > >> who don't distribute their code (or distribute Boost along with their > > code). > >> > >> The problem I see is that developers who distribute code that depends on > >> boost can't count on the user's version of Boost being configured in any > >> particular way (or at all - the docs suggest just untarring it as a valid > >> way to use the header-only modules). > > > > There shouldn't really be any difference between the config after just > > extracting the tarball, and after running configure. > > Maybe I'm missing something - when I run boost/libs/config/configure, it > adds #defines to user.hpp. Presumably Boost Config does something similar, > correct? Yes, the default user.hpp does nothing and delegates everything to to the boost.config system, ultimately they should both end up setting the same options allbeit by different means. > If these defines were just for boost implementation details/optimization it > wouldn't concern me, but it seems as though in some cases they change the > way Boost will interact with my program (e.g., shared_ptr and thread safety). Threading support is on when BOOST_HAS_THREADS is defined, and off when it's not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both of these mentioned in the configure generated user.hpp (and in the config docs). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0->1.30.2: no more thread support for Linux?
> IMHO it's not requirement to use -pthread on linux - especially when it's > not documented. I think usage of -D_REENTRANT for compiling and -lpthread > for linking should be enough. Maybe - I don't have a linux box to check on right now - doing a: g++ -dumpspecs | grep thread will tell you what -pthread does on your system. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost.Regex compilation errors with BCB5
> and I don't get an error. Are you using any particular compiler setting?. (I > am just creating a new Console Project in the IDE and then pasting in the > code.) Maybe there is more to this? Make sure that the console app has "Project uses the VCL" checked when you create it. Haven't tried without it... I'm using the 5.6.4 compiler BTW. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0->1.30.2: no more thread support for Linux?
>You mean I can't just run bjam with no options and get the libs built with >thread support? I need to add a command-line option? > >I am updating my RPM package for 1.30.2, and I'd like to make sure this is >correct, and I will forward this to Redhat (they now have a boost rpm). The thread libs will be built with threading support turned on (obviously), other libs will not be built thread safe by default - you could use bjam -sBUILD="multi" but remember that thread safe and non-thread-safe lib builds are very unlikely to be binary compatible (this is true of the C++ std lib as well BTW). We are aware that this is an issue, and there is work going on to provide an install procedure, that will address this by mangling library names. I hope we can provide an official rpm specs file as well, but that may have to wait... John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Regex compilation errors with BCB5
> At the moment, Boost.Regex has an incompatibility with the VCL headers
when
> compiling with Borland C++ 5.5. Simply having
>
> #include
> #include
>
> generates a large number of errors of the type.
>
> [C++ Error] cregex.hpp(91): E2015 Ambiguity between '_fastcall operator
> |(int,const Variant &)' and '|'
>
> I'm afraid that I have yet to track down the precise cause of the errors,
or
> a solution.
I can reproduce this with just:
#include
#include
No boost code necessary :-(
Even worse this reproduces the error as well:
#include
#pragma hdrstop
enum enum_t
{
one = 1,
two = 2
};
int test()
{
int a = one | two; // error
int b = one + two; // error
int c = (int)one & (int)two; // OK
return a & b; // OK
}
which doesn't look good at all...
Oh and the problem is present in Builder 6 as well.
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Regex compiler warnings
> Compilation of Boost.Regex using Borland C++ 5.5 currently gives a bunch of > "previous options and warnings not restored" messages. The culprit is > boost/regex/config/cstring.hpp where the lines Fixes are in cvs now. Thanks for reporting this. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
> see boost::is_POD. And has_trivial_copy has_trivial_assign has_trivial_destruct etc John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: memcpy_copyable<> and memcpy_moveable<> type traits
>> > > Thats my point - you may flag some types as safely moveable and then > > use > > this knowledge in algorithms. User has the responsibility to do the > > decision. > > Extremely dangerous and error prone. I can't even imagine a non-POD type > where flagging it for memcpy_copyable and memcpy_moveable can be right. Can > you give an example ? > > Also, "flagging it" introduces some more complication on the user's part. > How would you propose the user do this ? He needs to take a look at the has_trivial_* traits: has_trivial_assign is roughly equivalent to memcpy_copyable I guess there is no equivalent to memcpy_moveable: but it looks rather dangerous, what state is the original object left in afterwards etc? In any case there is another promising approach to moveable objects proposed for the next standard (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost 1.30.2 thread support issue under cygwin
> From the g++ man pages, -mthreads "Support thread-safe exception handling > on Mingw32" and only defines _MT for Mingw32. Therefore, after threading > support is disabled on line 53 of boost/config/compiler/gcc.hpp, nothing > actually enables it again for a non-Mingw32 cygwin build. Is this the > desired behaviour? (If I removed the check for __CYGWIN__ in gcc.hpp, > everything compiles and the tests seem to run correctly). No it's not desired - boost/config/suffix.hpp checks for _MT and turns threading support on when it finds it, however, when I build the following program with the -mthreads option I see the #error triggered: #ifndef _MT #error oops #endif Looking further into the specs file it seems that _MT is only defined if you use both -mno-cygwin and -mthreads, cygwin itself appears to no longer set any define in multi-threading mode, so I guess we're back to setting BOOST_HAS_THREADS unconditionally for that compiler :-( John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0->1.30.2: no more thread support for Linux?
> One more thing: what exactly can go wrong with 1.30.0 if > -pthread isn't used? Is it boost specific or a general thing > (e.g. issues w/ respect to libstdc++)? A general thing - without this then: Your std lib is not thread safe. Your C lib is not thread safe. g++ will not emit thread safe exception handling code. Thus while for C programs enabling thread support is just a question of linking to the right libraries, for C++ you also need to ensure that the compiler "knows" that you want thread safe code. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: POSIX, gcc, Comeau, Boost.Test, glibc
> > My understanding is that Boost.Config should take care about these issues. > > Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in > > case if there is no support for POSIX interfaces. Could you report the value > > of that flag in case of compilation failures you are expiriencing. > > BOOST_HAS_SIGACTION gets defined to an empty string > for como, "gcc -ansi -U_GNU_SOURCE" and for "icc -D__STRICT_ANSI__". > > Boost.Config uses _POSIX_VERSION to determine wether sigaction() > is available. The presence of _POSIX_VERSION doesn't indicate > wether the POSIX API has actually been enabled. > > If we want to use Boost.Config to take care of this then > Boost.Config also has to check wether POSIX has been enabled. > This would be a very tedious task. glibc uses a plethora of > flags to enable POSIX, other implementations probably will > also add some flags. My gut feeling is that checking for _POSIX_C_SOURCE would probably be the standard conforming way to handle this, but is likely to break on some systems. Could we not just add _POSIX_C_SOURCE=200112 to the test library's requirements? On the other hand, I notice that the requirement to specify this, is only for conforming C applications, nothing is mentioned about other languages (if we're being picky about this). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: libs/config/configure screwed up in DOS format in1.30.1
> Fixed now. I wonder if it really ought to be checked in as binary so > this doesn't happen? Personally I think that would cause even more problems (for me at least), note that there are plenty of other files that need the \r's stripping in order for them to work on Unix, in fact some pre-processors (some versions of gcc for example) can't even cope with \r's in header files (if there's a \r between a \ and a \n). The only complete solution is to make sure that all text files have their \r's stripped before producing the tar.gz file. [ footnote - one way to do this is with the new bcp tool - something like: bcp --boost=boost-path --unix-lines --cvs "." destination-path will produce a clean copy of all of the boost cvs with \r's stripped from text files - we could probably even write a Jamfile that would automate the release process come to that. -- end footnote ] John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
> So John, would you be interested in trying to get this sorted out for > the next release? As I have said, I currenly only use BCB, and so can't > offer much help for other compilers. Yep. > Would it be best to have something like a boost/config/preinclude.hpp > file which includes a compiler specific pre-include and then a > boost/config/postinclude.hpp for afters? I'm wondering how complicated to make this - one option would be to do something a little like the config system does and have: #ifdef BOOST_ABI_INCLUDE #include BOOST_ABI_PREFIX #endif // code... #ifdef BOOST_ABI_INCLUDE #include BOOST_ABI_SUFFIX #endif which would let users define their own prefix/suffix headers if they want to. > I've created ones for BCB which I use here, that simply do > > #praga nopushoptwarn > #pragma option push -a8 -b -Vx -Ve -pc -w-8027 > > for pre and > > #pragma nopushoptwarn > #pragma option pop > > for post (probably don't need the nopushoptwarn in postinclude though). Yep. > These options are from regex. I may be a better idea not to include > disabling warnings in the default boost options? Some of those warnings can get pretty pesky at times > And also, It might be > worth adding -Vg- to disable codeguard for boost, unless the new build > system will build CodeGuard libraries as well as non-cg enabled libraries. Does adding codeguard info break the ABI? I didn't think it did so (there are no codeguard protected std libraries for example), and I mix and match codeguard and non-codeguard code all the time without any apparent issues... Here's what the STLPort that Borland ship is using: # pragma option push -Vx- -Ve- -a8 -b -pc -w-inl -w-aus -w-sig -w-8062 -w-8041 -w-8008 -w-80 12 -w-8027 -w-8057 -w-8091 -w-8092 -w-8066 > These options also should be the same as the default jam options for the > compiler also. Yes, that should be the case now I think. I'm slightly tied up this week, but I'll try and add something to regex and see how it looks. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MSVC7.1 bug not yet fixed
> I've just downloaded 1.30.1 and the bug I reported a while ago > > http://aspn.activestate.com/ASPN/Mail/Message/boost/1622190 > (Missing BOOST_HAS_THREADS on MSVC with /Za and /MT) > > is still there. I don't know config at all but if nobody else has time I'll > try to submit a patch (I believe it'd be less than half an hour for someone > knowing config). Just let me know. I'm pretty sure that I fixed that in the main branch, I'm not sure what changes would need to be merged into the release branch though, I'll try and look into it. Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Release of 1.30.2 imminent
> NOTICE: > > If I don't hear of any new problems with the RC_1_30_0 branch I'm > going to release 1.30.2 tomorrow (Wed) evening or Thursday morning. Then be aware that I've just merged a few select config changes into the RC_1_30_0 branch to fix the linux regressions you reported (and bring a few other config headers up to date to cope with new compiler/platform releases etc). If this can make into the release it would be a good thing IMO. Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
> > The link failures for the format tests and the ios_state_test likely > > isn't an indication of a problem in the respective libraries. > > > I was in holidays, sorry I did not respond earlier. > > I gave a look at the regression reports, and indeed the pthread linking > problem must be rather unrelated to the code itself in format, which > doesnt call any thread function. > > I suspect it's because the tests are linked statically (because of wchar > issues whith some compiler), and it triggers something. > > Does anyone have a clue on what to do to fix this ? Very likely you are using something like shared_ptr or regex that make themselves thread safe when BOOST_HAS_THREADS is defined, if this is the case then adding either: BOOST_DISABLE_THREADS=1 or multi To the build requirements of the test will fix that. If you don't depend on any boost lib that uses threads, then I would guess that the culprit would be the std lib used (probably synchronises it's iostream code somewhere), in which case you're going to need to use the second option above. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost/math octonion/quaternion failures?
> Current GCC and Intel compilers don't appear to allow using declarations
at
> function scope, according to a bug report.
Also Borland's compiler crashes if there are using declarations inside a
function that will be expanded inline if memory serves.
> Is there any reason not to just move the using declarations to namespace
> scope?
>
> Answering my own queston, I think prefer the solution used in other boost
> code where calls to say std::abs are explicitly qualified, and ifdef
> BOOST_NO_STDC_NAMESPACE then namespace std { using ::abs; } is supplied.
>
> What are the pros and cons of the different approaches?
Personally I prefer, namespace std { using ::abs; } approach, however this
can cause overload ambiguities on vc6 (but this is legacy support now
right?), likewise mixing the two approaches with the same function name
messes up vc6 (overload ambiguities again).
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release of 1.30.2 imminent
> Just out of curiosity. What the heck is librt? It contains the POSIX realtime feature set (used by boost.threads, and hence tested by boost.config for timeouts and thread priorities and the like). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Metaprogramming question
I'm trying to remember, did someone around here come up with some code that can tell at compiler time whether an object has a specific member or not, I can do it for operators, but not a member typedef (which is what I want)... Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
> I'm not sure how to proceed with this so if there is anything I can do > in the meantime, let me know. Feel free to e-mail me off the list. ABI prefix and suffix headers are now in cvs, as is boost/config/auto_link.hpp for selecting link libraries - for now refer to the header for usage, I'll add this to the config docs in due course, but lets get it running through the regression tests first... John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Metaprogramming question
> See boost/mpl/aux_/has_xxx.hpp. Example usage in boost/detail/iterator.hpp. Thanks, I'll look into it. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Release date? (was the boost::signal sample crashes)
> I'm not sure how to proceed with this so if there is anything I can do > in the meantime, let me know. Feel free to e-mail me off the list. OK, I've got this working pretty well with regex - but as it entails changes to boost.config I'm not sure if I should make the changes now or wait until after the next release - Beman I guess we have a couple of weeks still to run yes? [ Footnote - on second thoughts it just means moving code that's in boost.regex now into the central config system it's not new code - so maybe I should go ahead ] John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] config, workaround of bug in variant's compiler bugworkaround on gcc
> I think problem is with BOOST_EXPLICIT_TEMPLATE_TYPE(void) > Simply removing that workaround macro from forced_return works for me as a > dirty workaround. > > The question is, why BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS on gcc > 3.2.x? config/compiler/gcc.hpp comments about some unspecified bug, while > documentation says only about VC6. The same bug in both compilers? Strange. Kind of - the extended test case is in libs/config/test/boost_no_exp_func_tem_arg.cxx > Diving more in config, little of compiler specific code pollutes > config/suffix.hpp, shouldnt it go to compiler specific config instead? Everything in suffix.hpp is generic macro workarounds - it's not dependent upon specific compilers just whether the appropriate macro is defined. I think you are going to have to use a dirty workaround here: check for gcc before using BOOST_EXPLICIT_TEMPLATE_TYPE(void) in this particular case. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [regex] Escaping a search string?
>Given that I have a string 's' from somewhere, I'd like to create a
>regular expression where some part must match that string. The problem
>is, the 's' could contain characters that have a special meaning in
>regular expressions. Is there some support function that can provide an
>escaped version of 's'? Something that transforms "my.*string" into
>"my\.\*string"? If there isn't, would it be possible/easy to provide one?
Good question, no there isn't, but how about:
std::string escape_regex(const std::string& s)
{
static const std::regex e("[\\[\\]$\\^|.+*?(){}]");
return regex_merge(s, e, "$&");
}
Just off the top of my head and untried
I'll try and think up something more general that works with all the flag
settings though...
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ABI fixing and prefix/suffix headers (was the boost::signal sample crashes)
> The main problem with shared_ptr 1.30.x and below is that the single- and > multithreaded versions are incompatible. The CVS version is now binary > compatible on Windows, so 1.31 will "work" across different threading > models; still, the correct default for Borland should probably be to do a > multithreaded build. > > By the way, this can't be fixed with prefix/suffix headers. Agreed, no-one is trying to fix that - threaded and non-threaded builds use different run time libraries for both the Microsoft and Borland compilers - mixing code that was built with threading turned on with code where it is turned off will *always* cause ODR violations, even if you're not using boost :-) > > but by default the libraries are all built using > > the default compiler option for the tool. The inlined (header-only) > > library are only tested against that default set, so why not enforce > > that default set for all boost libraries? If an individual library > > author then wants to enforce another set (different alignment or > > something) for optimisation purposes, then let then over-ride the > > defaults, > > But I don't want to enforce a set. I want (for example) shared_ptr to use > whatever set the user has specified and not to override his settings. Which causes no end of issues for libraries with separate source, unless we abandon having a build system altogether and just tell people to "build everything yourself". To put this in perspective for C++ Builder the following options effect the ABI: -b (on or off - effect emum sizes) -Vx (on or off - empty members) -Ve (on or off - empty base classes) -aX (alignment - 5 options). -pX (Calling convention - 4 options) -Vmx (member pointer size and layout - 5 options) -VC (on or off, changes name mangling) -Vl (on or off, changes struct layout). In addition, there are a whole bunch of separate runtime libraries - 4 C libraries, plus 2 STLPort versions on top (so 8 combinations). And that's not counting the optional diagnostic libraries or the optional use of Rogue Waves STL. So assuming we build libraries for the 8 runtime variants we can't control, that still leaves 2*2*2*5*4*5*2*2=3200!!! ABI options for each runtime variant. Seriously we need to get a handle on this where we can - and please don't forget users can always turn this off if they want to handle the ABI themselves. One final point - there was a reason that I moved regex to use automatic library selection and ABI fixing - without it I was getting a tonne of support requests along the lines of "Your library doesn't work, it just crashes when I call anything", which almost always turned out to be caused by ODR violations (either the user had changed an ABI option, or had linked to the wrong runtime-library-build variant), these basically stopped overnight once I modified my code to stop those (this was all in pre-boost days BTW). Convinced yet? John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [regex] Escaping a search string?
> Front end localization could change this also, I believe. For instance if
a
> dll or message catalog substitutes '!' for '$' wouldn't I need to escape
'!'
> instead of '$' in order to use '!' as a literal in an expression ?
Yes, I was afraid you would bring that up :-)
> In this regard it would be helpful if the end-user could obtain back at
> run-time the substitutions that are made due to localization. I didn't see
> this as a function of the regex_traits class reference but maybe it is
> there.
No it's not - the internal data simply isn't structured in a way that allows
that kind of query - however as you yourself said already - the end user
*knows* what the special characters are (if they have been changed).
The worst case scenario: the user has substituted a traits class that uses
different characters for the \ x { and } regular characters, so that escape
sequences like: \x{32} don't work anymore.
John
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
> Does regex address the issue of alignment and calling convention etc and > other options (in BCB, treat enums as ints is a good one to screw up > libraries) by wrapping the headers in push/pop option statements? Yes: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] C++ Builder 6 and Boost Generic Graph Library
> awhile ago I tried to compile this simple program:
>
> #include
>
> int main (){
>
>return 0;
> }
>
>
> and Borland C++ Builder 6 refuse to compile.
> I have track the problem and it seemed that Borland C++ builder has
problem with template partial specialization with constant. The program
below also refuse to compile
Yep, we even have a macro for it: BOOST_NO_CV_SPECIALIZATIONS, evidently
boost.graph doesn't use it.
John.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Preparing 1.30.1 Release
>I've applied the first two; I'm not comfortable applying the regex >patches myself; it takes someone who knows the library to verify that >they're OK. John can do it, though, as far as I'm concerned. done, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and gcc
>I've just written the following. It (correctly) fails for MSVC 6.5 and gcc 3.2 for >cygwin, >but I cannot test it in a conforming compiler. I had to modify it a little to make it conforming code, but it's now in cvs. Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preparing 1.30.1 Release
> I have put a diff of the changes between Version_1_30_0 and RC_1_30_0 > at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be > the changes that go into the Boost 1.30.1 release. Will the > authors/maintainers of the following libraries please post a brief > summary of the fixes that were applied? > > smart_ptr > lexical_cast > function > lambda > MPL > type_traits The one type_traits change is hardly worth mentioning - it just updates the EDG version number for which a specific fix is required (is_base_and_derived fix for EDG versions prior to 243). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS and gcc
>Currently, BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS >is not defined for gcc. However, the following URL in the gcc bug >database > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7676 > >leads me to believe that the macro should be set on for the appropriate >versions of gcc. Matter of fact, I run with this problem myself and it >can be >workedaround with techniques similar to those employed for MSVC. See >for instance definitions of get() and workaround_holder in > >boost/tuple/detail/tuple_basic_no_partial_spec.hpp > Thanks, The issue with gcc seems to be a little more specific than we normally set the macro for, but I don't see any reason why we shouldn't set it. Am I right in thinking that this is specific to gcc 3.1 and 3.2? Also do you have a test case that can be added to the appropriate config test? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Today's compiler checks
> > don't know how to make config_info/regex_config_info.cpp > > don't know how to make concepts/concept_check.cpp > > don't know how to make concepts/wide_concept_check.cpp > > Any ideas how this got broken? You need to do a cvs update with the -d option to get the new directories I've added... John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: stale regex regression test results
> I don't see that the library builds OK for cwpro8. Strangely, Beman's test > results are fine. Beman's using a "special" fixed version of CW8 which presumably will become an official fix from MW at some point (it fixes the internal compiler error that otherwise occurs). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Recursive_mutex bug?
> I caught a memory leak (24 bytes) when using recursive_mutex class in > Solaris 8. > This class initializes a pthread_mutexattr attribute but never destroys it > thus > leaving the leak. > We use tons of the recursive mutexes in our huge app and that leak leads > to significant memory loss. That does look like a bug... Bill? John Maddock. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost Bibliography?
> Attached is a quick draft of a "Boost Bibliography" page. Each entry is > bookmarked so it can be referenced directly from other web pages. > > Comments? A good idea, can you add to that the article in libs/type_traits/c++_type_traits.htm which was in the October 2000 issue of Dr Dobb's Journal, I don't have an issue number to hand though. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] problems with config for intel-7.1 on Linux
> I found a problem with the intel configuration for Linux. > For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T > gets defined although the compiler has an intrinsic wchar_t. > > Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is > defined on Linux. __WCHAR_TYPE__ is defined to int. Never- > theless, wchar_t and int are distinct types. Looking at the boost regression test results, it seems that Intel on linux defines _WCHAR_T (which is what the EDG front-end documentation specifies for wchar_t support), so I used that as the test - should be in cvs now - can you check that it does the right thing? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::regex opeartor+= bug report
> I believe that consistent use of std::advance would solve the problem. > Or would this change be so costly that I ought to use vector or deque? > Unfortunately, doing so would cause me other problems such as iterator > invalidation. :-/ Should be fixed in cvs now. Thanks for the report, John Maddock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regex documentation bug
> http://www.boost.org/libs/regex/template_class_ref.htm#partial_matches > > There are two examples given. Though the examples are different, in > both cases, the "example" links to a complete implementation of the > first example. This likely was a cut-and-paste error. Thanks, fixed in cvs, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Borland-tools.jam
Dave, Is there any reason for including the option in the Borland toolset: this is set to on by default in features jam, and then selectively turned off for , this means that if I inherit a toolset from borland-tools.jam (I want multiple toolsets to test different Borland versions) then it gets turned on again in the inherited toolset and nothing compiles anymore. BTW this option should *not* be turned on by default - the effect of -WU is to make the linker look for a Unicode entrypoint: int wmain(int argc, wchar_t** argv); and since no boost code uses such an entry point this is obviously a mistake. Also since only borland-tools.jam provides this option, I think we can just remove all reference to it (or at the very least rename it to something more suitable and turn it off by default in features.jam). Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Experimental audience-targeted regression results
> Well, we didn't do anything special to mis-configure it ;), besides > choosing MSVC 6 compatibility mode (during the setup, as opposite to > MSVC 7.0 one). Any ideas what's the right way to fix that? The problem is that there is no way for the config system to tell how your Intel compiler is set up, and which conformance options have been set (because Intel doesn't define any macros to indicate which options have been enabled/disabled), so... you basically have to set up boost.config manually to match your compiler options. On unix platforms running the configure script would do that, but that's a little tricky on win32 :-( John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Managing boost licenses
I've modified the bcp tool to add a --report mode which will report all the licenses in effect for a set of boost files, for example: bcp --report scoped_ptr.hpp scoped-ptr-report.html will report: * All the licences in effect. * All the authors using each license. * All the copyright holders using each license. * Any files with no recognized copyright holder or license. * All the authors and the files they are responsible for. * The dependency information for each file found (which is to say the reason for including each file as a dependency). There are a couple of examples of the program output here: http://www.regex.fsnet.co.uk/scoped_ptr.html http://www.regex.fsnet.co.uk/regex.html The source is in cvs now, or available from here: http://www.regex.fsnet.co.uk/bcp.zip as is a win32 executable: http://www.regex.fsnet.co.uk/bcp_win32.zip If the folks that have been having trouble with boost licenses could take a look and see if this helps smooth their problems out I would appreciate it. Regards, John Maddock. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Trouble building latest CVS (Intel 7.1 and VC7)
> I just checked out the latest CVS and I am having trouble building it. > My environment is: > > - Windows XP > - Intel Version 7.1, Build 20030402Z > - Visual C++ 7.0 > > All my environment variables are setup correctly (INCLUDE, LIB, MSVCDIR, > INTEL_PATH, PATH). The command line I am using with bjam is: > > bjam -sTOOLS=intel-win32 -sINTEL_BASE_MSVC_TOOLSET=vc7 > -sPYTHON_ROOT=C:\Python > > Looking at the command line that bjam is executing to compile the files, > it seems to be all right (paths to header files, the correct compiler, etc). > This error happens in a lot of files, besides numeric.cpp. I let it try > to compile more 6 files before I gave up, since something is obviously > wrong. If needed, I can post the list of files that are giving this error. > > Does anybody know what am I doing wrong? It looks like the config system is assuming that wchar_t is a native type, but that it isn't being turned on in the compiler - perhaps a boost.build expert can jump in here John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem problem
> Comments? Sounds reasonably to me, but I admit that I don't really understand POSIX filesystems. I guess what I really wanted was something that would be equivalent to "rm -f file", remember that we already have the equivalent to "rm -r path". Of course I don't know how one would implement that :-) John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Filesystem problem
Beman, I'm having a problem with the filesystem lib and read only files - basically if I copy a read only file then the result is read only, fair enough. However if I then try and overwrite that file with another file copy it throws because of the read only status of the target file, still fair enough. So then I try and remove the target file with remove first, but that throws as well because the file "not accessible" i.e. read only! So - how can I get rid of a read only file? At present it seems to be impossible? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Comments on the "bcp" tool
> Except for one problem. If the second run of "bcp" selects less files than > the first, and you only ovewrite files, not clean up the entire directory, > the number of files will not be reduced. Uncessasary ones will just lay in > the directory. Good point, however I've sometimes used it that way deliberately (if I've forgotten something), even so it has a problem with overwriting read only files (boost.filesystem won't let you do that). > :-( > I start to understand why Gennadiy Rozental was saying that dependency from > program_options to function is a bit too much --- don't feel all that good > about adding 2Megs just for command line parsing. Of course, this only > matters when packaging library separately. Agreed - it's not quite 2Megs though: 1.39Mb on disk, and zips up to 235K, even so... John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Comments on the "bcp" tool
> Anyone got a Win32 exe of bcp that they could email me? Eventually there probably will be one to download, but it's still developing quite rapidly at present, I'll mail you a binary build though. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comments on the "bcp" tool
> However, it seems to be confused by the preprocessor library. Since the > includes sometime have the form: > >#include BOOST_PP_ITERATE() > > the 'bcp' tool does not find them. For example, > "boost/preprocessor/iteration/detail/iter directory is needed by > boost/function.hpp but is not included. I've added some explicit dependencies > with the attached patch --- can it be applied? Thanks will fix - I've got a bunch of other really exciting changes comming (licence scanning) - so the patch may have to wait a few days. > Another note is on usability. Say I create directory "po" and find that some > files are missing. I tweak bcp source and try again. But attempt to override > files fail. I remove "po" directory. But then "bcp" says the destination does > not exist. It's a bit inconvenient --- maybe destination directory should be > created if it does not exist. Or maybe, there should be --overwrite switch, > which would simply clean up destination before doing copies. Or maybe it should just go ahead and overwrite, should be easy to fix. > And the last note: > >bcp --boost=/home/ghost/Work/boost boost/function/function1.hpp function1 > > creates a tree of 1975 kbytes. Hmm, never though there's that many > dependencies... Hmm, it seems to pull in more of type_traits than I would have expected, and that pulls in part of mpl, and then a whole load of the preprocessor library. I don't think any given compiler will include half of that, but which half depends upon which compiler... John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Comments on the "bcp" tool
> > > However, it seems to be confused by the preprocessor library. > > > Since the > > > includes sometime have the form: > > > > > >#include BOOST_PP_ITERATE() > > > > > > the 'bcp' tool does not find them. For example, > > > "boost/preprocessor/iteration/detail/iter directory is needed by > > > boost/function.hpp but is not included. > > > > Is it overkill to use Wave for this? It would solve the > > mentioned problem by correctly preprocessing the inspected sources. > > Here is the (main) code, which uses Wave to output the file names of all > successfully opened include files (this needs some filtering to avoid > double output of the same file): Interesting, the thing is I need the code to find all possible dependencies, so that if we have: #if SOME_MACRO #include #else #include #endif then it should find *both* headers. Which I don't think a preprocessor will do? In any case I'm already using regex for other purposes, and boost::function seems to be the only problematic case so far... John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] problems with config for intel-7.1 on Linux
> I found a problem with the intel configuration for Linux. > For that compiler the macro BOOST_NO_INTRINSIC_WCHAR_T > gets defined although the compiler has an intrinsic wchar_t. > > Neither _WCHAR_T_DEFINED nor _NATIVE_WCHAR_T_DEFINED is > defined on Linux. __WCHAR_TYPE__ is defined to int. Never- > theless, wchar_t and int are distinct types. > > The attached patch to intel.hpp fixes this problem for > intel 7.1 on Linux. However, I'm not sure wether the change > is acceptable in this form. I'm also not sure wether > it causes problems with version 7.0 of the compiler. We have endless problems with this compiler: basically you can turn wchar_t support on or off on the command line, but there is no way to detect which option is used in code. Is wchar_t supported by default with Intel 7.1 on linux? If yes then I guess we should change Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Missing copyright on pending files
A large number of files in the boost/pending directory have no licence or copyright information: boost/pending/container_traits.hpp boost/pending/cstddef.hpp boost/pending/detail/disjoint_sets.hpp boost/pending/detail/property.hpp boost/pending/fenced_priority_queue.hpp boost/pending/fibonacci_heap.hpp boost/pending/iterator_adaptors.hpp boost/pending/iterator_tests.hpp boost/pending/property.hpp boost/pending/queue.hpp boost/pending/stringtok.hpp Any chance of the authors concerned fixing these? Thanks, John Maddock. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] no licence or copyright in boost/any.hpp
> The license is at the end. Duh!, apologies, and thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] No copyright or licenceinboost/date_time/microsec_time_clock.hpp
> Done. Thanks! John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Licence proliferation (Graph library)
> I would not mind to change my copyrights to use different wording --- either > the one from function library or the "standard" one. The only problem is > that > >boost/graph/transitive_closure.hpp > > is generated from > >libs/graph/doc/transitive_closure.w > > and only Jeremy knows how. > > And related note: probably the text of "standard" license should be placed > somewhere and you could suggest that "standard" license to authors which > used something different, instead for suggesting to use any license > currently used? Of course, it must be settled what "standard" is. I think I probably jumped the gun a little here: there's going to some discussion around here real soon now about a "standard" boost licence for new code. At present I've been trying to flag up files that have licences that are *almost* completely identical to common ones used elsewhere in boost, but which are just different enough to be separate legal entities (well probably anyway). If you want to either hold off any changes for a while that's completely OK; your existing licence is perfectly boost compatible, it's just um, well "unique". I'll also try and post a rundown of what licences are actually in use right now, one I've got my code a bit more complete. Regards, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Licence Proliferation (background and explanation)
I've been working on an automated tool to extract and present a list of boost licences in effect for a given boost library (or collection of files). Although the tool is working well, it's throwing up a lot of licences that are used by just one or two files, and which are only very subtly different from licences in use elsewhere in boost (by different I mean that they use different words, not just formatting, or punctuation). My guess is that most of these are accidental changes, and if that is the case then it would make things a whole lot easier if they could be changed to match other existing boost licences - from a lawyers point of view, why should a commercial body wanting to use Boost have to review 50 almost but not quite identical licences, when just two or three variants would do? Thoughts, comments? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Licence proliferation (Graph library)
The following two files: boost/graph/transitive_closure.hpp boost/graph/vector_as_graph.hpp Use a licence that is different from any other file in boost (the closest approximation appears to be that used by the lambda and function libraries). Is it possible to avoid unnecessary licence proliferation, and reissue these files under another licence (one that is already in use elsewhere)? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] licence proliferation (filesystem and variant libraries)
The following four files: boost/filesystem/exception.hpp boost/filesystem/operations.hpp boost/variant/detail/move.hpp libs/filesystem/src/exception.cpp Use a licence that is different from any other file in boost (the closest approximation appears to be the good old SGI licence). Is it possible to avoid unnecessary licence proliferation, and reissue these files under another licence (one that is already in use elsewhere)? Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] No copyright or licence inboost/date_time/microsec_time_clock.hpp
Again subject says it all, please fix and apply an existing boost licence if possible Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_STATIC_WARNING ?
> I find BOOST_STATIC_ASSERT(...) extremely useful. > > I would also find BOOST_STATIC_WARNING(...) extremely useful. > > I've looked in boost and now found such a thing. Am I missing > something? Is there something equivalent? Can such a thing > be added? > > I envision an implementation of BOOST_STATIC_WARNING that > would display a compile time warning message but permit > compilition to successfully complete. Its usage would be > to notify library users of legal but suspect library usage. I agree on it's usefulness, but there's no real way to implement it IMO, John Maddock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] no licence or copyright in boost/any.hpp
Subject says it all, as it stands boost/any.hpp isn't even open source, please reuse an existing boost licence if possible, thanks, John Maddock. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] patch to select_compiler.hpp for Comeau C++
> the attached patch changes the order in which compilers are checked in > config/select_compiler.hpp. This is required to detect Comeau C++ > with gcc backend correctly. > > ok to apply? Please go ahead, Thanks, John Maddock ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] VC7/Threads Warnings
> This discussion was a long time ago, but I didn't get the end of it. > As building the thread library I get a lot of warnings I would like > to remove them somehow (I'm using the 1.30 release version). > > So, what would you suggest? Using pragma's is safe enough? > If yes, where is the best place to add this ? Just for the record, the list of warnings from vc7.1 is rather long (see below), it would be nice if we could fix these, John. -- Build started: Project: boost_thread, Configuration: Debug Win32 -- Compiling... xtime.cpp tss.cpp c:\data\boost\develop\boost\boost\thread\tss.hpp(33) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::detail::tss' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\tss.hpp(32) : see declaration of 'boost::detail::tss' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(35) : warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' threadmon.cpp thread.cpp c:\data\boost\develop\boost\boost\thread\exceptions.hpp(29) : warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(14) : see declaration of 'std::logic_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(28) : see declaration of 'boost::lock_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(35) : warning C4275: non dll-interface class 'std::runtime_error' used as base for dll-interface class 'boost::thread_resource_error' c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\stdexcept(136) : see declaration of 'std::runtime_error' c:\data\boost\develop\boost\boost\thread\exceptions.hpp(34) : see declaration of 'boost::thread_resource_error' c:\data\boost\develop\boost\boost\thread\mutex.hpp(37) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::mutex' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\mutex.hpp(36) : see declaration of 'boost::mutex' c:\data\boost\develop\boost\boost\thread\mutex.hpp(75) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::try_mutex' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\mutex.hpp(74) : see declaration of 'boost::try_mutex' c:\data\boost\develop\boost\boost\thread\mutex.hpp(115) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::timed_mutex' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\mutex.hpp(114) : see declaration of 'boost::timed_mutex' c:\data\boost\develop\boost\boost\thread\thread.hpp(39) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\thread.hpp(38) : see declaration of 'boost::thread' c:\data\boost\develop\boost\boost\thread\thread.hpp(68) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::thread_group' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\boost\thread\thread.hpp(67) : see declaration of 'boost::thread_group' c:\data\boost\develop\boost\boost\thread\thread.hpp(79) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ] c:\data\boost\develop\boost\boost\thread\condition.hpp(38) : warning C4275: non dll-interface class 'boost::noncopyable' used as base for dll-interface class 'boost::detail::condition_impl' c:\data\boost\develop\boost\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable' c:\data\boost\develop\boost\b
[boost] filesystem::path and ./
Beman, While putting together bcp (see managing boost dependencies thread), I found that some of the boost html files contain relative URL's of that begin with "./". In order to get filesystem::path to accept these, I had to manually strip the ./ off first, so basically this is a plea to let the portable syntax recognise this, as there does seem to be a genuine need. Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Managing boost dependencies
> I don't think it needs to. We review libraries, but traditionally > tools are just checked in if they seem useful or are known to be > needed. This one is. OK I'll check it in, thanks. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Managing boost dependencies
> Do realize that people are different and that my programming preference is > almost always to use a GUI interface over command lines as long as the GUI > interface lets me do what I want to accomplish. Of course I write actual > code in a fancy editor just like everyone else . I will dig into the .pdf > version of the link first, although my initial reaction to CVS was not > joyful, but I am sure it can not be that arcane to use. Check out TortoiseCVS: it integrates with the windows shell and is pretty much wonderful and easy to use. It does lack the power features of WinCVS or the command line, but that can sometimes be a good thing. One caveat however: I've never tried to use it in pserver (read only access) mode. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Managing boost dependencies
> Many thx for doing this, I'm sure it will come in handy. > > I've tried this out for date_time and noticed a couple things: > > 1) date_time includes tokenizer.hpp which includes token_iterator.hpp > which includes token_functions.hpp. Unfortunately, token_functions.hpp > is not copied so my compile failed. Ah, I'm not sure whose error this is: the header uses: #include Note the lack of whitespace between the include and the <, I'm not sure if this is legal or not, but whatever I can change the regexes I'm scanning with to make allowance for that. > 2) When I copied the 'build' library the boost-build.jam file and Jamrules > files in boost root directory were not copied so bjam commands complained. > > Seems like these last 2 can't be determined because there isn't any > direct include... I've got a list of "special cases" for just that, I was only using this for boost/config.hpp dependencies, but I can soon add a few more. Thanks for the feedback, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] alternative configuration technique
> I found that boost has very powerful configuration system > (boost/config.hpp and around...) > but why use macros? > there is another solution described here, let discuss it... > may be there are some troubles, invisible for me, that prevent from using > this technique > in libraries like boost? I think that there are two problems: 1) Your scheme requires that all possible implementations can be parsed by the compiler - that won't be true for macros describing defects. 2) Your scheme can't cope with optional features (long long or ). Oh, and macros are probably simpler, if ugly. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost header and library dependency tables
> I think it's a good idea. But I have a few comments. > > First, it only handles headers that are directly under 'boost/'. However > some people have tried not to pollute the root directory and have put > their libraries in sub-directories. For example, the Graph library, uBlas, > the Interval library, the mathematical libraries, and so on. And your > script is unfortunately forgetting them. I know, I just wasn't sure which needed including. > Second, the links at the top of the pages don't work with all browsers > since the anchors are defined in a non-standard way. It shouldn't be name=#boostaligned_storagehpp> but (no > sharp sign). With some quotes, it would be even better, but it's another > problem. OK, that's an error in the shell script I used, easy enough to hack around > Finally, what are "library dependencies"? Sorry if it's a dumb question. > But by looking at the results, I don't get the meaning of it. It's everything that's needed by the complete library - by it's test and example programs etc as well as the headers - for most libraries this means that the Boost.test source will be listed as a dependency for example. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost header and library dependency tables
A while ago Beman produced header dependency tables, unfortunately these began to get rather complicated and so were dropped, I've placed some alternative tables here: Boost header dependencies: http://www.regex.fsnet.co.uk/header_dependencies.html Boost library dependencies: http://www.regex.fsnet.co.uk/library_dependencies.html Whether these are actually any better than what we had before is questionable, but the information might prove useful to some. BTW these tables are produced using bcp in list mode (see separate thread). Regards, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Managing boost dependencies
Folks, I've put together a small tool for managing boost dependencies called bcp (for boost copy). The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application. Examples: ~~~ bcp scoped_ptr /foo Copies boost/scoped_ptr.hpp and dependencies to /foo. bcp boost/regex.hpp /foo Copies boost/regex.hpp and all dependencies including the regex source code (in libs/regex/src) and build files (in libs/regex/build) to /foo. Does not copy the regex documentation, test, or example code. bcp regex /foo Copies the full regex lib (in libs/regex) including dependencies (such as the boost.test source required by the regex test programs) to /foo. bcp regex config build /foo Copies the full regex lib (in libs/regex) plus the config lib (libs/config) and the build system (tools/build) to /foo including all the dependencies. Syntax: ~ bcp --list [options] module-list Outputs a list of all the files in module-list including dependencies. bcp [options] module-list output-path Copies all the files found in module-list to output-path Options: ~~ --boost=path Sets the location of the boost tree to path. --scan Treats the module list as a list of (probably non-boost) files to scan for boost dependencies, the files listed in the module list are not copied (or listed), only the boost files upon which they depend. --cvs Only copy files under cvs version control. --unix-lines Make sure that all copied files use Unix style line endings. module-list: When the --scan option is not used then a list of boost files or library names to copy, this can be: 1.. The name of a tool: for example "build" will find "tools/build". 2.. The name of a library: for example "regex". 3.. The title of a header: for example "scoped_ptr" will find "boost/scoped_ptr.hpp". 4.. The name of a header: for example "scoped_ptr.hpp" will find "boost/scoped_ptr.hpp". 5.. The name of a file: for example "boost/regex.hpp". When the --scan option is used, then a list of (probably non-boost) files to scan for boost dependencies, the files in the module list are not therefore copied/listed. output-path: The path to which files will be copied (this path must exist). Dependencies File dependencies are found as follows: C++ source files are scanned for #includes, all #includes present in the boost source tree will then be scanned for their dependencies and so on. C++ source files are associated with the name of a library, if that library has source code (and possibly build data), then include that source in the dependencies. C++ source files are checked for dependencies on Boost.test (for example to see if they use cpp_main as an entry point). HTML files are scanned for immediate dependencies (images and style sheets, but not links). ~ As usual comments etc are most welcome, also should a utility/tool such as this go through the review process, before eventually living under tools/bcp? The source is available from: www.regex.fsnet.co.uk/bcp.zip This requires the latest boost cvs source to build, so there is also a file containing bcp's dependencies (obviously produced using bcp!): www.regex.fsnet.co.uk/bcp_deps.zip Regards, John Maddock. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Need two new configuration macros
> Should I > explicitly ban copying in my subclass? On second thoughts you can make your stream buffer class copyable if you want - but the copy constructor must call the default constructor of the base class and then explicitly set up the buffer position information in it's body, IMO this is what you would need to do anyway (depending upon how you copy your buffer). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Need two new configuration macros
> Actually, the problem I have is that GCC extended the copying ban to > std::basic_streambuf<>, even though DR 50 only mentions std::ios_base. > I know that copying stream bases or stream buffers are probably bad > ideas, but I didn't feel comfortable leaving copy semantics out of my > subclass's description, especially since I knew the default copy > semantics would be wrong. Should I just take the copying code out and > hope that no one will try copying? (Remember that copying can be > attempted, with unknown results, on compilers without DR 50.) Should I > explicitly ban copying in my subclass? Personally I would say "yes", is there a good reason for copying stream buffers (I can't think of one)? Looks like a grey area of the standard to me, I don't think that basic_streambuf was supposed to be copyable, but you never know, I'll check on the std-lib reflector. > Even if I add explicit non-copying, that is only necessary only if > stream-buffer copying wasn't already banned in std::basic_streambuf. I > would still need a macro to know when to apply my own copying ban. > (Since GCC added the ban on stream-buffer copying on its own, it's not > covered by DR 50. So I can't expect every compiler to eventually do > that change too.) If you add a private copy constructor then that will always work, no matter what the base class does. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Need two new configuration macros
> I see the need for two new configuration macros. The need popped up > when I was trying to add a copy constructor to a stream buffer template > class (for completeness) but GCC blocked it. > > The std::basic_streambuf<> class template and the std::ios_base class > don't mention any copying semantics in the standard. This means that > they automatically get a copy constructor. However, DR 50 suggests > that std::ios_base shouldn't be copyable. (I think the reason was > unclear semantics, and that all its derived types are non-copyable.) > Recent versions of GCC block copying in ios_base, and they did the same > to basic_streambuf. (The latter was a side-effect; if everything else > was non-copyable, why bother with copyable stream buffers.) > > So now, we need macros to detect environments that implement DR 50. We > need two macros because only ios_base is directly involved, the > treatment of basic_streambuf is an optional bonus. From someone > involved on GCC, he _thinks_ that the change happened in GCC 3.1, but > may have happened earlier. > > How would we express this macro? Right now, I'm blocking my problem > code with > > #if !defined(__GNUC__) || (__GNUC__ < 3) || ((__GNUC__ == 3) && > (__GNUC_MINOR__ < 1)) > > Any GCC experts here could correct, either in form, or the exact > version the change happened. We also need to know if any other > compilers have added this change. Hold on a minute: DR50 makes it clear that this was an oversight - you should *never ever* try to copy a stream object (or base class) - libraries that don't explicitly implement DR50 are still likely to be non-copyable (or at least invoke inconsistent or undefined behaviour) even if the copy constructor isn't explicitly private. In short you should always assume that DR50 is in effect and that the copy constructor for ios_base is either private or else not capable of being created. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MSVC 6 build problem
> I am a newbie to boost, and I don't know if this issue has been addressed. > > I am trying to build the boost libraries on a Win2k machine with MSVC++ 6 > installed, so I downloaded bjam, added it to the path, added the boost > libraries path to the include path and started the build with the command > "bjam -sTOOLS=msvc", and here is what I am getting: I suspect that bjam can't find your visual studio installation: try running the vcvars32.bat file (provided by Microsoft) to set your environment up, before running bjam. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Better Intel-Win32 support
> Gak! These compiler vendors are going to drive us all crazy! What do they > expect us to do, use ESP to know what compiler options are set? If you had ESP, then you would know the answer to that :-> John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RE: random, VC7 andBOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
> I've tried to use the random.hpp header using Visual Studio C++ 6.0, and it > does not > compile. I found a message thread in the mailing list about this on VC7, > where some work-arounds were suggested. Jens then asked for feedback, and I > didn't find any feedback, so here it is... This got fixed in cvs, but sadly after the release... John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Better Intel-Win32 support
> I don't know about Intel-Win32 but I brought much of this up regarding MSVC > 7.0+ and most everybody yawned. I am glad that some people have woken up to > the fact that there is a problem using wide characters with compilers which > support both the native C++ wide character and a previous typedef for > wchar_t. A disappointing aspect of this in regards to MSVC 7.0+ is that > there is no preprocessor macro ( as of 7.0, I haven't checked 7.1 yet ) > which MSVC defines for distinguishing native C++ wide character from the > previous typedef for wchar_t. Actually for real VC7 there is: _NATIVE_WCHAR_T_DEFINED (this may not be documented for VC7 though... sigh. > And as you have said, serious linker errors > will occur for Boost libraries with wide character usage if they are built > for one or the other version of wide character and the end-user sets the > opposite version of wide character in their Makes or projects. Sadly I don't think there is any way to solve linker problems: you just have to ensure that you use these options consistently (like you do with any option that affects binary compatibility). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] regex format conditional expression question
> How do I use the conditional expression in a format string when my > true_expression is a number? For example the format "(?1foo)" will replace > the 1st subexpression with the string "foo", but how do I replace the 1st > subexpression with 123? I try "(?1123)" and that fails. I can do "(?1 123)", > but it gives me an extra space. Ideas? Um, I think (?1(123)) will do it. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Better Intel-Win32 support
> That will certainly work, but you shouldn't have to do that since the > compiler itself defines _WCHAR_T_DEFINED. Since I made the fix earlier this > afternoon I am able to compile some non-boost code correctly which had > previously be failing. Just let me jump in here: you absolutely can not use _WCHAR_T_DEFINED to detect native wchar_t support: the windows headers will define this when wchar_t has been defined as a typedef (and wchar_t is not a native type). There appears to be no way to actually tell whether wchar_t is a native type or not with Intel. One other point: turning wchar_t support on may cause linker errors because you have now changed the name mangling of functions that take wchar_t as an argument - I don't know for sure but I would expect this to affect the std lib. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] needed?
> C99 has a header which provides types, macros, and functions "to > provide access to the floating-point environment." > > Some Boost code in the Interval Library uses this header, or has to do > workarounds if not present. Metrowerks, GCC, and Dinkumware currently ship > the header, but many others don't. > > * Should we have a header? (Greg Chicares asked the same > question a couple of years ago but got to reply.) Is there any general > workaround for when a vendor supplied isn't present? > > * Should there be a macro indicating > availability? > > * Should we start suggesting to vendors that they supply ? > > Any opinions from floating point users? Yes to all of the above IMO. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] problem with libs/config/test/boost_no_std_wstreambuf.cxx
> I've found a little problem in boost_no_std_wstreambuf.cxx > The code uses std::ptrdiff_t but doesn't #include > > I hesitated to add that #include because I don't know wether > all relevant compilers already support that. > > With the current code, the results for Comeau C++ on Linux > are wrong. Good point, I've changed it to int for now. Thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] More problems compiling regex with various compilers
> Then it might be fixed when Apple does the next import of the main > branch of gcc3.3 . Let us wait with those changes until Apple releases > the next version of the developer tools which will probably be based on > gcc3.3 Maybe, I've been able to confirm the problem using gcc 3.1 via sourceforges compile farm (On OS X), in the mean time I've submitted a bug report via bugzilla. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] More problems compiling regex with various compilers
> The undefind reference comes from posix_api.o . I guess that > s_match_vtable is not used in that file. You bet it is, you would get the unresolved external if it wasn't being used :-) > >> On MacOS X using g++ version 3.3 in addition to the linker problem I > >> had to make all the functions you refer to in the intiialization of > >> these tables public in order for the code to compile. > > > > Does that include > > s_match_vtable as well? > > Probably yes. I just made all functions public and it compiled - but > did not instantiate the tables Still weird, changing the declarations to public is not required with other gcc3.3 versions (see the linux regression test results for example). John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] More problems compiling regex with various compilers
> but that just instantiates what I currently need in my code and is no > real solution. I agree completely. > Why do you manually build these vtables and don't use virtual functions? Because they're dispatched based upon a numeric ID stored in the state machine. John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Metrowerks expert help needed with regex
Subject says it all, I'm trying to figure out why the following error is showing up with the metrowerks compiler alone: ### mwcc Compiler: # In: ..\boost\regex\v4\regex_compile.hpp #From: ..\libs\regex\src\cregex.cpp # - #1538: case traits_type::syntax_close_bracket: # Error: ^ # illegal use of structured exception handling keyword outside of __try statement ### mwcc Compiler Error: # internal compiler error (please report to <[EMAIL PROTECTED]>) # while executing in file ExceptX86.c: 'ExX86_WriteAction' (line 528) # (compiling '[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@@@std@@ [EMAIL PROTECTED]@boost@@[EMAIL PROTECTED]@2@@[EMAIL PROTECTED]@@QAE_NXZ' in 'cregex.cpp') Errors caused tool to abort. mwcc -maxerrors 5 -maxwarnings 20 -c -warn on,nounusedexpr,nounused -cwd include -DBOOST_REGEX_NO_LIB=1 -DBOOST_REGEX_STATIC_LINK=1 -DNOMINMAX -now raplines -lang c++ -g -O0 -inline off -prefix UseDLLPrefix.h -runtime md -iso_templates on -iso_templates n -I"d:\boost-regr\libs\regex\build" -I- -I"C:\boost\site" -o "d:\boost-regr\libs\regex\build\bin\libboost_regex.lib\cwpro8\debug\runtime- link-dynamic\threading-multi\cregex.obj" "..\libs\regex\build\../src\cregex.cpp" Thanks, John Maddock. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New configuration macro BOOST_INTEL
> I didn't apply the patches for type_traits and regex (is there a way to > know if Boost cvs contains the current version of a library or if all the > changes will be destroyed the next time the maintainer commits a new > version?). They would benefit from this new macro. As Pavel Vozenilek > suggested it in a recent mail, current_function.hpp would also benefit > from this macro. As far type traits and regex are concerned go ahead. Oh, and can you add the macro to config_info.cpp as well, Many thanks, John ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problems compiling regex with KCC
> After a cvs update I am having probles compiling cregex.cpp on an Intel > Linux platform with the KC compiler. The problem seems to be an > ambiguity in a call to destroy(..). While this is probably a bug in the > KCC compiler, I would appreciate a workaround (e.g. changing the name > of the destroy() function in regex) that would make this library > compile with KCC? The regex code has changed a lot in the last week - I'm still working through all the consequences - there should be fixes that particular problem already in place John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Patch for type_traits
> This small patch removes all the warnings the type_traits regression suite > is actually encountering with Intel compiler on Linux. And thanks to this > patch, the number of warnings for the whole Boost regression suite on this > particular compiler drops from 50 to 1. > > Index: libs/type_traits/test/test.hpp > === > RCS file: /cvsroot/boost/boost/libs/type_traits/test/test.hpp,v > retrieving revision 1.4 > diff -u -r1.4 test.hpp > --- libs/type_traits/test/test.hpp 1 Feb 2003 12:12:08 - 1.4 > +++ libs/type_traits/test/test.hpp 18 May 2003 07:58:19 - > @@ -126,7 +126,7 @@ > # ifdef BOOST_MSVC > # pragma warning(push) > # pragma warning(disable: 4181) > -# elif defined(__ICL) > +# elif defined(__ICL) || defined(__ICC) > # pragma warning(push) > # pragma warning(disable: 21) > # endif > @@ -141,7 +141,7 @@ > typedef const r_type cr_type; > # ifdef BOOST_MSVC > # pragma warning(pop) > -# elif defined(__ICL) > +# elif defined(__ICL) || defined(__ICC) > # pragma warning(pop) > # pragma warning(disable: 985) // identifier truncated in debug information > # endif > > The patch is trivial: the original file removes the warning on Windows, > this patch also removes them on Linux. I will apply the patch if nobody > complains. > > But, more importantly, I want to use this mail to repeat my proposal of a > BOOST_INTEL macro to encompass __INTEL_COMPILER, __ICL, __ICC, __ECC > (thanks to Richard Hadsell for pointing it out) macros. I am not asking > for somebody else to do it, I just want a bit of approval before preparing > the patches since it is not a small job to add a new config macro. Yes, please go ahead with that, it looks like a good idea, thanks, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Configuration for Intel compiler
> Your patch does not fix the problem at all. Ah, I see I got the Intel version check backwards, fixed (hopefully!) > In my opinion, it can even > break some working configurations. I would rather use this conditional > expression: > > # if !(defined(_GLOBAL_USING) && (_GLOBAL_USING+0 > 0 || _CPPLIB_VER == > 310)) && !defined(_STD) I'm not convinced that _GLOBAL_USING is used consistently between Dinkumware libraries (windows vs linux etc), so I'd rather not rely on _GLOBAL_USING at all - hence my attempt to check the Intel version number. > since the test _GLOBAL_USING+0 > 0 is false although we want it true with > Dinkumware 3.10 (_CPPLIB_VER == 310 and maybe other versions but I don't > know them). If there is a way to test the macro _GLOBAL_USING is defined > but doesn't have a value, it would be even better: it would work with all > the versions of the library that assume "#define _GLOBAL_USING" to be > equivalent to "#define _GLOBAL_USING 1". I don't think it's possible to check for that as far as I know :-( John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] CVS status
> I just restored the lost revisions for these three headers: > > boost/config/platform/win32.hpp > boost/config/stdlib/stlport.hpp > boost/filesystem/convenience.hpp > > and, comparing what is probably the most recent "before-the-disk-crash" CVS > snapshot to the current CVS state, it seems that collectively we've been > able to restore everything. Still, if we have resources for that, may be > it's worthy to set up a backup job somewhere to copy everything off-site, > nightly or so - we might not be so lucky next time. That would be a big help - I have about a dozen changes to the regex-4 branch that have been lost - and I haven't even begun to figure these out yet :-( John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
> I realize that I'm replying to a message that is now quite old. Hopefully > what I have to say is still relevant. Apologies if not. Absolutely, there are a couple of procedural points I should make: 1) we are talking about a library only TR at present, core changes aren't allowed just yet. 2) The library TR is not the same as the standard, libraries accepted for the TR won't necessarily make it into the next standard (still several years away). 3) If vendors end up implementing is_convertible in terms of an intrinsic, and if that intrinsic turns out to be more useful than the template, you can guess which one will make it into the standard (the one you want). 4) There has been some concern expressed that meta-programming helpers should not be added piecemeal and that some kind of coherent framework should be created (whether in the core or in the lib). Regards, John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost regex in 1.30.0
> John, what are the correct names? I think I can patch your Jamfile > for you. BBv2 is coming very soon, but this is so easy to do in BBv1 > that it seems a shame to leave users hanging. The names are documented here: http://www.boost.org/libs/regex/appendix.htm#redist Note that the toolset names vary with toolset version, which probably messes up borland bjam builds (since there is only one bjam toolset, but since we have separate toolsets for vc6 and vc7 already, that should be possible. BTW any chance of a separate toolset for vc71? John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible: rationale and wording
> Actually, there is another advantage, which (I think) is at least as
> important as the ones you cite. Namely, it is possible to define a built
> in operator such that is_convertible returns false for
>
> class X{};
> class Y : X {};
>
> and ambiguous conversion cases that (as far as I can tell) cannot be
> implemented in pure C++ (or even with any existing extension of which I am
> aware). That means there's no reason for any ill-formed is_convertible
> expressions, other than those involving incomplete types. That seems a
> good enough reason by itself to reject the template in favor of a built in
> operator.
>
> Put another way, the whole point of is_convertible (as I understand it) is
> to test a certain property of two types (or a type and an expression, if
> you like). In order to perform the test, it should not be necessary to
> know whether or not the types or expressions in question satisfy some
other
> untestible properties.
The problem is that the question "is A convertible to B" has four answers:
yes, no, ill-formed, and ambiguous :-(
John.
> Any code using the existing template could easily be converted to use a
> built in operator. We gain (at least) three distinct and compelling
> advantages, and it appears as though we loose nothing. Apart from getting
> it standardized, what's the problem?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
