I just moved a project that was using VC8, with TR1 supplied via BOOST, to VC9 with its own TR1 implementation. I was surprised that a unordered_map failed to compile with a great deal of verboseness because it didn't like my key type. I used a pair of two primitive types as the key. Boost took that just fine. But looking at the current Boost documentation for the hash object, (http://www.boost.org/doc/libs/1_40_0/doc/html/boost_tr1/subject_list.html#bo...) I see that the hash specializations include primitive types, strings, but not tuples. Is this something that changed between Boost 1_38 and 1_40, or an undocumented extension, or what? Why would the standard leave out that, when everyone and his neighbor will just supply their own generic definition. That is, is there a good reason for not doing it? --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
John Dlugosz wrote:
I just moved a project that was using VC8, with TR1 supplied via BOOST, to VC9 with its own TR1 implementation.
I was surprised that a unordered_map failed to compile with a great deal of verboseness because it didn't like my key type. I used a pair of two primitive types as the key. Boost took that just fine.
But looking at the current Boost documentation for the hash object, (http://www.boost.org/doc/libs/1_40_0/doc/html/boost_tr1/subject_list.html#bo...) I see that the hash specializations include primitive types, strings, but not tuples.
Is this something that changed between Boost 1_38 and 1_40, or an undocumented extension, or what? Why would the standard leave out that, when everyone and his neighbor will just supply their own generic definition. That is, is there a good reason for not doing it?
I think the issue is that TR1 does not (as of yet) require hash for pairs. Boost does have a hash function that works on pairs, in Functional/Hash, and that's the default hash used by Boost's unordered map, but since they aren't part of TR1, they're not included in the TR1 namespace. The Functional/Hash documentation links to a working group document which mentions this among other issues with TR1 (as then proposed). http://www.boost.org/doc/libs/1_40_0/doc/html/hash.html The document is four years old though. Someone more up on the C++0x development can tell you more, and what the current status is. -- Anthony Foglia Princeton Consultants (609) 987-8787 x233
I think the issue is that TR1 does not (as of yet) require hash for pairs. Boost does have a hash function that works on pairs, in Functional/Hash, and that's the default hash used by Boost's unordered map, but since they aren't part of TR1, they're not included in the TR1 namespace.
The unordered_map is finding it anyway.
The Functional/Hash documentation links to a working group document which mentions this among other issues with TR1 (as then proposed).
http://www.boost.org/doc/libs/1_40_0/doc/html/hash.html
The document is four years old though. Someone more up on the C++0x development can tell you more, and what the current status is.
That links to N1837 which marks the matter as "closed". "The LWG agreed that there are usability problems with the current interface, but thought that this proposal was too large, and raised too many design issues, for it to be accepted for the TR." Hopefully, a simpler, acceptable improvement will be provided in the final specification. The wording there is no vauge to know if there is an issue specifically with a pair form. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
participants (2)
-
Anthony Foglia -
John Dlugosz