boost facilities for determining whether or not a type supports particularsyntax?

[Howard Gardner]

/*

If I am using boost, then how should I write this program?

As it sits, this program is using SFINAE to determine whether
or not a type supports particular syntax. I suspect that there
is functionality in boost to do this.

I have found mpl::has_xxx, which I suspect of being part of the
solution. I've also found type_traits::has_nothrow_constructor
(etc.), which I suspect of using the solution: unfortunately, those
implementations are rotten with unfamiliar macros, which makes
them hard to follow.

What I'm looking for is an approachable sample of using the
relevant boost facility.

*/

#include <fstream>
using std::cout;
using std::endl;

template< typename x, typename xSyntax >
struct supports_syntax
{
private:
typedef char ret_true;
struct ret_false{ char c[2]; };

template< typename xTested >
static
ret_false
func( ... );

template< typename xTested >
static
ret_true
func( typename xSyntax::template match< xTested > * );

public:
static
const bool
value
= ( sizeof( func< x >( 0 ) ) == sizeof( ret_true ) );
};

template< typename xParm >
struct syntax_insert
{
template< typename y, y & (y::*)( xParm ) = &y::insert >
struct match;
};

struct syntax_type
{
template< typename y, typename xType = typename y::type >
struct match;
};

struct yes
{
yes &
insert( char );

template< typename xWhat >
yes &
insert( const xWhat & );

typedef int type;
};

struct no
{
};

int
main()
{
cout
<< supports_syntax< yes, syntax_insert< char > >::value
<< endl;

cout
<< supports_syntax< no, syntax_insert< char > >::value
<< endl;

cout
<< supports_syntax< yes, syntax_insert< const float & > >::value
<< endl;

cout
<< supports_syntax< no, syntax_insert< const float & > >::value
<< endl;

cout
<< supports_syntax< yes, syntax_type >::value
<< endl;

cout
<< supports_syntax< no, syntax_type >::value
<< endl;
}

[Phlip]

Howard Gardner wrote:

If I am using boost, then how should I write this program?

You will get better results on the Boost-User mailing list.

This newsgroup works best when it focusses on platform-neutral C++. Boost is
interesting, and is topical when we connect it back to generic C++, but not
when we discuss its innards.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Howard Gardner]

Phlip wrote:

Howard Gardner wrote:

If I am using boost, then how should I write this program?

You will get better results on the Boost-User mailing list.

This newsgroup works best when it focusses on platform-neutral C++. Boost is
interesting, and is topical when we connect it back to generic C++, but not
when we discuss its innards.

The stl was perfectly on-topic before it became part of the standard
library. boost is perfectly on topic now.

[Alf P. Steinbach]

* Howard Gardner:

Phlip wrote:

Howard Gardner wrote:

If I am using boost, then how should I write this program?

You will get better results on the Boost-User mailing list.

This newsgroup works best when it focusses on platform-neutral C++.
Boost is interesting, and is topical when we connect it back to
generic C++, but not when we discuss its innards.

The stl was perfectly on-topic before it became part of the standard
library. boost is perfectly on topic now.

I agree.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Roland Pibinger]

On Sat, 22 Apr 2006 18:39:18 +0200, "Alf P. Steinbach"
<al***@start.no> wrote:

The stl was perfectly on-topic before it became part of the standard
library. boost is perfectly on topic now.

I agree.

Boost is a set of experimental template programming libraries which
have almost no overlap with real-world C++ programming.

Best regards,
Roland Pibinger

[Howard Hinnant]

In article <4a************@individual.net>,
"Alf P. Steinbach" <al***@start.no> wrote:

* Howard Gardner:

Phlip wrote:

Howard Gardner wrote:

If I am using boost, then how should I write this program?

You will get better results on the Boost-User mailing list.

This newsgroup works best when it focusses on platform-neutral C++.
Boost is interesting, and is topical when we connect it back to
generic C++, but not when we discuss its innards.

The stl was perfectly on-topic before it became part of the standard
library. boost is perfectly on topic now.

I agree.

Parts of boost that the OP mentioned, type_traits, got voted into the
C++0X working draft two weeks ago. :-)

-Howard

[Howard Hinnant]

In article <44**************@news.utanet.at>,
rp*****@yahoo.com (Roland Pibinger) wrote:

Boost is a set of experimental template programming libraries which
have almost no overlap with real-world C++ programming.

Yeah, no one uses reference counted smart pointers, generic function
adaptors, heterogeneous containers (tuples), regular expressions,
multithreading, graph structures, date-time utilities, file system path
manipulation, ... ;-)

-Howard

[Markus Schoder]

Roland Pibinger wrote:

Boost is a set of experimental template programming libraries which
have almost no overlap with real-world C++ programming.

This is simply an amazing statement. How one could arrive at such a
conclusion is beyond me. I use many boost libraries for my everyday
work and found the exact opposite of your statement to be true.

boost has a very stringent review process. The level of documentation
is outstanding. The number of supported compilers is unbelievable.
There are workarounds for broken or feature challenged compilers that
boggle the mind. You can use most of the boost libraries on a POS like
VC++ 6.

Calling such an effort "experimental" is nothing short of an insult to
the boost developers.

[Howard Gardner]

Markus Schoder wrote:

Roland Pibinger wrote:
This is simply an amazing statement. How one could arrive at such a
conclusion is beyond me. I use many boost libraries for my everyday
work and found the exact opposite of your statement to be true.

Do you, by chance, know how to write my example :)

[Alf P. Steinbach]

* Howard Gardner:

Markus Schoder wrote:

Roland Pibinger wrote:
This is simply an amazing statement. How one could arrive at such a
conclusion is beyond me. I use many boost libraries for my everyday
work and found the exact opposite of your statement to be true.

Do you, by chance, know how to write my example :)

Not sure if this helps, but have a look at

<url: http://www.boost.org/libs/concept_check/concept_check.htm>

and

<url:
http://www.neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_traits/doc/>.

It might be that your code isn't directly what you wish to achieve, and
that the URLs above might help you achieve what you're really after.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Howard Hinnant]

In article <KB*****************@tornado.tampabay.rr.com>,
Howard Gardner <hg******@rawbw.com> wrote:

As it sits, this program is using SFINAE to determine whether
or not a type supports particular syntax. I suspect that there
is functionality in boost to do this.

I have found mpl::has_xxx, which I suspect of being part of the
solution. I've also found type_traits::has_nothrow_constructor
(etc.), which I suspect of using the solution: unfortunately, those
implementations are rotten with unfamiliar macros, which makes
them hard to follow.
has_nothrow_constructor can not be done without compiler help to the
best of my knowledge. is_pod will approximate it, but that also needs
compiler help to be done correctly. is_scalar will approximate is_pod,
and is done by relatively mundane techniques.
What I'm looking for is an approachable sample of using the
relevant boost facility.

BOOST_MPL_HAS_XXX_TRAIT is as probably as close as you're going to get.
Fwiw, I've been writing my has_xxx traits classes separately, each time
I need one. So far that hasn't been a burden as I haven't needed one
very often, and when I do, there are often other constraints I'm looking
for at the same time, making a general purpose has_xxx less attractive
anyway (e.g. has a nested type named iterator_category AND that type is
convertible to std::input_iterator tag).

Your framework looks quite reasonable.

-Howard

[Howard Gardner]

Alf P. Steinbach wrote:

Not sure if this helps, but have a look at

<url: http://www.boost.org/libs/concept_check/concept_check.htm>

and

<url:
http://www.neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_traits/doc/>.

The facility that I am hoping to find might very well be described as
"use the boost::concept_check facility to create numerical metafunctions."

If that has already been done, I don't see it. If not, maybe I can write
it. In either case, thank you for the links.

[Howard Gardner]

Howard Hinnant wrote:

What I'm looking for is an approachable sample of using the
relevant boost facility.
BOOST_MPL_HAS_XXX_TRAIT is as probably as close as you're going to get.
Fwiw, I've been writing my has_xxx traits classes separately, each time
I need one. So far that hasn't been a burden as I haven't needed one
very often, and when I do, there are often other constraints I'm looking
for at the same time, making a general purpose has_xxx less attractive
anyway (e.g. has a nested type named iterator_category AND that type is
convertible to std::input_iterator tag).

Your framework looks quite reasonable.

It has several major faults. First, I have to maintain it. Second, it
suffers from the problem that you are describing: there's an infinite
set of "potentially interesting syntax." Third, the mechanics beg for
generalization.

I really don't want to spend a lot of time creating and maintaining such
a facility if someone else will do it for me!

Elsewhere in this thread, Alf P. Steinbach directed me to:

http://www.boost.org/libs/concept_ch...cept_check.htm

Which might form part of the solution (if it is possible to turn those
concept checks into numerical metafunctions).

And also to:

http://www.neoscientists.org/~tschwi...pt_traits/doc/

which looks like it is just the ticket. It appears to be new code,
though, and I haven't tried it yet. The docs say that it covers the
builtin operators, concepts from std::, concepts from boost::mpl::, and
that it provides a mechanism for adding more concepts.

[Phlip]

Howard Gardner wrote:

Elsewhere in this thread, Alf P. Steinbach directed me to:

http://www.boost.org/libs/concept_ch...cept_check.htm

That's because Alf wants to change this newsgroup into a boost forum.

;-)

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Phlip]

Howard Gardner wrote:

You will get better results on the Boost-User mailing list.

The stl was perfectly on-topic before it became part of the standard
library. boost is perfectly on topic now.

That doesn't mean you will get the best results here.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Howard Gardner]

Phlip wrote:

Howard Gardner wrote:

Elsewhere in this thread, Alf P. Steinbach directed me to:

http://www.boost.org/libs/concept_ch...cept_check.htm

That's because Alf wants to change this newsgroup into a boost forum.

;-)

I suspect that he is going to get his wish then. There is a lot of
compelling functionality in boost, but with the best will in the world I
cannot say that it is easy to learn to use it. It is going to take lots
and lots of discussion before we can all use it as effectively as we can
use the standard library.

[Roland Pibinger]

On Sun, 23 Apr 2006 18:52:09 GMT, Howard Gardner <hg******@rawbw.com>
wrote:

There is a lot of
compelling functionality in boost, but with the best will in the world I
cannot say that it is easy to learn to use it. It is going to take lots
and lots of discussion before we can all use it as effectively as we can
use the standard library.

But why would you do that? Libraries for everyday use are simple,
convenient and comprehensible, designed with 'KISS' in mind. Boost is
the opposite of 'KISS'. Boost was founded in the late nineties to
'boost' (hence the name) generic programming in the tradition of STL.
By definition Boost always was experimental, especially in exploring
the limits of template programming. It was never targeted at Joe
Programmer.
Recommending Boost to a real-world programmer is like recommending a
race-car to someone who wants to drive to work. Sure, the race car has
better acceleration, better top-speed, better brakes, ... but it isn't
the better car for the rush hour.

Best wishes,
Roland Pibinger

[Howard Gardner]

Roland Pibinger wrote:

On Sun, 23 Apr 2006 18:52:09 GMT, Howard Gardner <hg******@rawbw.com>
wrote:

There is a lot of
compelling functionality in boost, but with the best will in the world I
cannot say that it is easy to learn to use it. It is going to take lots
and lots of discussion before we can all use it as effectively as we can
use the standard library.
But why would you do that? Libraries for everyday use are simple,
convenient and comprehensible, designed with 'KISS' in mind.

There are a lot of ways to do something to each element of a standard
container. Here are three:

1) iterating it with a for loop

2) calling for_each using only the facilities in the standard library
and whatever you write for yourself.

3) calling for_each using boost::lambda, boost::bind, and boost::function

Which is simplest? More importantly, why?
Boost is
the opposite of 'KISS'. Boost was founded in the late nineties to
'boost' (hence the name) generic programming in the tradition of STL.
Whatever they set out to do, what they have actually done is create an
extremely well conceived, cleanly designed, solidly implemented,
thoroughly documented, and widely distributed collection of compellingly
useful facilities. Just being beautiful and elegant does not make it bad.

I'm having a hard time learning it strictly because I haven't got my
mental map of "problem->boost::solution" pairs built yet. Its a big
library, and there's a lot of stuff in it that I haven't used at all,
and an even more that I haven't used much.

The parts that I *have* used are stunningly effective. As a matter of
fact, my experience has been that replacing my own facilities with boost
facilities makes the rest of my code better *even though my facilities
were usually built specifically to address the needs of the rest of my
code.*

Maybe my facilities are just lousy. I'd rather believe that the boost
facilities are exceptionally good. I'm happier that way.
By definition Boost always was experimental, especially in exploring
the limits of template programming. It was never targeted at Joe
Programmer.
Some of the facilities in boost are definitely aimed at Joe Programmer,
even if Joe Programmer is just banging out thin applications.

I think that at this point Joe Programmer really ought to be dedicating
some serious thought to building high-utility, high-quality libraries
for his employer by the way. If Joe Programmer is solving a problem from
scratch for the fourth time, then Joe Programmer is seriously slacking.
Recommending Boost to a real-world programmer is like recommending a
race-car to someone who wants to drive to work. Sure, the race car has
better acceleration, better top-speed, better brakes, ... but it isn't
the better car for the rush hour.

Real world programmers are in a race, not stuck in rush hour. That's
fortunate, because no one goes very fast in rush hour.