[program_options, type_traits] is_reference and VC 7.0
Hi, I get program_options failures on VC 7.0 that result from the following sequences of events: variable_map::as<string> is called any_cast<string&> is called the following code in any.hpp gives static assertion: typedef BOOST_DEDUCED_TYPENAME remove_reference<ValueType>::type nonref; #ifdef BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION // If 'nonref' is still reference type, it means the user has not // specialized 'remove_reference'. // Please use BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro // to generate specialization of remove_reference for your class // See type traits library documentation for details BOOST_STATIC_ASSERT(!is_reference<nonref>::value); The problem is that on VC 7.0 specializations for remove_reference must be defined explicitly, and it's not done for string and wstring. I see three choices: 1. Declare specialization for string and wstring in program_options 2. Declare them somewhere in type_traits 3. Mark 7.0 as unsupported. 4. Don't use any_cast to reference type I don't like (4) because I've introduced cast to reference myself explicitly for program_options sake. (1) can lead to conflicts with user code. So it leaves (2) and (3). Any opinions which one is better? - Volodya
The problem is that on VC 7.0 specializations for remove_reference must be defined explicitly, and it's not done for string and wstring.
I see three choices:
1. Declare specialization for string and wstring in program_options 2. Declare them somewhere in type_traits 3. Mark 7.0 as unsupported. 4. Don't use any_cast to reference type
I don't like (4) because I've introduced cast to reference myself explicitly for program_options sake. (1) can lead to conflicts with user code. So it leaves (2) and (3). Any opinions which one is better?
I'm sympathetic towards (2), but it means making type_traits depend upon <string> and all that brings in (I've just checked and the header doesn't pull <string> in at present). It seems a shame to make VC7 unsupported, just for the lack of an include however. What does anyone else think? Note that the dependency on <string> would be for broken compilers *only*. John.
John Maddock wrote:
The problem is that on VC 7.0 specializations for remove_reference must be defined explicitly, and it's not done for string and wstring.
I see three choices:
1. Declare specialization for string and wstring in program_options 2. Declare them somewhere in type_traits 3. Mark 7.0 as unsupported. 4. Don't use any_cast to reference type
I don't like (4) because I've introduced cast to reference myself explicitly for program_options sake. (1) can lead to conflicts with user code. So it leaves (2) and (3). Any opinions which one is better?
I'm sympathetic towards (2), but it means making type_traits depend upon <string> and all that brings in (I've just checked and the header doesn't pull <string> in at present). It seems a shame to make VC7 unsupported, just for the lack of an include however.
What does anyone else think? Note that the dependency on <string> would be for broken compilers *only*.
Isn't it technically possible to forward-declared basic_string and specialize on that? I can't find anything in the standard to prohibit specializing on incomplete type. And restriction on putting declarations to "namespace std" is not enforced. - Volodya
Vladimir Prus wrote:
Isn't it technically possible to forward-declared basic_string and specialize on that? I can't find anything in the standard to prohibit specializing on incomplete type. And restriction on putting declarations to "namespace std" is not enforced.
Not portable, as the library implementer is free to add additional template parameters, so long as they have default values. Of course if you know exactly which implementation you are dealing with, you can arrange the correct fwd-declaration <g> In general, it is easier just to include the necessary header though. [This is one reason <iosfwd> exists in the standard] AlisdairM
Alisdair Meredith wrote:
Vladimir Prus wrote:
Isn't it technically possible to forward-declared basic_string and specialize on that? I can't find anything in the standard to prohibit specializing on incomplete type. And restriction on putting declarations to "namespace std" is not enforced.
Not portable, as the library implementer is free to add additional template parameters, so long as they have default values.
Of course if you know exactly which implementation you are dealing with, you can arrange the correct fwd-declaration <g>
We're talking about very specific case -- VC 7.0, so extact fwd-declaration is possible.
In general, it is easier just to include the necessary header though.
[This is one reason <iosfwd> exists in the standard]
Alas, there's no <stringfwd> - Volodya
Not portable, as the library implementer is free to add additional template parameters, so long as they have default values.
100% agreement in principle.
Of course if you know exactly which implementation you are dealing with, you can arrange the correct fwd-declaration <g>
I suspect we're only really dealing with VC6 and 7 here, so I guess it is possible in this case. John.
Vladimir Prus <ghost@cs.msu.su> writes:
John Maddock wrote:
The problem is that on VC 7.0 specializations for remove_reference must be defined explicitly, and it's not done for string and wstring.
I see three choices:
1. Declare specialization for string and wstring in program_options 2. Declare them somewhere in type_traits 3. Mark 7.0 as unsupported. 4. Don't use any_cast to reference type
I don't like (4) because I've introduced cast to reference myself explicitly for program_options sake. (1) can lead to conflicts with user code. So it leaves (2) and (3). Any opinions which one is better?
I'm sympathetic towards (2), but it means making type_traits depend upon <string> and all that brings in (I've just checked and the header doesn't pull <string> in at present). It seems a shame to make VC7 unsupported, just for the lack of an include however.
What does anyone else think? Note that the dependency on <string> would be for broken compilers *only*.
Isn't it technically possible to forward-declared basic_string and specialize on that? I can't find anything in the standard to prohibit specializing on incomplete type. And restriction on putting declarations to "namespace std" is not enforced.
As long as you can be sure that the standard library implementation hasn't added default parameters to basic_string, then yeah, you can do that. -- Dave Abrahams Boost Consulting www.boost-consulting.com
John Maddock writes:
The problem is that on VC 7.0 specializations for remove_reference must be defined explicitly, and it's not done for string and wstring.
I see three choices:
1. Declare specialization for string and wstring in program_options 2. Declare them somewhere in type_traits 3. Mark 7.0 as unsupported. 4. Don't use any_cast to reference type
I don't like (4) because I've introduced cast to reference myself explicitly for program_options sake. (1) can lead to conflicts with user code.
So can (2) if users already defined them for themselves -- which is quite likely; I know that we did.
So it leaves (2) and (3). Any opinions which one is better?
I'm sympathetic towards (2), but it means making type_traits depend upon <string> and all that brings in (I've just checked and the header doesn't pull <string> in at present). It seems a shame to make VC7 unsupported, just for the lack of an include however.
If we did, it would be a lie.
What does anyone else think? Note that the dependency on <string> would be for broken compilers *only*.
5. Provide a standalone type_traits header defining necessary/possible specializations for the standard library's types and include it as required in the corresponding program_options' tests/examples. Users can use or ignore this header at their will. -- Aleksey Gurtovoy MetaCommunications Engineering
5. Provide a standalone type_traits header defining necessary/possible specializations for the standard library's types and include it as required in the corresponding program_options' tests/examples. Users can use or ignore this header at their will.
That sounds like a plan, someone want to put it together? John.
On Wednesday 08 June 2005 14:06, John Maddock wrote:
5. Provide a standalone type_traits header defining necessary/possible specializations for the standard library's types and include it as required in the corresponding program_options' tests/examples. Users can use or ignore this header at their will.
That sounds like a plan, someone want to put it together?
Will that new header go to the type_traits directory? Will is specialize only remove_reference? If yes, just tell me the name the header should have ;-) - Volodya
Will that new header go to the type_traits directory?
Yes.
Will is specialize only remove_reference? If yes, just tell me the name the header should have ;-)
Can't think of a good name: I was hoping someone else would suggest one :-) std_workarounds.hpp is by best suggestion at the moment. As for contents, use the BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION macro: see http://tinyurl.com/arluc for examples and reference. John.
John Maddock writes:
Will that new header go to the type_traits directory?
Yes.
Will is specialize only remove_reference? If yes, just tell me the name the header should have ;-)
Can't think of a good name: I was hoping someone else would suggest one :-)
I'd go with "broken_compiler_std_spec.hpp", to follow the convention of the existing "broken_compiler_spec.hpp". -- Aleksey Gurtovoy MetaCommunications Engineering
participants (5)
-
Aleksey Gurtovoy -
Alisdair Meredith -
David Abrahams -
John Maddock -
Vladimir Prus