[boost] Re: Re: boost::tuple to MPL sequence
Eric Friedman wrote: I am a bit uneasy about any proposal making adding MPL sequence semantics to an otherwise-typical value type. If such proposals are implemented, I see a significant ambiguity problem arising in generic code: given a type T that is an MPL sequence, should we treat it as a sequence or as a value type? In particular, if we were to implement boost::tuple as an MPL sequence, the following code would seem to me quite unclear insofar as its intended behavior: typedef mpl::listint, std::string some_types; typedef boost::tupleint, std::string some_tuple; typedef boost::variantsome_types v1; // ok, unambiguous typedef boost::variantsome_tuple v2; // ambiguity!? It seems clear that objects of type v1 should behave equivalently to boost::variantint, std::string. However, if boost::tuple were an MPL sequence, it seems less clear whether objects of type v2 should behave likewise or instead as a variant holding a 2-tuple. Thus, this question is of particular importance for boost::variant. But also, I imagine, it is important for any other type implementing a pseudo-variadic template interface as I intend for the final release of variant (which is coming, by the way). Input? I agree. -- Alexander Nasonov Remove minus and all between minus and at from my e-mail for timely response ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost implementation of the Library TR?
Beman Dawes wrote: * What if the committee changes the namespace? Hum... That could happen. Maybe we should use a macro to make it easy to change. A macro would be ugly, unless it looked just like the namespace. Can you define a macro to make std::tr1 be equivalent to std::tr2? Can't you do something that imports all of the new namespace into the old namespace, so that people could make the change (or not) to the new namespace gradually? -- Dick Hadsell914-259-6320 Fax: 914-259-6499 Reply-to: [EMAIL PROTECTED] Blue Sky Studioshttp://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Quantity library: any interest?
From: [EMAIL PROTECTED] Even if angle is added as a dimension, to an implementation using an integer vector, it still wouldn't accommodate any other dimensions added later, without rewriting the library and unit definitions. how about having the basic SI dimensions and a couple of extra to-be-defined-by-the-developer dimensions. In that case, full SI compliance and for those who want something extra they can have it. I saw one of the discussed unit libraries provided something like a dimension to be defined by the user/developer. I think I know a way this may be done, now: Default parameters. There's several ways of specifying a unit; one is to use a typelist, such as typedef mpl::vector_c1,0,0,0,0,0,0 kg (Dave Abrahams also showed this approach at the recent ACCU conference), or use template parameters for the dimensions. In both ways, defaults may be used (it's used internally for mpl::vector, anyway). In fact, all could be defaulted (like mpl::vector), giving in this case a dimensionless unit. Named template parameters could be a possibility, as well, so you could do typedef unitkg, m, s-2 newton. Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] new functions proposals
At 03:21 AM 4/25/2003, Vladimir Prus wrote: Beman Dawes wrote: Beman, if that's fine with you, I'll code them. Yes, go ahead. Although the concept of extension may be foreign on some operating systems, I think the idea is widespread enough to be worth including. If I understand your proposal correctly, the code and its usage will be portable when applied to a path build from the generic grammar and the results will be more or less correct (if a bit odd) when applied to a path which used the system dependent constructor and an operating system specific path string. Yes, I think that's so. I attach a patch against CVS HEAD with implementation, docs and tests. Could you take a look and tell if anything should be corrected? * There are two places in the docs where what should be shown as '.' is showing up as apos;.apos; (browser is IE 6). * empty() is misspelled as empy() in several places. But see next item. * I think the preconditions should be removed. In each case, the behavior as specified is quite sensible even if ph.leaf().empty(), and may be useful in some applications. (Assuming you agree, the assert()'s should be removed, and test cases should be added.) * You have my permission to remove my copyright from the docs and add your own. You've contributed all the pieces, so no need to mention me. * Please add Contributed by Vladimir Prus. to each function. I'd like to track all contributors. * Go ahead and commit to CVS. Then let's keep an eye on the test results for a couple of days as the changes get tested on various platforms. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] new functions proposals
At 12:14 AM 4/27/2003, Trevor Taylor wrote: So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Just my 2 cents... Many legacy filesystems append version or similar identification to file names, often using ':' as a delimiter. OTOH, ':' is a valid character in a file name (and in an extension) on many operating systems. Trying to distinguish between those two cases on an operating system by operating system basis just doesn't seem possible. Better to only promise what we are sure can be delivered - in other words, Vladimir's suggested semantics. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] program options - how to extend
I'm trying to learn to use program options, posted here by Vladimir Prus.
I was trying to use the variables map, and I wanted a double variable. It
seems validator is specialized for float, but not double.
I tried following the example of the float type:
namespace boost { namespace program_options {
template
void validatordouble::operator()(any v, const vectorstring xs)
{
check_first_occurence(v);
string s(get_single_string(xs));
try {
v = any(lexical_castdouble(s));
}
catch(bad_lexical_cast) {
throw validation_error(' + s + ' doesn't look like a double value.);
}
}
}
But check_first_occurence and get_single_string are in an anonymous namespace,
and are not accessible.
Is there a workaround? Should these functions be moved to a different
namespace to make extension more convenient?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [filesystem] new functions proposals
At 10:08 AM 4/27/2003, Pavel Vozenilek wrote: Trevor Taylor [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So it sounds to me like the :blat is *not* part of the extension. It sounds like the NT file name is made up of three parts: name, extension and stream. In which case I think it is fine to have functions extension() and change_extension() - they just should not report or modify the stream part. To implement them I guess I'd need to know whether the file name was an NTFS filename, and then how to reliably locate the extension part? Functin DeviceIoControl() with parameter IOCTL_DISK_GET_PARTITION_INFO can do it. It is available on NT/W2K. Does it make sense to take into account NTFS drives for Win95/98 (from www.systeminternals.com) or Linux NTFS drivers? There are a lot of file systems in this world. It isn't uncommon for the heavy-duty operating systems to handle many different path formats. IIRC, OS/390 (and C++ compilers for it) handles six different path formats. The purely lexical approach taken in Vladimir's proposal is a practical way to meet a common need in portable C++ programs. Let's just leave it at that, and not worry that it won't handle certain non-portable path formats. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost Library Guidelines
On Wednesday 30 April 2003 06:30 am, Pavol Droba wrote: Most of the new warnings can be easily removed with a static_cast. I don't understand, why any boost lib have to generate such a warnings. enters grumpy old developer mode I agree that it would be great from the user's point of view if all of Boost compiled without warnings, but I'm afraid a no-warnings policy will make the whack-a-mole game all that much worse. As it stands, some Boost code is brittle on certain compilers: tweak in one place, and it breaks a compiler; fix for that compiler and you've broken another compiler. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and mutexes : assign_to error
On Wednesday 30 April 2003 08:44 am, Jacques Kerner wrote:
Hi,
I get the following error :
error C2664: 'void boost::function0R,Allocator::assign_to(Functor)' :
unable to convert parameter 1 from 'const CTaskManager' to 'CTaskManager'
when doing this :
class CTaskManager
{
public:
CTaskManager();
~CTaskManager();
void operator()() {}
private:
boost::mutex m_mutex;
}
and
CTaskManager taskManager;
boost::thread_group mainThreadGroup;
mainThreadGroup.create_thread(taskManager);
mainThreadGroup.join_all();
The error dissapears when I remove the mutex from the definition of
CTaskManager ... (?!!)
So what is the right way to use mutex and threads together? Do I have to
declare the mutex outside of the
functor? Why?
Mutexes are not copyable, and when you pass taskManager to create_thread it
tries to make a local copy of the function object . If you would prefer to
pass a reference to taskManager to create_thread, do this:
mainThreadGroup.create_thread(boost::ref(taskManager));
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost Library Guidelines
Pavol Droba said: I have noticed a lot of new warnings in the release 1.30. I absuletely agree, that there is no reason to do some kind of line by line pragma suppression. But... Most of the new warnings can be easily removed with a static_cast. I don't understand, why any boost lib have to generate such a warnings. I'm going to guess that most of the new warnings you see aren't level 4 warnings. I'll also guess that the crept in for the same reason I missed some VC warnings in Boost.Threads with 1.30. That is to say, it happened because I assumed Boost.Build was setting the warning level to an appropriate default (i.e. the level that the IDE sets for new projects), when in fact, it wasn't setting it at all. I posted about this a while ago. If this isn't the cause, then you'll have to ask individual authors, and/or submit patches. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost implementation of the Library TR?
Richard Hadsell wrote:
Beman Dawes wrote:
* What if the committee changes the namespace?
Hum... That could happen. Maybe we should use a macro to
make it easy
to change.
A macro would be ugly, unless it looked just like the namespace. Can
you define a macro to make std::tr1 be equivalent to std::tr2?
Only with macro scopes as discussed recently on this list:
#region std
# define tr1 std::tr2
#endregion
namespace std::tr1 {} // expands to namespace std::tr2 {}
Regards Hartmut
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and mutexes : assign_to error
Jacques Kerner said:
Hi,
I get the following error :
error C2664: 'void boost::function0R,Allocator::assign_to(Functor)' :
unable to convert parameter 1 from 'const CTaskManager' to
'CTaskManager'
when doing this :
class CTaskManager
{
public:
CTaskManager();
~CTaskManager();
void operator()() {}
private:
boost::mutex m_mutex;
}
and
CTaskManager taskManager;
boost::thread_group mainThreadGroup;
mainThreadGroup.create_thread(taskManager);
mainThreadGroup.join_all();
The error dissapears when I remove the mutex from the definition of
CTaskManager ... (?!!)
Correct. Functors are passed by value (i.e. they must be Copyable), and
Mutexes are Noncopyable.
So what is the right way to use mutex and threads together? Do I have to
declare the mutex outside of the
functor? Why?
No, you just have to enable the functor to be copyable, as per the FAQ at
http://www.boost.org/libs/thread/doc/faq.html#question5.
However, I'm going to guess from the code snippet that you really don't
want this functor to be copied? If that's the case, you may want to make
use of boost::ref.
CTaskManager taskManager;
boost::thread_group mainThreadGroup;
mainThreadGroup.create_thread(boost::ref(taskManager));
mainThreadGroup.join_all();
--
William E. Kempf
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost implementation of the Library TR?
On Wednesday 30 April 2003 08:25 am, Beman Dawes wrote: * What namespace should the Boost version go in? (tr1 is t, r, followed by numeral one, and is the committee's tentative choice for a sub-namespace.) std::tr1 // well, this IS an implementation of the standard TR boost::tr1 // users can pick and choose, also more traditional Putting everything into boost::tr1 feels like gratuitous code movement. Then our users' migration path is from ::boost to ::boost::tr1 to ::std::tr1. Why bother with the intermediate step? * What header naming convention? Note that users can pick and choose an implementation by header choice, even if we use namespace std::tr1. I'd prefer to use the standard's naming convention for headers, to make it a real implementation of TR1. There is one problem with this that I don't know how to completely solve: some of the new libraries are extensions to old headers, e.g., function, reference_wrapper, and bind all go into functional. Can we rely on something like GNU's #include_next to allow us to have our own functional that falls back to the standard library's functional? * Should we continue to maintain the pre-TR Boost versions of the libraries? Decide this on a library by library basis Long term, probably don't want to continue as we don't want to compete against the standard itself. We should maintain the pre-TR versions at least until the TR gets its rubber stamp, because until then the TR versions may still change whereas the pre-TR versions are generally quite stable. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Workarounded regression tools for MSVC 6
At 06:40 PM 4/29/2003, Vaclav Vesely wrote: This patch allows to compile regression tools with MSVC 6. First, thanks for going to the effort to work through the various issues. I have very mixed feelings about the patch. Obviously it is great to extend the regression reporting tools to work with more compilers, but there just hasn't been any demand from users. I hate to see the source code degraded to cope with a compiler version that is now two releases and 14 months out-of-date, particularly when the latest version is *much* more standards conforming, and both of the newer versions do fine with the reporting tools. Looking forward, I also don't want to have to support VC++ 6.0 for any future changes. So please don't take it personally, but I'm not going to apply the patches unless someone comes forward with more rationale for supporting reporting tool compilations with VC++ 6.0. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Threads and mutexes : assign_to error
Douglas Gregor wrote:
On Wednesday 30 April 2003 08:44 am, Jacques Kerner wrote:
Hi,
I get the following error :
error C2664: 'void boost::function0R,Allocator::assign_to(Functor)' :
unable to convert parameter 1 from 'const CTaskManager' to 'CTaskManager'
when doing this :
class CTaskManager
{
public:
CTaskManager();
~CTaskManager();
void operator()() {}
private:
boost::mutex m_mutex;
}
and
CTaskManager taskManager;
boost::thread_group mainThreadGroup;
mainThreadGroup.create_thread(taskManager);
mainThreadGroup.join_all();
The error dissapears when I remove the mutex from the definition of
CTaskManager ... (?!!)
So what is the right way to use mutex and threads together? Do I have to
declare the mutex outside of the
functor? Why?
Mutexes are not copyable, and when you pass taskManager to create_thread it
tries to make a local copy of the function object . If you would prefer to
pass a reference to taskManager to create_thread, do this:
mainThreadGroup.create_thread(boost::ref(taskManager));
Doug
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thank you very much, it works great. I had missed the fact that
create_thread makes a copy
of the functor. Thanks again!
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
