[boost] stlport vc++ (was RE: [boost] stlport gcc support)
People are actively working on it though, see the forum on stlport.org. It seems, adding STLport/any recent gcc version to the tests makes only limited sense at the moment. I'm inclined not to add such a configuration, now. Additionally, Visual C++ 7.1 (aka .NET 2003) also comes with decent (working) implementation of standard library, and considering the dynamics of new STLPort versions (quite slow lately), I don't see a point in using STLPort any more for newer MS compilers. VC 6 is another story as STLPort is the only sane standard library implementation. Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: XMLUI (was Re: Re: UI++)
May I come with a bit of scepticism? There's already XUL (see http://xulplanet.com for a start, and http://www.mozilla.org/catalog/architecture/xul/ for more details). I think Mozilla folks put some effort into it, so I wonder if XMLUI offers something new/better? I would say that targets of these two projects are somewhat different. XML UI (IIUC) will support static definition of the layout and functionality in the C++ source code itself, while XUL defines layout (and some functionality) in the external XML file. It's like compile time (XMLUI) vs run-time (XUL). If you ask me, latter is a better approach if done right, but it is very hard to make all this portable. Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: How Do We Install the Boost FileSystem?
You can use the parts independently There is no install required You have the complete code, you include the appropriate header! Yes, for the 'header-only' libraries, filesystem library is not one of them. Boost isn't like most 3rd party libraries in the sense of a dll (or similar) which you download or build and then have to ship and an API to use it. You have the complete code so you can use it as if it was your own! In this case, one would need to either statically link to filesystem lib (if(!) static library is one of the targets of the jamfile) or to link to DLLs (which are for sure produced by jamfile). I would personally always go with DLLs (if we are talking about Windows platform), and building filesystem to DLLs with provided jamfiles is really easy... Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: GUI/GDI template library
Now that the interest for this kind of library has been shown (or not, whatever) could the interested parties please coordinate their efforts using other means than boost mailing list? IIUC this list is for issues with existing code (problems, usage patterns etc) and for submissions that have some code. I am already having problems keeping up with the list as is... Thanks, Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Inconsistency using BOOST_WORKAROUND in format library
There was a message few weeks ago that did not get satisfactory answer hm, I may have missed this message.. Well, like my previous post it ended up with debate about BOOST_TESTED_AT macro and not this case :) you're right there was an inconsistency. but the lines you're quoting are not in CVS anymore, I Good to hear that. In the meantime, we had for quite some time 1.30 version (without the fix), then we applied the same patch, then imported current CVS version few weeks ago. I just wanted to make sure that this is fixed, so that next time we import boost we can overwrite all files safely (we had no other patches). Thanks for the fix, Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Inconsistency using BOOST_WORKAROUND in format library
Hello, There was a message few weeks ago that did not get satisfactory answer IMHO. It's about compiler workaround in boost/format/feed_args.hpp (note that we use VC7.1): [original] #if BOOST_WORKAROUND( BOOST_MSVC, BOOST_TESTED_AT(1300)) [fixed] #if BOOST_WORKAROUND( BOOST_MSVC, = 1300) At the same time, in msvc_disambiguater.hpp: [working] #if defined(BOOST_MSVC) BOOST_MSVC = 1300 // this whole header is specifically for msvc The problem is that macro [working] is, well, working, but the [original] doesn't, and they should work together (by design) - again, all this with VC7.1. My proposal is that if we are all to use these macros, we should use them consistently, and if we do, I'd rather see the version marked as [fixed] above - it does the same thing (according to the docs) and is more readable, or we fix the macro (or the compiler :) I don't know who is to blame (macro or compiler or both), but after reading boost/detail/workaround.hpp I don't see any advantage in using [original] over [fixed], IMHO the [fixed] is more readable and clearly states intent. In my company we have fixed this in our own CVS, but I feel uneasy patching external libraries like this, so if someone with full access to boost CVS could fix this, we would very much appreciate it. Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Inconsistency using BOOST_WORKAROUND in formatlibrary
No it does *not*. Please re-read the docs. OK, mea culpa, I've read them again. I have no opinion on which one is better for this case, but they are different! Good, goes along well with my point - boost code for format uses _different_ macros to detect the same thing. The result is that code wants to use msvc_disambiguater (wrongly) and then can't see it's definiton (correctly). For BOOST_TESTED_AT to do anything useful, we MUST define BOOST_DETECT_OUTDATED_WORKAROUNDS, otherwise fix stays even if new compiler obsoletes workaround, which is what happened in this case. On the other hand, without BOOST_TESTED_AT, assumption is that new compiler _always_ obsoletes the workaround, so I see that for some cases it (BOOST_TESTED_AT) is useful. But for this particular case, it should at least be the same macro for two dependent places in the code, no? Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
That's because void_ is for MPL internal use only; it's not a type
you should manipulate (I think Aleksey doesn't believe me, but I'm
about to prove it... wink).
It's quite all right - my code does not use that other type, I just
need a type. I could have just as well used my own class null_type
{};, but mpl's void_ looked like good enough choice. Anyway, I want to
use null or void in the name of the type just for readability of my
code.
Observe the definition of identity (comments added for exposition
purposes):
[snip]
Well, what can I say - this is not visible from the header, as many
things are wrapped in macros, so reading the code is much harder. Now
that you've shown it the way it really is, I can see the problem. But
since I didn't need void_ in the first place, all is good.
Thanks,
Drazen
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] mpl/loki
Hello,
I've recently discovered that mpl provides all the functionality I was previously
using from loki, so I decided to switch. There is one small thing driving me crazy,
and I was wondering if I missed something...
I was using loki's TypeAtNonStrict algorithm to give me type from type list at a
specified position, or NullType (loki's internal null class) if not found. Now, I
need the same for mpl:vector, and I tried the following 'naïve' approach:
[TypeVector is boost::mpl::vectorbool]
enum { numParams = boost::mpl::sizeTypeVector::type::value };
typedef typename boost::mpl::if_c(numParams 2), typename
boost::mpl::at_cTypeVector, 2::type, boost::mpl::void_::type Param1;
I was expecting to get Param1 to be boost::mpl::void_, but to my great surprise, my
compiler (VC7.1) decided to fully evaluate then branch of if_c as well, even though
the expression numParams 2 was false, and failed.
What would be the right way to express my intention? Btw, I would like to
congratulate authors of mpl on the job well done, I am most impressed not only with
the features that mpl provides but also with the errors I get when something goes
wrong - they are far more readable than most of the STL errors I am used to seeing.
Thanks in advance,
Drazen
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
Just a note: Loki (generic programming applied to design patterns) and MPL (C++ template metaprogramming) preally have a different focus; you may yet find some Loki components that are useful to you. That's possible, but hasn't happened up to now. Actually, I had to replace loki with several of the boost libraries, not only mpl, but the sum of these seems to be enough :) Uh, formatting, please! Uh, sorry, I didn't know it matters to you so much. You have two confusion is about the way template instantiation works. Whenever you write something of the form: template_name ... ::nested_name The template is instantiated. Damn :), I need to brush up on my template skills. [solution for my problem, snipped] Thanks for the solution, it has given me more insight into ways in which mpl can be used. Might I suggest you get ahold of Leor Zolman's latest STLFilt package (www.bdsoft.com)? It contains some great features for formatting nested templates so that they are readable. Thanks, I knew about Leor's package and used it in the old days (VC6), but since I switched to VC7.1, reading errors in SL code became MUCH easier. Thanks again for the help, Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
Btw, VC7.1 does not seem to like identity in this (and
David's) scenario
- it complains that it does not have inner typedef to type,
even though
it does.
Can you please post a small example which fails?
Well, your own :) from few hours ago, used something like this (btw, I
am using CVS snapshot as of, say, 2 weeks ago):
templatetypename Result, TypeVector
class Useful
{
public:
typedef typename type_at_non_strict_cTypeVector, 0::type Param1;
typedef typename type_at_non_strict_cTypeVector, 1::type Param2;
typedef typename type_at_non_strict_cTypeVector, 2::type Param3;
}
Blatant copy from your mail plus small typo (size_t_c to size_t only)
corrected:
template class S, class N
struct type_at_non_strict
: mpl::apply_if
mpl::greatermpl::sizeS,N
, mpl::atS,N
, mpl::identitympl::void_
{};
template class S, std::size_t N
struct type_at_non_strict_c
: type_at_non_strictS, mpl::size_tN
{};
If I do not replace identity with void_ only, I get the following (nice
VC71 elaborate error report):
c:\projects\tools\boost\boost\mpl\apply_if.hpp(39) : error C2039: 'type'
: is not a member of 'boost::mpl::identityboost::mpl::void_'
c:\projects\tools\boost\boost\mpl\identity.hpp(44) : see declaration of
'boost::mpl::identityboost::mpl::void_'
c:\projects\mylib\MetaProgramming.h(26) : see reference to class
template instantiation 'boost::mpl::apply_ifC,F1,F2' being compiled
with
[
C=boost::mpl::greaterboost::mpl::sizeboost::mpl::vectorbool,boost::
mpl::size_t1,
F1=boost::mpl::atboost::mpl::vectorbool,boost::mpl::size_t1,
F2=boost::mpl::identityboost::mpl::void_
]
c:\projects\mylib\MetaProgramming.h(34) : see reference to class
template instantiation 'type_at_non_strictTypeContainer,N' being
compiled
with
[
TypeContainer=boost::mpl::vectorbool,
N=boost::mpl::size_t1
]
c:\projects\mylib\Useful.h(37) : see reference to class template
instantiation 'type_at_non_strict_cTypeContainer,N' being compiled
with
[
TypeContainer=boost::mpl::vectorbool,
N=1
]
c:\projects\mylib\Used.h(45) : see reference to class template
instantiation 'UsefulResult,TypeVector' being compiled
with
[
Result=bool,
TypeVector=boost::mpl::vectorbool
]
I tried to replace company/project specific names with generic ones,
hope I did not ruin the example.
Drazen
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Current CVS Snapshot or...?
Hi, My company is using boost and we would very much like to use variant library immediately and not wait for the next official release of boost. Now, we know that this might not be sensible, but we are ready to take the risk. At the same time, we don't want to break anything else in the boost (and by chain reaction in our code). It seems that variant lib is dependent on (branch of?) mpl, so what I would like to know is: what is the most sane branch/snapshot we should take from the cvs to get reasonably stable boost (overall) with variant in whatever state it is ATM? Thanks, Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] lexical_cast and VC 7.1 (aka VS.NET 2003)
Hello,
I am using boost 1_30_0 (NOT current cvs snapshot) and Visual Studio.NET
2003. There is a strange problem with lexical_cast in the following
scenario (rough aproximation of my code, all in one header):
std::ostream operator(std::ostream out, const ConcreteType v);
namespace foo
{
namespace bar
{
template class T class Formatter
{
public:
std::string getFormattedValue(const T)
{
return boost::lexical_caststd::string(T);
}
}
[,,,]
}
}
When I try to use
FormatterConcreteType::getFormattedValue(objOfConcreteType), the
lexical_cast fails with compiler claiming that there is no operator
that accepts const ConcreteType (or no acceptable conversion).
Now, even more funny is that if I put the operator in boost namespace,
everything is fine (??). Anyone else seeing this? For the moment I am
assuming this is a compiler bug, but if I missed some dusty (or not so
dusty :) corners of C++ that explain this (in favor of compiler),
someone please enlighten me, this is driving me nuts.
Regards,
Drazen
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
