headers
Aleksey Gurtovoy | 1 Aug 01:45
Favicon
Gravatar

Re: [mpl] Integral Constant is over specified

Andy Little writes:
> The boost type_traits integral constant is derived from
> mpl::integral_c which has a tag type member, without which
> boost:::integral_constant wouldnt work with mpl types such as
> equal_to. The std version doesnt specify the tag, nor does the boost
> type_traits version in its documentation. Without the tag,
> boost::integral_constant would not work with mpl types such as
> equal_to as demonstrated in another mail in this thread. Therefore
> changing from boost::integral_constant to std::integral_constant
> will break code that uses mpl. Maybe its not important, but the
> innocent std:: integral_constant will appear to be bug ridden.

Ideally, I'd like to link the '::tag' requirement with the mixed-type
arithmetic operations (for which the tag was introduced) and move it
out of the Integral Constant requirements into a corresponding
concept. Either way, making the above work is not a major issue.

--

-- 
Aleksey Gurtovoy
MetaCommunications Engineering
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Joe Van Dyk | 1 Aug 01:49
Picon
Gravatar

Getting a xsd:datetime from boost::date_time

Hi,

(sorry if this is off topic)

I need to get the current date and time and convert it into a string
that follows the xsd:datetime time stamp format:
[-]CCYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm].

(timezone should be UTC)

Any ideas on how to do that?  The Boost::Date_Time library
documentation is confusing to my feeble mind.

Thanks,
Joe
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 3 comments |
headers
Aleksey Gurtovoy | 1 Aug 01:52
Favicon
Gravatar

Re: [mpl] Integral Constant is over specified

David Abrahams writes:
> "Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:
>> The std version doesnt specify the tag, nor does the boost
>> type_traits version in its documentation. Without the tag,
>> boost::integral_constant would not work with mpl types such as
>> equal_to as demonstrated in another mail in this thread. Therefore
>> changing from boost::integral_constant to std::integral_constant
>> will break code that uses mpl. Maybe its not important, but the
>> innocent std:: integral_constant will appear to be bug ridden.
>
> I see no requirement that a `tag' type member be included in
> http://boost.org/libs/mpl/doc/refmanual/integral-constant.html.
> However, it does look like the current implementation of equal_to
> depends on the presence of `tag'.  I'm not sure what the plan was
> here; Aleksey?

Please see http://article.gmane.org/gmane.comp.lib.boost.devel/146324.

--

-- 
Aleksey Gurtovoy
MetaCommunications Engineering
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Aleksey Gurtovoy | 1 Aug 02:19
Favicon
Gravatar

Re: Boost regression testing status

Gennaro Prota writes:
> On Mon, 31 Jul 2006 14:11:58 -0500, Aleksey Gurtovoy
> <agurtovoy <at> meta-comm.com> wrote:
>
>>Gennaro Prota writes:
>>> About the regression test mess, dynamic_bitset is not listed in the
>>> report, but has some "red" failures 
>>
>>A "red" failure indicates a regression from the last-known-good
>>release, whether the toolset is marked as required or not, so it's
>>perfectly normal to have these present on the library's page and
>>absent from the Issues page.
>
> Ok. I realized this afterwards.
>
>>> on compilers which I don't think were tested before (which I've
>>> discovered by chance);
>>
>>Which compilers, and why do you think they weren't tested before?
>
> Not sure, but I don't remember dynamic_bitset<> being regression
> tested on CW 8.3.

Well, it was:
http://engineering.meta-comm.com/boost-regression/1_33_1/developer/dynamic_bitset_release.html

>>> and cases where the same compiler passes or not depending on the
>>> test runner (e.g.  VC7).
>>
>>That happens, and when it does, it needs investigation.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gennaro Prota | 1 Aug 03:42
Picon
Favicon

Re: Boost regression testing status

On Mon, 31 Jul 2006 19:19:45 -0500, Aleksey Gurtovoy
<agurtovoy <at> meta-comm.com> wrote:

>Surely there is a lot of room for improvement (as illustrated by
>http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Testing),
>but the above sounds like you think they are in flux, and if so, you
>should list the particular issues that led you to this conclusion, or
>otherwise it's FUD. For instance, surely you could check 1.33.1 report
>pages before making the claim that dynamic_bitset wasn't tested with
>CW 8.3 (or any other toolset)?

Yes. The "particular issues which led me to this conclusion" are
listed in the initial post of this thread. Surely you could read a
little above before making the claim that anyone spreads FUD,
especially when it comes to people who is being here for years.

That said, I don't think I've much more to add to this thread.

--
[ Gennaro Prota, C++ developer for hire ]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Gennaro Prota | 1 Aug 03:51
Picon
Favicon

Where to place tests for BOOST_WORKAROUND?

Hi guys,

despite proceeding on it by fits and starts I've completed the work on
the new compiler identification macros. Since Rene asked for them to
be committed after the 1.34 release they are still on hold
(/auto-censorship here/) however I'd like to add tests for the new
BOOST_WORKAROUND macro. The question is: it was, and is, a sort of
private tool for boost developers, as its placement in the detail/
subdirectory emphasizes, so we probably (uncertainty and doubt) don't
want its test results to show in the regression reports. If so, where
should those tests go?

--
[ Gennaro Prota, C++ developer for hire ]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |
headers
Emil Dotchevski | 1 Aug 05:21
Picon

Re: Boost Exception

Brad King wrote:
> Emil Dotchevski wrote:
>> I posted the new version of the proposed Boost Exception library last
>> Friday, you can get the new documentation and code here:
>>
>> http://www.revergestudios.com/boost-exception/boost-exception.htm.
>
> I've just briefly glanced through the current implementation and some
> of
> the discussion earlier on the boost list.  It looks pretty nice so
> far.
>
> If it is not mentioned already in the documentation you should add an
> explanation of why boost::exception does not derive from
> std::exception.
> I'm guessing it's so that enable_exception_info works for types that
> derive from std::exception without diamond inheritance.  User-defined
> subclasses of boost::exception can also derive from std::exception
> anyway.

Your guess is correct: enable_exception_info is designed to integrate the 
exception library with existing programs, where modifying the exception 
class hierarchy could introduce subtle and hard to detect bugs in existing 
exception handling code. Because such hierarchies commonly derive from 
std::exception, if boost::exception also derives from std::exception this 
would result in unwanted double inheritance. Thanks for the tip, I already 
added this explaination in the FAQ.

>> I have received two suggestions by email to remove the use of macros
>> for type registration.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Beman Dawes | 1 Aug 05:13
Picon
Favicon
Gravatar

Re: [endian] Comments on Endian 0.5


"Dave Dribin" <dave-ml <at> dribin.org> wrote in message 
news:F773AA4D-E17B-4FB2-B872-116B17E7715B <at> dribin.org...
> Hello,
>
> I started a thread on Boost-users about the proposed endian library,
> but it's probably more suitable on the dev list.  Here's a link to
> the thread in the archives:
>
>   <http://lists.boost.org/boost-users/2006/07/20887.php>
>
> I see two issues with the library as  of 0.5.  First, the endian
> classes cannot be used in unions.

Yep, that's a problem. But it goes beyond union requirements - the class 
needs to be changed be POD's. The primary use is I/O, and that means they 
need to be memcpyable. And that means they must be POD's.

I know some have argued that both POD and non-POD versions should be 
supplied, but I don't want to depend on undefined behavior, which is what 
will happen with a non-POD endian class. Constructors can be added later if 
the committee decides to relax the POD requirements.

>  And, second the classes cannot be
> used in variable argument lists.  I'm attaching a patch to help
> resolve both of these issues.
>
> In order to be used in a union, a class must not have any
> constructors.  However, removing constructors breaks the following code:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Frederick Akalin | 1 Aug 05:38

Re: Numerical integration library?

"Numerical integration" is often loosely used to mean quadrature, ODE  
solving, and PDE solving.  I was just following the terminology on  
the Wiki; I'm sorry if I wasn't clear.

I was talking about ODE solving in my original e-mail, but of course  
there might be a need for PDE solving and quadrature libraries, too.   
That PDE library looks interesting, although I don't have much  
experience with solving PDEs.  It looks like a bunch of people have  
quadrature routines, too, so it might be beneficial to integrate that  
into a coherent library.

Anyway, I hacked up an example program demonstrating what I'm talking  
about, available at: http://akalin.cx/boost/ode_solver_example.cpp ,  
which should be compilable by itself.  The interesting stuff is the  
classes at the top.  Some notes:

- The step routines are taken straight out of a numerical analysis  
reference.  Note that they are completely container-agnostic, so they  
can be used with floats, vectors of floats, vectors of particles  
which have their own floats, etc.  Other libraries are more  
restricted.  For example, the GSL library routines only work with  
double arrays: http://www.gnu.org/software/gsl/manual/html_node/ 
Ordinary-Differential-Equations.html#Ordinary-Differential- 
Equations .  Also, the ODE++ library ( http://www.minet.uni-jena.de/ 
www/fakultaet/iam/ode++/ode++_e.html#Problem ) requires adapting your  
code to their framework, including using their vector/matrix classes.  
(I only took a cursory look at the documentation -- correct me if I'm  
misrepresenting anything)
- I haven't done any performance tests, but it seems to me that a  
reasonably smart container/adapter (with expression templates) would
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aleksey Gurtovoy | 1 Aug 06:11
Favicon
Gravatar

Re: Boost regression testing status

Gennaro Prota writes:
> On Mon, 31 Jul 2006 19:19:45 -0500, Aleksey Gurtovoy
> <agurtovoy <at> meta-comm.com> wrote:
>
>>Surely there is a lot of room for improvement (as illustrated by
>>http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost.Testing),
>>but the above sounds like you think they are in flux, and if so, you
>>should list the particular issues that led you to this conclusion, or
>>otherwise it's FUD. For instance, surely you could check 1.33.1 report
>>pages before making the claim that dynamic_bitset wasn't tested with
>>CW 8.3 (or any other toolset)?
>
> Yes. The "particular issues which led me to this conclusion" are
> listed in the initial post of this thread. 

All of them but one are perfectly ordinary environment/linking issues,
no? OK, may be they are not normal that far in the release cycle, but
that's hardly a "regression test mess".

>    - For some failures no error message is reported, so that it
>      is pretty much impossible for the developer to fix them; e.g.:
>      http://tinyurl.com/zmpwk

We will look into this one.   

> Surely you could read a little above before making the claim that
> anyone spreads FUD, especially when it comes to people who is being
> here for years.

I did.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane