headers
Thorsten Ottosen | 1 Mar 2004 01:06
Picon
Picon

Re: [math constants] a new approach (perhaps)

"Paul A Bristow" <boost <at> hetp.u-net.com> wrote in message
news:002c01c3ff13$be46d340$0c010101 <at> hetp3...
> Looks interesting - but what is in "math_constant.hpp" ?

David Abrahams:
>So, umm, are you going to show us the definition of "pi"?

Yes, of course. BTW, I've attached the file since
my messages seems to format the code like ****.

br

Thorsten

namespace std
{

#define CNAME( Var ) Var##_constant_t

#define OVERLOAD_CONTEXT( ConstType, FP, FPV )  \
inline FP operator+( FP l, ConstType )          \
{ return l + FPV; }                             \
inline FP operator+( ConstType, FP r )          \
{ return r + FPV; }                             \
inline FP operator-( FP l, ConstType )          \
{ return l - FPV; }                             \
inline FP operator-( ConstType, FP r )          \
{ return FPV - r; }                             \
inline FP operator*( FP l, ConstType )          \
{ return l * FPV; }                             \
(Continue reading)

Permalink | Reply | 32 comments |
headers
Brian McNamara | 1 Mar 2004 01:29
Picon
Favicon

Re: Re: dynamic inheritance with FC++

On Sun, Feb 29, 2004 at 06:50:34AM -0600, Larry Evans wrote:
> On 02/28/2004 06:29 PM, Brian McNamara wrote:
> >        Expr tree           TExpr tree
> >           + <----------------- .
> >          / \                  / \
> >         /   \                /   \
> >        x_    y_            int   int
> >        |\    |\_____________/_____/
> >          \_________________/
> >
> > where the tree on the right contains only the "added data" as well as
> > pointers to the corresponding nodes of the original tree.
> 
> YES!  This is exactly what I want, expressed "most directly" AFAICT,
...
> However, this implementation has a disadvantage.  For example, The
> tree -> first isomorphism, implemented by the regexp_first_constructor
> :: new_from_nilable, would have to create, for the regexp_tree_alt ->
> regexp_first_alt mapping a list<regexp_first_top*> as superclass of
> regexp_first_alt corresponding to the list<regexp_tree_top*>
> superclass of regexp_tree_alt.  This duplicates the list
> overhead. OTOH, the way it's currently coded may be represented as:
> 
>          Expr tree           TExpr tree
>             + <----------------> .
>            / \
>           /   \
>          x_    y_             _int  _int
>          |\    |\             /|    /|
>            \     \___________/     /
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Niebler | 1 Mar 2004 01:36
Picon
Favicon

Re: Tragically pointless?

Daryle Walker wrote:

> You seem to be assuming:
> 
>     The Windows header macros are Boost-hostile
> 
> But from recent posts about the problem, I think:
> 
>     The Windows header macros are Boost-hostile _and_ STL-hostile
> 
> We can "fix" all the Boost code, but we can't change the STL files.  Since
> Boost (pretty much) requires STL, the user is screwed anyway.  This means
> that there was no point in changing our code!

You seem to be assuming that someone hasn't already fixed STL for us. 
They have.  The Dinkumware STL that ships with Visual C++ has been 
minmax-proofed in much the same way as I have just minmax-proofed Boost.

> 
> If we force the user to disable the macros, then the user can do an one-time
> change to his/her code to be Boost/STL compliant _and_ Windows compliant

Why should Boost force users to change their code?

--

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Niebler | 1 Mar 2004 01:41
Picon
Favicon

Re: Solution to Windows' min/max problem?

Daryle Walker wrote:

> 1.  The MS Windows headers define "min" and "max" macros
> 2.  But nothing in those headers _actually needs_ those macros

Try this with VC7.1:

#define NOMINMAX
#include <afxtempl.h>

int main()
{
     CArray<int> array;
     array.SetSize(3);
     return 0;
}

f:\Program Files\Microsoft Visual Studio .NET 
2003\Vc7\atlmfc\include\afxtempl.h(398): error C3861: 'max': identifier 
not found, even with argument-dependent lookup

Regretably, there *is* code out there that require the min/max macros, 
even platform headers.

> So why can't we add:
> 
> #if defined(min) || defined(max)
> #error Define NOMINMAX and use the alternates in <algorithm>
> #endif
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Garland | 1 Mar 2004 03:31

Re: Re: please read! min/max guidelines

On Sun, 29 Feb 2004 09:31:40 -0800, Eric Niebler wrote
> > Daniel Frey <d.frey <at> gmx.de> writes:
> >>I don't like the name of the function, as std_min doesn't hint me
> >>about the ADL-nature of the call. Would adl_std_min be too much
> >>typing? Or propbably just adl_min, as it's quite common to use
> >>std::min if ADL doesn't find a better match. My $.02.
> > 
> > 
> > Looks to me as though boost::min_ is the best name for this thing.
> > 
> 
> I tried to engage people in a discussion of these issues before 
> making 1000+ edit to correct this problem. Now, everybody want to 
> change it. :-P
> 
> This would be a simple search/replace, so I don't mind. Can we all 
> agree on boost::min_? I don't want to have to change it again.

No, I don't think it is worth changing again.  min_ isn't better than std_min
in my view. Put extra comments in the code / docs to explain it.  Changing it
again means all of us will have to re-integrate your new changes.  It's
working, don't mess with it, lets move on.

Jeff

ps: Thx for taking this on.  I haven't personally had to deal with this nasty
bit of windows macro hell, but I'm sure it would have got me sooner or later.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Garland | 1 Mar 2004 04:07

Re: Date_time currently broken with Borland and cygwin?

On Thu, 26 Feb 2004 13:22:46 -0000, John Maddock wrote
> Title says it all, see
> http://boost.sourceforge.net/regression-logs/cs-win32.html

Cygwin is now fixed -- more ripping out of wide string capability...

As for Borland, I don't know what it is complaining about.  Any Borland
experts out there able to decipher this?  The change that set this off was
templatizing some of the string output functions on the char type to support
wide strings.  If no one wants figure it out I'll just pull wstring support
for Borland 5.6.4.  Although I suppose we should file a bug report since the
we are now getting to the point that the rest of the modern compilers are
working. BTW, Borland 5.5.1 in the MetaComm tests suceeds because the new
wstring code is ifdef'ed out...

Jeff

Error details:

C:\boost\site\libs\date_time\build\../src/gregorian/greg_month.cpp:
Error E2426 C:\boost\site\boost/operators.hpp 139: Explicit specialization of
'boost::operator >=(const gregorian::date &,const gregorian::date &)' requires
'template<>' declaration in function gregorian::to_simple_string(const
gregorian::date_period &)
Error E2426 C:\boost\site\boost/operators.hpp 138: Explicit specialization of
'boost::operator <=(const gregorian::date &,const gregorian::date &)' requires
'template<>' declaration in function gregorian::to_simple_string(const
gregorian::date_period &)
Error E2426 C:\boost\site\boost/operators.hpp 137: Explicit specialization of
'boost::operator >(const gregorian::date &,const gregorian::date &)' requires
(Continue reading)

Permalink | Reply | 0 comments |
headers
scott | 1 Mar 2004 04:53
Favicon

RE: Re: [Threads] Simple active object wrapper, take 2

Hi Mark,

You have introduced a third perspective - looks promising. Hope
I can keep track of all the differences and still contribute in some
useful manner.

> [mailto:boost-bounces <at> lists.boost.org]On Behalf Of Mark Blewett
>

<snip>

>
> class MyServant : public Servant
> {
> public:
>          MyServant(Scheduler* scheduler) : Servant(scheduler) {}
>          void do_fn(int x, int y) { std::cout << x << " " <<
> y << std::endl; }
> };
>

> class MyServant : public Servant
> {
> public:
>          MyServant(Scheduler* scheduler) :
> Servant(scheduler), fn(this,
> &MyServant::do_fn) {}
>          MethodProxy<MyServant, int, int> fn;
> private:
>          void do_fn(int x, int y) { std::cout << x << " " <<
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Mar 2004 05:25
Picon
Favicon

[Boost-bugs] [ boost-Bugs-907276 ] ha ha very funy........idiots!

Bugs item #907276, was opened at 2004-02-29 20:25
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907276&group_id=7586

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ha ha very funy........idiots!

Initial Comment:
you have a neat site, but it says you are not authorized 
to view this file.

very amusing...corporation...bast...idiots!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907276&group_id=7586

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Torjo | 1 Mar 2004 07:00

Re: small addition to functional

Peter Dimov wrote:

>John Torjo wrote:
>  
>
>>Imagine this:
>>
>>struct test {
>>   int i;
>>   std::string s;
>>};
>>std::vector<test> tests;
>>// ... fill
>>
>>void set(int & i, int val) { i = val };
>>int val = 10;
>>// for each obj from vector, set obj.i = val;
>>std::for_each( tests.begin(), tests.end(), bind(&decrement,
>>bind(mem_fn(&test::i),_1), val);
>>    
>>
>
>Out of curiosity, do you really need this functionality?
>
>  
>
Yup, that's how I came up with it ;)
The truth is that not very often, but yes, I do need it at times.

>The current implementation fails with the above example because of its
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 1 Mar 2004 06:54
Picon
Favicon

[Boost-bugs] [ boost-Bugs-907299 ] Miss " = ParserT()"

Bugs item #907299, was opened at 2004-02-29 21:54
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=907299&group_id=7586

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Miss " = ParserT()"

Initial Comment:
\boost\spirit\core\scanner\skipper.hpp

101 skip_parser_iteration_policy(
102     ParserT const& skip_parser,
103     base_t const& base = base_t())
104 : base_t(base), subject(skip_parser) {}

"no_node_d" can&#039;t be used.

Fixed:
101 skip_parser_iteration_policy(
102     ParserT const& skip_parser = ParserT(),
103     base_t const& base = base_t())
104 : base_t(base), subject(skip_parser) {}
(Continue reading)

Permalink | Reply | 0 comments |

Gmane