[config] explicit call of operator templates / msvc bug workaround
Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan
AMDG Stefan Strasser wrote:
is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it?
struct functor{ template<class T> void operator()(); };
template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC }
this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions.
(instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.)
Why do you want to define this as operator(), when you can't use it as an operator? Can you deal with this the same way you would for for_each? template<class T> struct wrap {}; struct functor { template<class T> void operator()(wrap<T>); }; In Christ, Steven Watanabe
Zitat von Steven Watanabe <watanabesj@gmail.com>:
Stefan Strasser wrote:
is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it?
struct functor{ template<class T> void operator()(); };
Why do you want to define this as operator(), when you can't use it as an operator? Can you deal with this the same way you would for for_each?
template<class T> struct wrap {};
struct functor { template<class T> void operator()(wrap<T>); };
I could, but the functor is a visitor that is provided by the user of this class, while the call of the operator is an implementation detail. so I'd rather use a compiler bug workaround for the call than complicate the visitor interface. operator(): because it's a functor. you could use call() or apply() instead of course, but you could for any functor. you just don't because operator() is the convention. I've already defined BOOST_OPERATOR_TEMPLATE in my code, but other compilers might have the same problem, or MSVC might fix this bug, so I'd rather use a Boost.Config macro if it exists. does it?
AMDG Stefan Strasser wrote:
Zitat von Steven Watanabe <watanabesj@gmail.com>:
Why do you want to define this as operator(), when you can't use it as an operator? Can you deal with this the same way you would for for_each?
template<class T> struct wrap {};
struct functor { template<class T> void operator()(wrap<T>); };
I could, but the functor is a visitor that is provided by the user of this class, while the call of the operator is an implementation detail. so I'd rather use a compiler bug workaround for the call than complicate the visitor interface. operator(): because it's a functor.
It isn't a functor if you need explicit template arguments.
you could use call() or apply() instead of course, but you could for any functor. you just don't because operator() is the convention.
In Christ, Steven Watanabe
At Sat, 29 May 2010 13:51:55 -0700, Steven Watanabe wrote:
I could, but the functor is a visitor that is provided by the user of this class, while the call of the operator is an implementation detail. so I'd rather use a compiler bug workaround for the call than complicate the visitor interface. operator(): because it's a functor.
It isn't a functor if you need explicit template arguments.
Well, let's not pick nits over what one should consider a functor, because nobody's ever defined it well for C++, and there's a good argument that C++ has totally abused a term of art from elsewhere (http://en.wikipedia.org/wiki/Functor). -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
if the Boost.Config maintainer wants BOOST_NESTED_OPERATOR_TEMPLATE to be part of Boost.Config, let me know. I can provide a patch for config code, documentation and pass/fail tests, but I'm not very familiar with the boost test/build system, so you'd have to add it there. Stefan Zitat von David Abrahams <dave@boostpro.com>:
At Sat, 29 May 2010 13:51:55 -0700, Steven Watanabe wrote:
I could, but the functor is a visitor that is provided by the user of this class, while the call of the operator is an implementation detail. so I'd rather use a compiler bug workaround for the call than complicate the visitor interface. operator(): because it's a functor.
It isn't a functor if you need explicit template arguments.
Well, let's not pick nits over what one should consider a functor, because nobody's ever defined it well for C++, and there's a good argument that C++ has totally abused a term of art from elsewhere (http://en.wikipedia.org/wiki/Functor).
-- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
if the Boost.Config maintainer wants BOOST_NESTED_OPERATOR_TEMPLATE to be part of Boost.Config, let me know. I can provide a patch for config code, documentation and pass/fail tests, but I'm not very familiar with the boost test/build system, so you'd have to add it there.
This is such a corner case, it seems to be exactly what BOOST_WORKAROUND was made for? I'm also confused as to why you would want to do this - overloading the function call operator is supposed to make things easier read/type, but this use just seems to make them harder? Basically you're forcing folks to use an interface and syntax that most people would never have used before (assuming this is part of a public interface). Just my 2c worth... John.
On 29.05.2010 21:38, Stefan Strasser wrote:
Hi,
is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it?
BOOST_NESTED_TEMPLATE? FWIW, why not always follow the standard syntax (that is, with the 'template' keyword)? This macro was introduced for some ancient compilers that didn't support the standard syntax.
Zitat von Andrey Semashev <andrey.semashev@gmail.com>:
On 29.05.2010 21:38, Stefan Strasser wrote:
Hi,
is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it?
BOOST_NESTED_TEMPLATE?
FWIW, why not always follow the standard syntax (that is, with the 'template' keyword)? This macro was introduced for some ancient compilers that didn't support the standard syntax.
I was a bit unclear above, MSVC requires the "template" keyword NOT to be used when calling an operator template: f.operator()<int>(); //MSVC:ok std:error f.template operator()<int>(); //MSVC:error std:ok f.func()<int>(); //MSVC:ok std:error f.template func<int>(); //MSVC:ok std:ok msvc 9.0
On 29/05/2010 19:38, Stefan Strasser wrote:
Hi,
is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it?
struct functor{ template<class T> void operator()(); };
template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC }
this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions.
(instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.)
I know this is old, but I'd really like to see the right macro defect be added to Boost.Config. Contrary to other comments of the thread, I think this is a core defect, and not just a corner case. The use case is also valid, and superior to the alternatives for a number of reasons.
is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it?
struct functor{ template<class T> void operator()(); };
template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC }
this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions.
(instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.)
I know this is old, but I'd really like to see the right macro defect be added to Boost.Config.
Contrary to other comments of the thread, I think this is a core defect, and not just a corner case. The use case is also valid, and superior to the alternatives for a number of reasons.
Can you provide a patch? John.
participants (6)
-
Andrey Semashev -
David Abrahams -
John Maddock -
Mathias Gaunard -
Stefan Strasser -
Steven Watanabe