By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,309 Members | 2,035 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,309 IT Pros & Developers. It's quick & easy.

problem with SFINAE applied to class methods

P: n/a
Hello

I am trying to do some template metaprogramming involving enabling or
disabling a method in a parameterised class based on some condition. I
am trying to use the Boost enable_if mechanism to do this, using the
SFINAE principle. Here is a simple example showing what I am trying to do:

1 #include <iostream.h>
2 #include <boost/utility/enable_if.hpp>
3
4 using namespace boost;
5
6 template <bool CanFoo> class A {
7
8 public:
9 typename enable_if_c<CanFoo>::type foo() {
10 cout << "Foo" << endl;
11 }
12
13 };
14
15 int main(int argc, char** argv) {
16 A<false> cant_foo;
17 cant_foo.foo();
18 A<true> can_foo;
19 can_foo.foo();
20 }

In this example the foo method in the A class is supposed to only exist
when the boolean template parameter is true, thus I expect only one
compiler error to occur on line 17. However when compiling this code I
get the following additional message from the compiler (gcc 3.2.2):

traits.cc: In instantiation of `A<false>':
traits.cc:16: instantiated from here
traits.cc:9: no type named `type' in `struct boost::enable_if_c<false, void>'

Obviously there is not meant to be a type 'type' in this struct, which
is what SFINAE is all about! Is this a bug in the compiler or am I
misunderstanding the principle? If so can someone suggest an alternative
way to do what I want?

Thanks
--
Peter
Jul 22 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
On Thu, 1 Jul 2004 16:31:42 +0000 (UTC), Peter Collingbourne
<pc***@doc.ic.ac.uk> wrote:
Hello

I am trying to do some template metaprogramming involving enabling or
disabling a method in a parameterised class based on some condition. I
am trying to use the Boost enable_if mechanism to do this, using the
SFINAE principle. Here is a simple example showing what I am trying to
do:

1 #include <iostream.h>
2 #include <boost/utility/enable_if.hpp>
3
4 using namespace boost;
5
6 template <bool CanFoo> class A {
7
8 public:
9 typename enable_if_c<CanFoo>::type foo() {
10 cout << "Foo" << endl;
11 }
12
13 };
14
15 int main(int argc, char** argv) {
16 A<false> cant_foo;
17 cant_foo.foo();
18 A<true> can_foo;
19 can_foo.foo();
20 }

In this example the foo method in the A class is supposed to only exist
when the boolean template parameter is true, thus I expect only one
compiler error to occur on line 17. However when compiling this code I
get the following additional message from the compiler (gcc 3.2.2):

traits.cc: In instantiation of `A<false>':
traits.cc:16: instantiated from here
traits.cc:9: no type named `type' in `struct boost::enable_if_c<false,
void>'

Obviously there is not meant to be a type 'type' in this struct, which
is what SFINAE is all about! Is this a bug in the compiler or am I
misunderstanding the principle? If so can someone suggest an alternative
way to do what I want?

Thanks


I think you are misunderstanding the principle. SNIFAE only applies
(AFAIK) to choice between alternative function templates (including member
function templates). When choosing the function template the fact that one
choice leads to a type error is not a problem, it just means that choice
is not made.

The following would seem to do what you want without using SNIFAE (or
enable_if)

#include <iostream>
#include <boost/static_assert.hpp>

using namespace boost;

template <bool CanFoo>
class A {

public:
void foo() {
BOOST_STATIC_ASSERT(CanFoo);
std::cout << "Foo" << std::endl;
}

};

int main(int argc, char** argv) {
A<false> cant_foo;
//cant_foo.foo();
A<true> can_foo;
can_foo.foo();
}
Remove the comment from cant_foo.foo() and you get a compile error.

john
Jul 22 '05 #2

P: n/a

Man, I hate acronyms! What's "SFINAE"?

(In the news business, most acronyms are spelled out the first time they're
used in an article. IMO [in my opinion], that would be a good idea in the
newsgroups as well. :-))

-Howard

Jul 22 '05 #3

P: n/a

"Howard" <al*****@hotmail.com> wrote in message
news:eV********************@bgtnsc04-news.ops.worldnet.att.net...

Man, I hate acronyms! What's "SFINAE"?
Substitution Failure Is Not An Error.
(In the news business, most acronyms are spelled out the first time they're used in an article. IMO [in my opinion], that would be a good idea in the
newsgroups as well. :-))


In this case, (IMO) if you don't know what the acronym stands for you
probably aren't going to be able to contribute. :-)

Jeff F
Jul 22 '05 #4

P: n/a
On Thu, 1 Jul 2004 14:01:25 -0400 in comp.lang.c++, "Jeff Flinn"
Substitution Failure Is Not An Error. In this case, (IMO) if you don't know what the acronym stands for you
probably aren't going to be able to contribute. :-)


But if the poster would spell it out, somebody else reading might learn
something.

Jul 22 '05 #5

P: n/a

"David Harmon" <so****@netcom.com.invalid> wrote in message
news:41***************@news.west.earthlink.net...
On Thu, 1 Jul 2004 14:01:25 -0400 in comp.lang.c++, "Jeff Flinn"
Substitution Failure Is Not An Error.

In this case, (IMO) if you don't know what the acronym stands for you
probably aren't going to be able to contribute. :-)


But if the poster would spell it out, somebody else reading might learn
something.


I googled SFINAE the first time I saw the acronym. I think that's why the
definition stuck with me. If I'd been spoon fed, who knows...

Jeff F
Jul 22 '05 #6

P: n/a
In article <opsagx7jcv212331@andronicus>, John Harrison wrote:
BOOST_STATIC_ASSERT(CanFoo);


Thank you for the hint about static assertions - this enabled me to
implement a solution to my problem.

--
Peter
Jul 22 '05 #7

P: n/a
On Fri, 2 Jul 2004 08:01:48 -0400 in comp.lang.c++, "Jeff Flinn"
<NO****@nowhere.com> wrote,
But if the poster would spell it out, somebody else reading might learn
something.


I googled SFINAE the first time I saw the acronym. I think that's why the
definition stuck with me. If I'd been spoon fed, who knows...


"Substitution Failure Is Not An Error" is sufficiently mysterious to
begin with.

Jul 22 '05 #8

P: n/a
David Harmon wrote:

On Fri, 2 Jul 2004 08:01:48 -0400 in comp.lang.c++, "Jeff Flinn"
<NO****@nowhere.com> wrote,
But if the poster would spell it out, somebody else reading might learn
something.


I googled SFINAE the first time I saw the acronym. I think that's why the
definition stuck with me. If I'd been spoon fed, who knows...


"Substitution Failure Is Not An Error" is sufficiently mysterious to
begin with.


Think of it as "now you see it, now you don't." Or, perhaps, NYSINYD.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Jul 22 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.