RE: [boost] Re: Eric Ford's Unit package
I have found in the past that there is a need to distinguish between dimension handling and unit handling. In the case of a physical calculation, I usually ensure that the code works with a self consistent set of units, and thus only need dimensionality, compile time, code. Units then become important only in the user interface, and I have a list of the units used in the physical calculation for each dimension. This is obviously only one way of using dimensions and units, but I think an important one. The usual exception to the above is for money where you are working with multiple currencies. I agree that this is an important distinction which some people get confused on. Reviewing our old discussions, this was the closest thing to a concensous. Money was the one issue that was still very much up in the air. My conclusion was that money probably warranted a whole library to itself, but that many users would be happy with a simple money dimension tacked onto SI. A couple of use cases, that I am unsure would be handled by the current proposal: I have a Cost class that records costs for different factories in different countries. The unit used for each is factory is different, eg USD for factories in US, GBP for those in UK. ie the unit varies per instance. I agree that treating value as the dimension, but I choose to use currency as the name of the dimension, since value has other connotations to programers. There are several ways you could deal with this with my draft library. Users would choose the most appropriate way for their particular purposes. One way involves treating USD, GBP, etc. as units for the currency dimension. The other involves treating USD, GBP, etc. as qualifiers for the type of currency. One way is to decide that what you're really interested in is the value, and you're not really interested in which currency that is in. Such a user could use the currency dimension something like this... static const currency usd (1.00); static const currency gbp (1.50); currency chicago_cost = 2000 * usd; currency dublin_cost = 1500 * gbp; currency total_cost = chicago_cost + dublin_cost; cout The total cost is total_cost = total_cost / usd USD = total_cost / gbp GBP\n; The advantage of this way is that the user can do arithmetic between different currencies transparently. If all the user is interested in is the value in their home currency, then this may be adequate and even desirable. Of course, there are cases where this would not be appropriate. For example, if a user wants to keep track of how much of his money is in different currencies, a common desire given that the relative values of currencies fluctuate. In such a case, I would recommend making use of my qualifier tags. Something like... char usd_label[] = USD; char gbp_label[] = GBP; typedef basic_qualifierusd_label usd_qualifier; typedef basic_qualifiergbp_label gbp_qualifier; typedef basic_qualifiereuro_label euro_qualifier; typedef qualified_dimensioncurrency,usd_qualifier usd; typedef qualified_dimensioncurrency,gbp_qualifier gbp; typedef qualified_dimensioncurrency,euro_qualifier euro; static const usd dollar (1.00); static const gbp gb_pound (1.00); usd chicago_cost (2000.); // just to show another way usd la_cost = 1800. * dollar; gbp dublin_cost = 1500. * gb_pound; usd total_us_cost = chicago_cost + la_cost; // same currency, so ok usd total_cost = total_us_cost + dublin_cost; // different currencies: WILL NOT COMPILE BY DEFAULT This way the compiler will prevent you from assigning or performing arithmetic between currencies (unless a user want to allow such operations and specializes the is_tag_change_ok and/or promote_dimension_qualifier templates accordingly). Now a user who wants to keep track of all her bank accounts in different currencies will do so with strongly typed variables. Of course, they might want to write a class that allows for combining these into a single value in some time dependant fashion (and most likely not possible at compile time). A similar situation occurs for dimensions of physical units. eg. if you want a list of quantities used per output weight or output pieces, then each item in the list has different dimensions, eg. Watt seconds/time, Litre/piece, number/kg. In this case I obviously have to give up the type checking, but still need to be able to record a dimension, to allow display in appropriate units. I think this could be addressed with something like listany materials; materials.push_back(100.*joule); materials.push_back(50.*liter); cout This will take: for(listany::iterator i = materials.begin();i!=materials.end();++i) cout *i \n; Now, it's probably obvious that the 100 joules is of electricity, but may not be so obvious what the 50 liters is of. If you'd like to keep track of what those fifty liters are of, then I'd recommend you use a qualifier tag like: char garlic_label[] = garlic;
Re: [boost] possible addition to operators library
Hi all,
Hate to sound pushy, but I've no answer on this, were the patches ok? Would
you like me to repost them?
Or should I just drop it?
Cheers
Sam
- Original Message -
From: Sam Partington [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Thursday, February 27, 2003 10:55 AM
Subject: Re: [boost] possible addition to operators library
Daniel Frey wrote:
Daniel Frey wrote:
No problem. IIRC it was Peter Dimov who came up with the safe-bool
idiom first. At least I saw it first from him. Another way which
works but results in worse error messages is this:
template class T, class B = ::boost::detail::empty_base
struct bool_testable : B
{
private:
operator int() const;
public:
operator bool() const
{
return !!static_cast T ( *this );
}
};
It should be a more efficient implementation for most of the points
Dave mentioned and it should also work in all cases (allowing the use
as a bool, int is private, thus not accessible and other conversions,
e.g. to 'long' are ambiguous. The drawback is, that the error
messages are not as clear and obvious as for Peter's idiom.
Well we'll stick with Peter's model then. I had figured it was Peter,
someone let me know if it wasn't.
Sam Partington (me!) wrote:
Is there another alternative to this? How about this:
typedef void (bool_testableT,B::*unspecified_bool_type)() const;
operator unspecified_bool_type() const
{
return !static_castconst T(*this) ? 0 :
reinterpret_castunspecified_bool_type(bool_testableT,B::operator
unspecified_bool_type);
}
Does this have any issues that I can't see? Ideally we could avoid
the reinterpret_cast, but how do you express the type of a
user-defined conversion operator for the type you're trying to
express? Beats me!
I was hoping for a response to this, but I know we're all busy, so I'll
take
the silence to mean that noone has any serious objections. I know lots of
you will see the reinterpret_cast and start shouting non-portable but in
this case all its doing is casting the return type of the function
pointer.
Also we're not going to use the pointer other than a compare to zero, so
providing there are no compilers that would reinterpret_cast to a zero, I
don't see a problem.
This is my preferred solution for now, as it avoids a lot of the overhead
problems that have worried some of you.
I've attached the patches, including docs and test.
Sam
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Sam Partington wrote: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? No, please don't drop it. I think it's a good idea, but I haven't found the time to look at your patches closely. I will try to do so but I can't promise any shedule. Besides: I remember that the first message about the NRVO-implementation I wrote was about June 2002 and it took several months to get it accepted. Just be patient and keep reminding the group (and the maintainers of operators.hpp) from time to time :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Aleksey Gurtovoy wrote: If one of the developers could at least comment on this I might give it another try. Otherwise I estimate it would take me weeks to reverse-engineer what is happening here. Ralf, I will definitely look into it tonight and get back to you. OK, I've checked in a fix into the main trunk (see boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the problem go away, I'll integrate the new version into the release branch. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL]edge connectivity code won't compile
Hi, Volodya,
1) It works even though I haven't got to CVS.
#ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
template
struct property_traitsdefault_color_type* {
typedef default_color_type value_type;
I added it here-- typedef default_color_type reference;
typedef std::ptrdiff_t key_type;
typedef lvalue_property_map_tag category;
}
2) After it works, I set compile option back to /Gm, and it still works, the
error C1076 does not appear anymore.
Thanks.
J-S
- Original Message -
From: Vladimir Prus [EMAIL PROTECTED]
To: Boost mailing list [EMAIL PROTECTED]
Sent: Friday, March 07, 2003 2:32 AM
Subject: Re: [boost] [BGL]edge connectivity code won't compile
Hi J-S,
Hi, Volodya
Following arethe error messages:
--
\boost-g\boost_1_29_0\boost\property_map.hpp(151) : error C2039:
'reference'
: is not a member of 'boost::property_traits'
with
[
PA=boost::default_color_type *
]
g:\boost-g\boost_1_29_0\boost\graph\properties.hpp(52) : see
declaration of 'boost::property_traits'
with
[
PA=boost::default_color_type *
]
Could you please try adding
typedef default_color_type reference;
to the specialization of property_traits for default_color_type, which
is in file boost/graph/properties.hpp (line 56 in CVS version)
If this fixes the error, I'll make the fix in CVS.
Basically, I got two errors:
1)C1076--I have changed from /Gm to /Zm1000, and it went way.
Did you posted compiler output for this error, or I missed it?
Thanks,
Volodya
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] how to avoid inclusions?
Hi Bootsters, I have a problem that, I think, is worth of discussion. When developing a library I came to a to a need of a trait class, containing properties of different containers. There is a default behavior and a specialization for different stl containers like vector, basic_string and etc. To make the specialiazation, I have to include all the headers for specific containers even, if they are not used by the user code. ( trait class template does not gets instantiated for the specific container ). I have tried to make forward declaration of std::vector and alike, but it does not work all the time, and, I think it is even forbiden by some compilers. My question is: Is there a correct way how to avoid these unwanted inclusions? Or more specificaly: How to define a partial specialization for a specific type, without including its full definition? Regards, Pavol ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] how to avoid inclusions?
Pavol Droba [EMAIL PROTECTED] writes:
I have tried to make forward declaration of std::vector and alike, but it does not
work all the time,
and, I think it is even forbiden by some compilers.
It's forbidden by the standard.
My question is:
Is there a correct way how to avoid these unwanted inclusions?
Not if they're standard containers :(
Or more specificaly:
How to define a partial specialization for a specific type, without including its
full definition?
That's a different question:
template class T struct whatever;
template class T struct whateverboost::shared_ptrT
{
//...
};
You never have to define the primary template, in fact.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
Sam Partington [EMAIL PROTECTED] writes: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? The code looks OK, but the submission won't be complete without patches for the docs and tests. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] possible addition to operators library
At 11:08 AM 3/7/2003, David Abrahams wrote: Sam Partington [EMAIL PROTECTED] writes: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? The code looks OK, but the submission won't be complete without patches for the docs and tests. The submission was three files, including patches for docs and tests. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [BGL]edge connectivity code won't compile
Hi J-S, Hi, Volodya, 1) It works even though I haven't got to CVS. OK, fix comitted both to the trunk and release candidate brunch, so it should be part of 1.30.0. 2) After it works, I set compile option back to /Gm, and it still works, the error C1076 does not appear anymore. That's good. Thanks, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] how to avoid inclusions?
On Fri, Mar 07, 2003 at 10:09:40AM -0500, David Abrahams wrote:
Pavol Droba [EMAIL PROTECTED] writes:
I have tried to make forward declaration of std::vector and alike, but it does not
work all the time,
and, I think it is even forbiden by some compilers.
It's forbidden by the standard.
My question is:
Is there a correct way how to avoid these unwanted inclusions?
Not if they're standard containers :(
not good :(
Or more specificaly:
How to define a partial specialization for a specific type, without including
its full definition?
That's a different question:
template class T struct whatever;
template class T struct whateverboost::shared_ptrT
{
//...
};
You never have to define the primary template, in fact.
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible? Or is there a way how to achieve the same efect, but without
including vector?
I see, that is probably isn't ..
Pavol
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: how to avoid inclusions?
Pavol Droba wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible? Or is there a way how to achieve the same efect, but without
including vector?
I see, that is probably isn't ..
Pavol
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Pavol
Could you put each specialisation in a separate header file and arrange only to
include the ones which you
need, the vector one when you include vector etc?
Just a thought
John
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] filesystem, Jamfile.v2, project-id
Hi, I suggest to apply the attached patch to libs/filesystem/build/Jamfile.v2 The patch adds boost/filesystem as project-id. Regards, m Index: Jamfile.v2 === RCS file: /cvsroot/boost/boost/libs/filesystem/build/Jamfile.v2,v retrieving revision 1.1 diff -u -r1.1 Jamfile.v2 --- Jamfile.v2 13 Jan 2003 10:05:00 - 1.1 +++ Jamfile.v2 7 Mar 2003 17:31:25 - @@ -1,5 +1,5 @@ -project +project boost/filesystem : source-location ../src ; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] filesystem, Jamfile.v2, project-id
Martin Wille wrote: Hi, I suggest to apply the attached patch to libs/filesystem/build/Jamfile.v2 The patch adds boost/filesystem as project-id. Applied both to trunk and release candidate brunch. Are you using Boost.Build V2 already? Thanks, Volodya P.S. Please post further Boost.Build questions to [EMAIL PROTECTED] mailing list. Thanks. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: how to avoid inclusions?
On Fri, 7 Mar 2003 18:17:56 +0100, Pavol Droba [EMAIL PROTECTED]
wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible?
Practically speaking, no. At least not in a portable, conforming way.
You can (under certain limitations) provide specializations like
class A { };
namespace std { template class numeric_limitsA {}; }
but you can't otherwise add declarations to std. There are several
reasons for this limitation.
AFAIK the committee discussed the possibility to provide fwd versions
of standard headers other than iosfwd but decided not to do so.
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Does this compiler need configuring?
On Tuesday, March 4, 2003, at 9:47 AM, Beman Dawes wrote:
At 02:03 AM 3/4/2003, Daryle Walker wrote:
I'm trying to use the more_io.zip stuff currently under review with a
copy of Metrowerks CodeWarrior Developement Studio (Mac OS X Edition,
v8). I haven't got anything to compile.
If there is a question of configuration as John's rely indicates, a
good way to debug the problem is to run the config_info regression
test. Inspect the output to see if it is reporting the right
platform, compiler version, and library.
Don't even bother trying anything else until config_info is reporting
the correct information.
I can't even get that to run. I get the error:
//=
Error : undefined identifier 'ptrdiff_t'
(included from:
config.hpp:57
config_info.cpp:10)
suffix.hpp line 245 namespace std { using ::ptrdiff_t; using
::size_t; }
//=
with the last ptrdiff_t highlighted as the problem.
I've attached the project I used, so maybe some Metrowerks expert can
find the obvious thing I forgot (or maybe it's actually a
misconfiguration, or [worse] a bug).
Daryle
config_info.mcp.xml.zip
Description: Zip archive
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] PRB with type_traits::is_member_function_pointer
At 09:00 AM 2/18/2003, Markus Schöpflin wrote: Hi there, currently, the is_member_func_test fails for VACPP6 with the following error messages: /home/auto/schoepf/src/extern/boost-cvs/boost/type_traits/is_member_functio n_pointer.hpp, line 37.29: 1540-1206 (S) The class template instantiation of is_mem_fun_pointer_implvoid (UDT::*)() is ambiguous. /home/auto/schoepf/src/extern/boost- ... When looking at is_mem_fun_pointer_impl.hpp it looks like the Metrowerks compiler has the same problem. Could anyone please add a check for __IBMCPP__ =600 at line 345 of this file and regenerate it? Markus, It doesn't look like this change was ever made. Would you still like to see it made? Does anyone have an objection? It would only affect the IBM compiler. (I'm trying to make sure that patches haven't fallen on the floor. Please excuse the bother if the patch was not applied because it was rejected, and I just didn't see any message indicating that.) I'll make the change if it is still needed. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Does this compiler need configuring?
At 03:49 PM 3/7/2003, Howard Hinnant wrote: On Thursday, March 6, 2003, at 03:33 AM, Daryle Walker wrote: I've attached the project I used, so maybe some Metrowerks expert can find the obvious thing I forgot (or maybe it's actually a misconfiguration, or [worse] a bug). I'm a Metrowerks expert, but not a boost expert. Your project is set up to use MSL C which correctly puts ptrdiff_t into namespace std. The above code can't find ::ptrdiff_t because cstddef only defined std::ptrdiff_t. It looks to me like BOOST_NO_STDC_NAMESPACE is being mistakenly defined somewhere. Daryle, Try compiling libs/config/config_info.cpp and running it. The output will tell you what the configuration looks like. It will identify the platform, compiler, library, and the important macros defined for each. Look for macros which are obviously wrong, such as BOOST_NO_STDC_NAMESPACE. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: possible addition to operators library
On Fri, 07 Mar 2003 19:42:44 +0100, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 11:08 AM 3/7/2003, David Abrahams wrote: Sam Partington [EMAIL PROTECTED] writes: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? The code looks OK, but the submission won't be complete without patches for the docs and tests. The submission was three files, including patches for docs and tests. The only one I could find was a single patch. Can someone point to the message in the archive please? http://www.mail-archive.com/boost%40lists.boost.org/msg05908.html BTW: I wonder if gmane eats messages. I cannot find some messages we exchanged when I was still in the company earlier this day. I will keep an eye on it in case the problem remains. Sam: I looked at the patches, especially the doc. I think you should write some more, as you were influenced from your knowledge. I suggest you begin with mentioning operator bool() and what's wrong with it before presenting the solution. Think of new users that potentially don't even know that there is a problem with operator bool(). Also, if you like, you can write a brief note about why the classic solution I showed (using a private operator int() in parallel to operator bool()) is not a good solution and how yours/Peter's is better. All this can/should happen in the note you added. The note itself should be added to the index at the top and you might want to add yourself to the contributors' list at the end. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: how to avoid inclusions?
On Fri, Mar 07, 2003 at 04:54:14PM +, John Fletcher wrote:
Pavol Droba wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible? Or is there a way how to achieve the same efect, but without
including vector?
I see, that is probably isn't ..
Pavol
Could you put each specialisation in a separate header file and arrange only to
include the ones which you
need, the vector one when you include vector etc?
I see this as the only possibility. It's not very nice though. This way user is
required to include a header
each time he want to use a container. It gets even more confusing, because the trait
class is supposed to
be only an implementation detail. However this way, users either accept the inclusion
of unwanted headers,
or they have to include specific header manualy.
Typical now win solution :(
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: how to avoid inclusions?
On Fri, Mar 07, 2003 at 08:09:35PM +0100, Gennaro Prota wrote:
On Fri, 7 Mar 2003 18:17:56 +0100, Pavol Droba [EMAIL PROTECTED]
wrote:
I wanted to do something else:
template class T struct trait_class
{
}
template class T struct trait_classstd::vectorT
{
}
without #include vector
Is this possible?
Practically speaking, no. At least not in a portable, conforming way.
You can (under certain limitations) provide specializations like
class A { };
namespace std { template class numeric_limitsA {}; }
but you can't otherwise add declarations to std. There are several
reasons for this limitation.
AFAIK the committee discussed the possibility to provide fwd versions
of standard headers other than iosfwd but decided not to do so.
My question is then following:
How do the boost libraries solve this problem?
I see only 2 possibilities, both not very nice.
- Silently include all stl container headers ( or at least meny of them )
- Divide the specialization into several files ( one for each container ) and
ask the user to include the specific one.
Is there some other option I don't know about?
Pavol
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey [EMAIL PROTECTED] writes: Sam: I looked at the patches, especially the doc. I think you should write some more, as you were influenced from your knowledge. I suggest you begin with mentioning operator bool() and what's wrong with it before presenting the solution. Think of new users that potentially don't even know that there is a problem with operator bool(). Also, if you like, you can write a brief note about why the classic solution I showed (using a private operator int() in parallel to operator bool()) is not a good solution and how yours/Peter's is better. All this can/should happen in the note you added. The note itself should be added to the index at the top and you might want to add yourself to the contributors' list at the end. Very nice remarks, Daniel. I have full confidence in you as the new maintainer of the operators library. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- Aleksey Gurtovoy [EMAIL PROTECTED] wrote: OK, I've checked in a fix into the main trunk (see boost/mpl/aux_/lambda_support.hpp). If you could check if it makes the problem go away, I'll integrate the new version into the release branch. Thank you very much Aleksey! The error posted before is gone. This is very helpful and highly appreciated. I spent the better part of today figuring out the six additional patches shown below. I believe all Boost.Python tests build as expected with these patches using the mipspro toolset, but the final re-compilation from scratch is still going. David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Thank you in advance! Ralf Index: mpl/protect.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/protect.hpp,v retrieving revision 1.5 diff -r1.5 protect.hpp 32c32 typedef protect type; --- typedef struct protect type; Index: mpl/aux_/integral_wrapper.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/integral_wrapper.hpp,v retrieving revision 1.1 diff -r1.1 integral_wrapper.hpp 30c30 # define AUX_WRAPPER_INST(value) AUX_WRAPPER_NAME value --- # define AUX_WRAPPER_INST(value) mpl::AUX_WRAPPER_NAME value 39c39 typedef AUX_WRAPPER_NAME type; --- typedef struct AUX_WRAPPER_NAME type; Index: mpl/aux_/preprocessed/no_ttp/iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/preprocessed/no_ttp/iter_fold_if_impl.hpp,v retrieving revision 1.1 diff -r1.1 iter_fold_if_impl.hpp 58c58 ::template result_ Iterator,State,ForwardOp,nextIterator impl_; --- ::template result_ Iterator,State,ForwardOp,mpl::nextIterator impl_; Index: mpl/aux_/preprocessed/no_ttp/lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/preprocessed/no_ttp/lambda_no_ctps.hpp,v retrieving revision 1.1 diff -r1.1 lambda_no_ctps.hpp 34c34 typedef protect bind1 --- typedef mpl::protect bind1 59c59 typedef protect bind2 --- typedef mpl::protect bind2 85c85 typedef protect bind3 --- typedef mpl::protect bind3 111c111 typedef protect bind4 --- typedef mpl::protect bind4 137c137 typedef protect bind5 --- typedef mpl::protect bind5 Index: python/enum.hpp === RCS file: /cvsroot/boost/boost/boost/python/enum.hpp,v retrieving revision 1.6 diff -r1.6 enum.hpp 95c95 this-enum_base::export_values(); --- this-base::export_values(); Index: type_traits/is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,28 #if !defined(__BORLANDC__) --- #if !defined(__BORLANDC__) \ !(defined(__sgi) defined(_COMPILER_VERSION) _COMPILER_VERSION = 730) __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Well, in addition, I believe: /boost/boost/mpl/aux_/lambda_no_ctps.hpp. The patch that worries me the most is the one in is_base_and_derived.hpp, but not seriously: it's just that it should probably be checking __EDG_VERSION instead of looking for the sgi compiler. Otherwise, they all look fine to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] C++ Standards Committee upcoming meeting
The C++ Standards Committee will be meeting in Oxford, UK, April 7th through 11th. As always, Boosters are welcome to attend as technical experts - See http://www.boost.org/more/cpp_committee_meetings.html. Contact me privately if you want more information. The committee's pre-meeting papers are now available. (The membership list is for members only, and so is password protected, but the rest are available to the public.) See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/#pre_oxford The papers this time around include final, or close to final, proposals for adding type traits, regex, shared_ptr, bind, and a number of other bits and pieces from Boost to the Standard Library TR. While the author's of course get the main credit, everyone who participates in Boost in any way can justifiably feel proud of these proposals. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Well, in addition, I believe: /boost/boost/mpl/aux_/lambda_no_ctps.hpp. OK, here are the two additional patches: Index: lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/lambda_no_ctps.hpp,v retrieving revision 1.7 diff -r1.7 lambda_no_ctps.hpp 127c127 typedef protect BOOST_PP_CAT(bind,i) --- typedef mpl::protect BOOST_PP_CAT(bind,i) Index: iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/iter_fold_if_impl.hpp,v retrieving revision 1.5 diff -r1.5 iter_fold_if_impl.hpp 104c104 ::template result_ Iterator,State,ForwardOp,nextIterator impl_; --- ::template result_ Iterator,State,ForwardOp,mpl::nextIterator impl_; The patch that worries me the most is the one in is_base_and_derived.hpp, but not seriously: it's just that it should probably be checking __EDG_VERSION instead of looking for the sgi compiler. I don't know what EDG version to use in the #ifdef. I'll leave this as is for now. If someone else has the same problem on a different platform we can generalize. Otherwise, they all look fine to me. OK, I'll wait for a word from Aleksey. If he is happy I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. BTW: David, compilation of as_to_python_function.cpp fails on all platforms. hopefully_illegal suggests that this is expected, but then again the test is not called xxx_fail.cpp like the other tests that are expected to fail. Is everything all right here? Don't you want to rename the test? Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: --- David Abrahams [EMAIL PROTECTED] wrote: Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: David and Aleksey, could you please review the patches and tell me which are OK to check in? -- I am a bit worried about the two patches in the mpl/aux_/preprocessed directory. Are these files auto-generated? Are there master files that should be patched instead? Well, in addition, I believe: /boost/boost/mpl/aux_/lambda_no_ctps.hpp. OK, here are the two additional patches: Index: lambda_no_ctps.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/lambda_no_ctps.hpp,v retrieving revision 1.7 diff -r1.7 lambda_no_ctps.hpp 127c127 typedef protect BOOST_PP_CAT(bind,i) --- typedef mpl::protect BOOST_PP_CAT(bind,i) Index: iter_fold_if_impl.hpp === RCS file: /cvsroot/boost/boost/boost/mpl/aux_/iter_fold_if_impl.hpp,v retrieving revision 1.5 diff -r1.5 iter_fold_if_impl.hpp 104c104 ::template result_ Iterator,State,ForwardOp,nextIterator impl_; --- ::template result_ Iterator,State,ForwardOp,mpl::nextIterator impl_; The patch that worries me the most is the one in is_base_and_derived.hpp, but not seriously: it's just that it should probably be checking __EDG_VERSION instead of looking for the sgi compiler. I don't know what EDG version to use in the #ifdef. It's easy enough to test it with a little program that prints the value you have. I'll leave this as is for now. If someone else has the same problem on a different platform we can generalize. Doesn't worry me too much, but it's surely not SGI-specific. Otherwise, they all look fine to me. OK, I'll wait for a word from Aleksey. If he is happy I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. That looks good. BTW: David, compilation of as_to_python_function.cpp fails on all platforms. Intended. The Jamfile says: compile-fail ./as_to_python_function.cpp : $(PYTHON_PROPERTIES) ; and the Jam output should say (failed-as-expected) ... **passed** ... unless -d0 caused that to be suppressed, in which case we should remove the -d0 I guess. hopefully_illegal suggests that this is expected, but then again the test is not called xxx_fail.cpp like the other tests that are expected to fail. Is everything all right here? Yes. Don't you want to rename the test? Not really ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: how to avoid inclusions?
Hereby at least a partial solution which so far works with gcc3.2 and comeau
4.3.0.1.
The complete source can be found in the sandbox :
boost-sandbox/libs/sequence_algo/test/container_traits.hpp
boost-sandbox/boost/sequence_algo/container_traits.hpp
my code does not include vector, list or map, but it does need
iterator.
Some of the functionality of the container_traits are shown here:
template typename C
bool is_container()
{
return boost::container_traitsC::is_container();
}
template typename C
bool is_sequence()
{
return boost::container_traitsC::is_sequence();
}
template typename C
bool is_contiguous_sequence()
{
return boost::container_traitsC::is_contiguous_sequence();
}
template typename C
bool is_associative()
{
return boost::container_traitsC::is_associative();
}
int main()
{
using namespace boost;
using namespace std;
typedef listint list_t;
typedef vectorint vector_t;
typedef mapint,int map_t;
assert( is_containervector_t() );
assert( is_sequencevector_t() );
assert( is_sequencelist_t() );
assert( !is_sequencemap_t() );
assert( is_contiguous_sequencevector_t() );
assert( !is_contiguous_sequencelist_t() );
assert( !is_contiguous_sequencemap_t() );
assert( is_associativemap_t() );
assert( !is_associativevector_t() );
assert( !is_associativelist_t() );
}
--
The implementation uses SFINAE and relys on some assumptions that I'm not a
100% sure about. The core of the implementation is this:
template typename C
true_t is_container( const C, const typename C::iterator =
typename C::iterator() );
template typename T, std::size_t sz
true_t is_container( const T ()[sz] );
false_t is_container( ... );
template typename C
true_t is_associative_container( const C,
const typename C::key_type =
typename C::key_type() );
false_t is_associative_container( ... );
template typename C
struct tag_generator
{
static C c;
BOOST_STATIC_CONSTANT( bool, is_container_ = sizeof( true_t )
== sizeof( is_container( c ) ) );
BOOST_STATIC_CONSTANT( bool, is_associative_container_ =
sizeof( true_t ) ==
sizeof( is_associative_container( c ) ) );
BOOST_STATIC_CONSTANT( bool, is_sequence_container_ =
is_container_
not is_associative_container_ );
enum { has_random_access_iterator_ =
::boost::is_same std::random_access_iterator_tag,
typename std::iterator_traits
typename container_traitsC::iterator
::iterator_category
::value };
BOOST_STATIC_CONSTANT( bool, is_contiguous_sequence_container_
= ::boost::is_arrayC::value ||
is_sequence_container_
has_random_access_iterator_ );
};
Comments are more than welcome.
regards
Thorsten
PS: How do you all use BOOST_STATIC_CONSTANT together with typetraits that
takes two parameters? As you can see I had to fall back on an enum.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve wrote: OK, I'll wait for a word from Aleksey. If he is happy I'll heck in the eight patches, both into the trunk and the RC_1_30_0 branch. Yep, they all look good to me. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: It's easy enough to test it with a little program that prints the value you have. OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which EDG version fixes the problem. Is this better? Index: is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,31 #if !defined(__BORLANDC__) --- #if !defined(__BORLANDC__) \ !(defined(__EDG_VERSION__) __EDG_VERSION__ = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. (failed-as-expected) ... **passed** ... unless -d0 caused that to be suppressed, in which case we should remove the -d0 I guess. I don't use -d0, but I don't see that **passed** message anywhere. Something else is not right: The other fail tests are only built once, but the as_to_python_function.cpp test is built each time I enter bjam again. That's why you see the failure on our auto-built test pages. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: how to avoid inclusions?
Thorsten Ottosen [EMAIL PROTECTED] writes:
my code does not include vector, list or map, but it does need
iterator.
Some of the functionality of the container_traits are shown here:
template typename C
bool is_container()
{
return boost::container_traitsC::is_container();
}
...
Yes, you can take an approach like this one, but it will cause false
positives in some circumstances. If that's acceptable for your
application, then it's a good answer.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] writes: --- David Abrahams [EMAIL PROTECTED] wrote: It's easy enough to test it with a little program that prints the value you have. OK, OK, OK, David. I know that MIPSpro == EDG 238, what I don't know is which EDG version fixes the problem. Is this better? Index: is_base_and_derived.hpp === RCS file: /cvsroot/boost/boost/boost/type_traits/is_base_and_derived.hpp,v retrieving revision 1.4 diff -r1.4 is_base_and_derived.hpp 27c27,31 #if !defined(__BORLANDC__) --- #if !defined(__BORLANDC__) \ !(defined(__EDG_VERSION__) __EDG_VERSION__ = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. Should be: #if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \ !BOOST_WORKAROUND(__EDG_VERSION__, = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. (failed-as-expected) ... **passed** ... unless -d0 caused that to be suppressed, in which case we should remove the -d0 I guess. I don't use -d0, but I don't see that **passed** message anywhere. -d0 is being used by the nightly builds, which I suggested for the build runs but not the test runs. Something else is not right: The other fail tests are only built once, but the as_to_python_function.cpp test is built each time I enter bjam again. That's why you see the failure on our auto-built test pages. what command-line are you using? Can you show me the output? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- Ralf W. Grosse-Kunstleve [EMAIL PROTECTED] wrote: I don't use -d0, but I don't see that **passed** message anywhere. Something else is not right: The other fail tests are only built once, but the as_to_python_function.cpp test is built each time I enter bjam again. That's why you see the failure on our auto-built test pages. I take all that back. The messages are printed if I don't specify -d0. And the as_to_python_function.cpp test behaves just like the others. Sorry for the confusion. Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
--- David Abrahams [EMAIL PROTECTED] wrote: Should be: #if !BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x570)) \ !BOOST_WORKAROUND(__EDG_VERSION__, = 238) // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. Sigh. Trying this out right now. If only compilation wouldn't take so long... Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RC_1_30_0 compile error with SGI MIPSpro Compilers
Beman Dawes [EMAIL PROTECTED] writes: At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote: ... I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. Ralf, Thanks for being alert to that. Please post a brief note once you have finished all commits. I haven't really figured out when we will close off RC_1_30_0, but it won't be until Tuesday at the very earliest. I have some Boost.Python things I want to merge into the release. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost talks at ACCU
There are going to be several talks about Boost libraries or related topics at the ACCU conference in Oxford, UK, April 2nd through 5th: * Design and Implementation of the Boost Graph Library by Jeremy Siek * Metaprogramming and the Boost Metaprogramming Library by David Abrahams * The Lambda Library : Unnamed Functions for C++ by Jaako Jarvi * Binding C++ to Python with the Boost Python Library by David Abrahams * Multi-Platform software Development; Lessons from the Boost libraries by Beman Dawes A number of other Boost participants will be speaking on non-boost topics, including Gabriel Dos Reis, Kevlin Henney, Greg Colvin, and Andrei Alexandrescu. More info at http://www.accuconference.co.uk/ --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.0 Schedule [was: RC_1_30_0 compile error with SGI MIPSpro Compilers]
At 07:59 PM 3/7/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote: ... I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. Ralf, Thanks for being alert to that. Please post a brief note once you have finished all commits. I haven't really figured out when we will close off RC_1_30_0, but it won't be until Tuesday at the very earliest. I have some Boost.Python things I want to merge into the release. We'll take stock Tuesday morning [US Eastern time] and see what is left to be done. In the meantime, I'd like any boost developers sitting on user submitted patches to either commit them or to post a message on the list saying why the patch is rejected. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Using weak_ptr with a hash
I just realized that it would be impossible to use weak_ptr with any hash. The problem is that the hash function would have to use weak_ptr's get() method. Then if the underlying object of the weak_ptr gets destroyed, get() will suddenly return 0 instead of the previous pointer, so the hash function will now map the weak_ptr to a new bucket. Is there any way to add a member function that returns a const void * that will be invariant even if the underlying object of the weak_ptr has been destroyed? Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 Schedule [was: RC_1_30_0 compile error with SGIMIPSpro Compilers]
--- Beman Dawes [EMAIL PROTECTED] wrote: At 07:59 PM 3/7/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 05:38 PM 3/7/2003, Ralf W. Grosse-Kunstleve wrote: ... I'll check in the eight patches, both into the trunk and the RC_1_30_0 branch. Ralf, Thanks for being alert to that. Please post a brief note once you have finished all commits. I've checked in all my patches. I couldn't fully test the RC_1_30_0 branch because Aleksey's recent fixes are not there yet. Aleksey, please let me know when the fixes are available on the branch. I will re-run my tests as soon as possible. Until the 1.30.0 release is finished our multi-platform Boost.Python auto-build procedure will use the RC_1_30_0 branch. The results are available at http://cci.lbl.gov/boost/ The last run started before I checked in my patches. The pages are updated approx. every 6 hours (if the Sourceforge CVS server is cooperating). Ralf __ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Using weak_ptr with a hash
What are you trying to do? Usually weak_ptr is used as the value in a map with some other key, so that just being in the map doesn't prevent an object from being deleted. At 06:52 PM 3/7/2003, Joe Gottman wrote: I just realized that it would be impossible to use weak_ptr with any hash. The problem is that the hash function would have to use weak_ptr's get() method. Then if the underlying object of the weak_ptr gets destroyed, get() will suddenly return 0 instead of the previous pointer, so the hash function will now map the weak_ptr to a new bucket. Is there any way to add a member function that returns a const void * that will be invariant even if the underlying object of the weak_ptr has been destroyed? Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Does this compiler need configuring?
On Friday, March 7, 2003, at 4:16 PM, Beman Dawes wrote:
At 03:49 PM 3/7/2003, Howard Hinnant wrote:
[SNIP my previous message]
I'm a Metrowerks expert, but not a boost expert. Your project is set
up to use MSL C which correctly puts ptrdiff_t into namespace std.
The above code can't find ::ptrdiff_t because cstddef only defined
std::ptrdiff_t.
It looks to me like BOOST_NO_STDC_NAMESPACE is being mistakenly
defined somewhere.
Try compiling libs/config/config_info.cpp and running it. The output
will tell you what the configuration looks like. It will identify the
platform, compiler, library, and the important macros defined for
each. Look for macros which are obviously wrong, such as
BOOST_NO_STDC_NAMESPACE.
I can't compile the file; the BOOST_NO_STDC_NAMESPACE mistake results
in a compilation error (which prevents running). How would I override
this particular macro?
I could preprocess the file, and here are the results, removing the
macro printings that result two identical strings (which I think means
that the macro isn't defined at all):
//==
void print_compiler_macros()
{
std::cout Metrowerks CodeWarrior C++ version 0x3003 \n;
print_macro(__cplusplus, =199711L) ;
print_macro(__STDC__, =1) ;
print_macro(__STDC_VERSION__, =199901L) ;
print_macro(__MWERKS__, =0x3003) ;
print_macro(__MSL__, =0x8003) ;
print_macro(__MSL_CPP__, =0x8300) ;
print_macro(__embedded_cplusplus, =0) ;
print_macro(__fourbyteints__, =1) ;
print_macro(__IEEEdoubles__, =1) ;
print_macro(__profile__, =0) ;
print_macro(__powerc, =1) ;
print_macro(__POWERPC__, =1) ;
print_macro(__MACH__, =1) ;
print_macro(__APPLE__, =1) ;
print_macro(powerc, =1) ;
print_macro(__STDC_HOSTED__, =0) ;
}
void print_stdlib_macros()
{
std::cout Metrowerks Standard Library version 0x8300 std::endl;
// No macros in this section were defined (D.W.)
}
void print_platform_macros()
{
std::cout Detected Platform: Mac OS std::endl;
print_sign(char, char()) ;
print_sign(wchar_t, wchar_t()) ;
print_byte_order(byte order for type short, short()) ;
print_byte_order(byte order for type int, int()) ;
print_byte_order(byte order for type long, long()) ;
print_expression(sizeof(wchar_t), sizeof(wchar_t)); ;
print_expression(sizeof(short), sizeof(short)); ;
print_expression(sizeof(int), sizeof(int)); ;
print_expression(sizeof(long), sizeof(long)); ;
print_expression(sizeof(float), sizeof(float)); ;
print_expression(sizeof(double), sizeof(double)); ;
print_expression(sizeof(long double), sizeof(long double)); ;
print_macro(CHAR_BIT, =8) ;
print_macro(CHAR_MAX, =0x7f) ;
print_macro(WCHAR_MAX, =0x7FFFU) ;
print_macro(SHRT_MAX, =0x7fff) ;
print_macro(INT_MAX, =0x7fff) ;
print_macro(LONG_MAX, =0x7fffL) ;
print_macro(LLONG_MAX, =0x7fffLL) ;
print_macro(_POSIX_CHOWN_RESTRICTED, =1) ;
print_macro(_POSIX_JOB_CONTROL, =) ;
print_macro(_POSIX_NO_TRUNC, =1) ;
print_macro(_POSIX_THREAD_ATTR_STACKADDR, =) ;
print_macro(_POSIX_THREAD_ATTR_STACKSIZE, =) ;
print_macro(_POSIX_THREAD_PRIO_INHERIT, =) ;
print_macro(_POSIX_THREAD_PRIO_PROTECT, =) ;
print_macro(_POSIX_THREAD_PRIORITY_SCHEDULING, =) ;
print_macro(_POSIX_THREADS, =) ;
print_macro(_POSIX_VDISABLE, =((unsigned char)'\\377')) ;
print_macro(_POSIX_VERSION, =198808L) ;
print_macro(_POSIX2_VERSION, =199212L) ;
}
void print_boost_macros()
{
std::cout Boost version 102900 std::endl;
print_macro(BOOST_DECL, =) ;
print_macro(BOOST_HAS_GETTIMEOFDAY, =) ;
print_macro(BOOST_HAS_HASH, =) ;
print_macro(BOOST_HAS_LONG_LONG, =) ;
print_macro(BOOST_HAS_PTHREADS, =) ;
print_macro(BOOST_HAS_SCHED_YIELD, =) ;
print_macro(BOOST_HAS_STDINT_H, =) ;
print_macro(BOOST_HAS_SLIST, =) ;
print_macro(BOOST_HAS_THREADS, =) ;
print_macro(BOOST_HAS_UNISTD_H, =) ;
print_macro(BOOST_MSVC6_MEMBER_TEMPLATES, =) ;
print_macro(BOOST_NESTED_TEMPLATE, =template) ;
print_macro(BOOST_NO_CTYPE_FUNCTIONS, =) ;
print_macro(BOOST_NO_CWCHAR, =) ;
print_macro(BOOST_NO_CWCTYPE, =) ;
print_macro(BOOST_NO_MS_INT64_NUMERIC_LIMITS, =) ;
print_macro(BOOST_NO_STDC_NAMESPACE, =) ;
print_macro(BOOST_NO_SWPRINTF, =) ;
print_macro(BOOST_STD_EXTENSION_NAMESPACE, =Metrowerks) ;
}
//==
Daryle
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: possible addition to operators library
On Fri, 07 Mar 2003 22:41:30 +0100, David Abrahams wrote: Very nice remarks, Daniel. I have full confidence in you as the new maintainer of the operators library. Thanks. [Note to myself: Refrain from urging or suggesting other to urge the maintainers :o)] Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ANN: Wave - A Standard conformant C++ preprocessor (was: IntheSpirit of Challenge)
Hi all, Sorry for the somewhat lenghty post, but I hope it will be helpful for someone of you. The Boost.Spirit based C++ preprocessor iterator (the project name is 'Wave') is functionally complete now. All pp operators and pp statements are in place, the macro expansion engine works as expected. So I've released a first version: Wave V0.9.0 (please consider it a beta). Conceptually, the Wave library is a conformant (to the C++ Standard) preprocessing C++ lexer, which exposes an (forward-)iterator interface for iteration over the preprocessed C++ tokens. The main goals for this project are: - full conformance with the C++ standard (INCITS/ISO/IEC 14882/1998) - usage of Spirit for the parsing parts of the game (certainly :-) - maximal usage of STL and/or Boost libraries (for compactness and maintainability) - straightforward extendability for the implementation of additional features (as variadics and placemarkers) - building a flexible library for different C++ lexing and preprocessing needs. At the first steps it is not planned to make a very high performance or very small C++ preprocessor. If you are looking for these objectives you probably have to look at other places. Although the C++ preprocessor should work as expected and will be usable as a reference implementation, for instance for testing of other preprocessor oriented libraries as Boost.Preprocessor et.al. or for developing new pp functionalities. Tests done by Paul Mensonides showed, that the Wave library is very conformant to the C++ Standard, such that it compiles several strict conformant modules written by him, which are even not compilable with EDG based preprocessors (i.e. Comeau or Intel). The C++ preprocessor is not built as a monolitic application, it's rather a modular library, which exposes a context object and an iterator interface. The context object helps to configure the actual pp process (as search path's, predefined macros, etc.). The exposed iterators are generated by this context object too. Iterating over the sequence defined by the two iterators will return the preprocessed tokens, which are generated on the fly from the underlying input stream. The overall preprocessing is a two stage process: input stream (characters) | v +---+ | C++ lexer | (tokenizer) +---+ | v pp tokens | v +---+ |preprocess.| (macro expansion etc.) +---+ | v preprocessed C++ tokens As you can see, the input stream feeds a full C++ lexer module (the generated C++ tokens here are exposed through an iteration interface too). This C++ lexer allows the preprocessing module to work on tokens, not directly on the character stream (performance!), additionally this helps to resolve language ambiguities such as 'some_classincludesome_term ' or similar (see C++ standard 2.1.1.3), which is difficult to do in a one step process. During token generation the C++ lexer does physical source lines splicing into logical source lines (removal of '\\' followed by a '\n'), trigraph and alternative token recognition etc. The exposed C++ lexer iteration interface generates the preprocessing tokens consumed by the preprocessing module, which does the actual work, the preprocessing :-). After this the resulting tokens are converted to C++ tokens exposed by the preprocessor interator. To make the C++ preprocessing library modular, the C++ lexer is held completely separate and independend from the preprocessor (it is actually a template parameter). To proof this concept I've implemented two different full blown C++ lexers (one based on a re2c based C++ lexer written by Dan Nuffer some time ago [VERY fast], the other based on the Spirit based Slex dynamic lexing engine - a table driven DFA [quite compact]). Both lexers are plugable into the preprocessor through a unified iterator interface and are completely interchangeable. BTW the C++ lexers are usable standalone, without using the preprocessing part of the library. It would be very interesting to see, how the other existing and ongoing C++ lexers (see the Spirit examples) fit into the picture. So the user of the final library will be able to decide, which C++ lexer fits best his/her needs. There a couple of things left by now: - report the concatination of unrelated tokens as an error - write a more complete documentation (for now please see the samples) - test the Wave pp iterator more thoroughly There is already some documentation in place, which you may use as a starting point. If this isn't enough, there is a sample driver program for the Wave library (source: cpp.cpp etc.), which fully utilizes the capabilities of the library, so you may look at the source for further information (for now). You can find the Wave library in the Spirit CVS (cvs.spirit.sourceforge.net:/cvsroot/spirit): 'spirit/wave'. Additionally there is a zip file, that can
RE: [boost] 1.30.0 Schedule [was: RC_1_30_0 compile error with SGI MIPSpro Compilers]
Ralf W. Grosse-Kunstleve wrote: I've checked in all my patches. I couldn't fully test the C_1_30_0 branch because Aleksey's recent fixes are not there yet. Aleksey, please let me know when the fixes are available on the branch. They there now. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: possible addition to operators library
On Fri, 07 Mar 2003 11:46:24 +0100, Sam Partington wrote:
Hate to sound pushy, but I've no answer on this, were the patches ok?
Daniel Frey wrote:
No problem. IIRC it was Peter Dimov who came up with the safe-bool
idiom first. At least I saw it first from him. Another way which
works but results in worse error messages is this:
template class T, class B = ::boost::detail::empty_base struct
bool_testable : B
{
private:
operator int() const;
public:
operator bool() const
{
return !!static_cast T ( *this );
}
};
One problem I just found with your implementation (and thus with Peter's
idiom in general) is, that is doesn't provide an operator bool(). This
may sound weird, an example hopefully clears things up:
#include iostream
using namespace std;
#include boost/operators.hpp
struct A : boost::bool_testable A
{
bool operator!() const { cout operator! endl; return false; }
operator int() const { cout operator int() endl; return 42; }
};
int main()
{
A a;
if( a )
cout Hello, world! endl;
// int i = a;
// long l = a;
}
The code above happily compiles without warnings but it calls operator
int(). Several options come to mind:
- Document it that the class T of bool_testable T shall not have any
other operators that might conflict.
- Use the above alternative implementation I showed. It is not as nice as
yours/Peter's wrt error-messages, but it works as expected.
- Convince the standard committee that explicit operator bool is needed
:) See:
http://groups.google.de/groups?hl=delr=ie=UTF-8frame=rightth=d0969f0fa2460dd4seekm=3A2D10EE.35544D0A%40aixigo.de#link1
Thoughts?
Regards, Daniel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
