headers
David Abrahams | 1 Feb 2004 03:37
Picon
Picon
Favicon
Gravatar

Re: mpl functions, pow_, root_, reciprocal

"Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:

>> This is not the "traditional" use of trailing underscores. Normally they
>> are used for keywords.
>>
>>    int -> int_
>>    bool -> bool_
>>
>> etc. MPL uses tons of names that clashes with names in std. This is a
>> problem for the user, not the library.
>
> I am attempting to write a libaray for 'users'. 

Many 'users' don't use using-declarations and won't appreciate having
perfectly usable names uglified with extra underscores, or having
names in mpl:: which don't follow the MPL conventions.

> Its my problem.
> Is the mpl namespace regarded as a 'user interface' ?

If we're putting the names in mpl::, they should follow the same
conventions as the rest of the library.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Feb 2004 03:47
Picon
Picon
Favicon
Gravatar

Re: problem with new iterators in 1.31 Release candidate # 2

Robert Ramey <ramey <at> rrsd.com> writes:

> I have a problem with the latest version of the new iterators.
> This is illustrated in the following example.
>
> #include <strstream>
> #include <iterator>
> #include <boost/iterator/counting_iterator.hpp>
>
> main(){
> 	std::istrstream is("abcdefg");
> 	typedef boost::counting_iterator<std::istream_iterator<char> > ci;
> 	const ci end = std::istream_iterator<char>();  // note the const !!!

I don't see why the const should be relevant.

> 	ci begin = std::istream_iterator<char>(is);

Hmm, the implicit conversions from istream_iterator to the
counting_iterator above are troubling.  I think those constructors
should be explicit.

> 	unsigned int size;
>
> 	// the following should fail at compilation ?

Why?  OK, maybe it would be better to make it fail because the
iterator is not in fact a random-access iterator.

> 	// in fact it compiles are returns a value of -7 !!!
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Feb 2004 03:39
Picon
Picon
Favicon
Gravatar

Re: mpl functions, pow_, root_, reciprocal

"Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:

>> These aren't very interesting metafunctions, since they're all
>> equivalent to mpl::always<implementation_defined> ;-)
>
> Oops sorry perhaps read 'undefined',' user defined' not implementation
> defined :-)

My point was to say that you are proposing we add something to the
library, but you haven't shown us anything but a sketch of a few empty
metafunctions.  How can anyone comment?

> Not to stay that way just havent had time to write some simple examples.
> (pow_<int_,int_> should be easy!) Could use one of my own  but doesnt mean
> much to many  -->
>
> The problem is I have specialised plus, minus, multiplies etc. for use in
> 'expression templates'. (think is right term).
> However it would be odd to put these in separate namespace. 

?? Specializations can only go in the same namespace as the primary
template.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 24 comments |
headers
David Abrahams | 1 Feb 2004 04:08
Picon
Picon
Favicon
Gravatar

Re: ICE with is_abstract on VC 7.0

Robert Ramey <ramey <at> rrsd.com> writes:

> When I compile anything that includes is_abstract.hpp
> I get a compiler ICE with VC 7.0
>
> since is_abstract.hpp is included by type_traits.hpp
> it means that a large part of boost 1.31 release candidate 2
> is now uncompilable on this platform.
>
> is_abstract was known to test the limits of  many
> platforms.  It is incredible to me that this could
> be dropped into "release candidate # 2" without
> having been part of the development tree for
> a reasonable amount of time.

I had the same reaction.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Andy Little | 1 Feb 2004 07:55
Picon
Picon

Re: mpl functions, pow_, root_, reciprocal


"David Abrahams" <dave <at> boost-consulting.com> wrote
> "Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:

[snip]

> ?? Specializations can only go in the same namespace as the primary
> template.

but not derived ;-).

1)  Can there be some operators representing power,root and reciprocal in
mpl?
2)  If 1), what names can mpl connoiseurs provide?

Any feedback welcome.

regards
Andy little

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 1 comment |
headers
Andy Little | 1 Feb 2004 09:57
Picon
Picon

Re: mpl functions, pow_, root_, reciprocal


"David Abrahams" <dave <at> boost-consulting.com> wrote in message
news:ur7xfv7yt.fsf <at> boost-consulting.com...
> "Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:
>
> >> These aren't very interesting metafunctions, since they're all
> >> equivalent to mpl::always<implementation_defined> ;-)
> >
> > Oops sorry perhaps read 'undefined',' user defined' not implementation
> > defined :-)
>
> My point was to say that you are proposing we add something to the
> library,

Whoa ! First I decide against using mpl at all. I was accused of being
'ad-hoc'. I decide to try it. I find a problem. Next I posted a question on
users about how to integrate a power function with mpl. NOTE the "Ideally"
in second line !!! Here is Alexei Gurtovoys reply:

"
Andy Little wrote:
> Hi,

Hi Andy,

> I am implementing the mpl math operators for my physical_quantities type.
> Ideally I would like to declare a boost::mpl::power<A,B> metafunction.
> I would like to do:
>
>         typedef  Power_type<...>  P  ;
(Continue reading)

Permalink | Reply | 21 comments |
headers
Pavel Vozenilek | 1 Feb 2004 10:34
Picon
Favicon

Re: ICE with is_abstract on VC 7.0


"Robert Ramey" <ramey <at> rrsd.com> wrote

> When I compile anything that includes is_abstract.hpp
> I get a compiler ICE with VC 7.0
>
> since is_abstract.hpp is included by type_traits.hpp
> it means that a large part of boost 1.31 release candidate 2
> is now uncompilable on this platform.
>
Boost.Config should be appended with new macro (BOOST_NO_SUPPORT_FOR_DR337
or better name) and is_abstract.hpp conditionally included.

Current regression test results can be used to check out which compilers
handle is_abstract<>.

/Pavel

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 4 comments |
headers
Momchil Velikov | 1 Feb 2004 10:33
Picon

Re: [filesystem] On POSIX, any reliable way to find file size?

>>>>> "Beman" == Beman Dawes <bdawes <at> acm.org> writes:
    Beman> The implementation would go something like this:

    Beman>     #if defined( BOOST_WINDOWS )
    Beman>        // use the Windows native API; file_offset_type is long long.
    Beman>        ...
    Beman>     #else
    Beman>        #define _FILE_OFFSET_BITS 64 // this may or may not do anything
    Beman>        // use stat(); file_offset_type is same as off_t,
    Beman>        // which may be 32-bits on 32-bit platforms which don't
    Beman>        // respond to _FILE_OFFSET_BITS
    Beman>        ...
    Beman>     #endif

  All files must be compiled with the same _FILE_OFFSET_BITS.  You
don't want to get binary incompatible objects just because one
happened to include the above header[1] and the other didn't.

~velco

[1] The program may have reasons to use struct stat independed of the
presence of boost.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 3 comments |
headers
David Abrahams | 1 Feb 2004 13:22
Picon
Picon
Favicon
Gravatar

Re: mpl functions, pow_, root_, reciprocal

"Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:

> "David Abrahams" <dave <at> boost-consulting.com> wrote
>> "Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:
>
> [snip]
>
>> ?? Specializations can only go in the same namespace as the primary
>> template.
>
> but not derived ;-).

That sentence fragment is incomprehensible to me.

> 1)  Can there be some operators representing power,root and reciprocal in
> mpl?

Sounds good to me.

> 2)  If 1), what names can mpl connoiseurs provide?

Your names seem fine to me, except for the needless trailing underscores.

--

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Abrahams | 1 Feb 2004 13:39
Picon
Picon
Favicon
Gravatar

Re: mpl functions, pow_, root_, reciprocal

"Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:

> "David Abrahams" <dave <at> boost-consulting.com> wrote in message
> news:ur7xfv7yt.fsf <at> boost-consulting.com...
>> "Andy Little" <andy <at> servocomm.freeserve.co.uk> writes:
>>
>> >> These aren't very interesting metafunctions, since they're all
>> >> equivalent to mpl::always<implementation_defined> ;-)
>> >
>> > Oops sorry perhaps read 'undefined',' user defined' not implementation
>> > defined :-)
>>
>> My point was to say that you are proposing we add something to the
>> library,
>
> Whoa ! 

Whoa, what?  Are you not proposing we add something to the library?

> First I decide against using mpl at all. I was accused of being
> 'ad-hoc'. I decide to try it. I find a problem. Next I posted a question on
> users about how to integrate a power function with mpl. NOTE the "Ideally"
> in second line !!! Here is Alexei Gurtovoys reply:

<snip>

Whoa! I saw Aleksey's reply when he posted it.  What's your point?

>> but you haven't shown us anything but a sketch of a few empty
>> metafunctions.  How can anyone comment?
(Continue reading)

Permalink | Reply | 20 comments |

Gmane