Hi, I've written a new version of boost::any. It does not depend on rtti and uses a static integer value instead of std::type_info to store type information. My version passed the unit tests included in boost 1_47_0 on vc++2010 express and gcc 4.5.(mingw) . With this mail, I'm sending the source and a small quick-and-dirty benchmark. On gcc, moving and copying performance seems to be roughly the same, any_cast however is about 400% faster. On msvc++, moving and copying times rise by ca. 50%, while any_cast is about 50.000% faster (although I guess the speed boost measured in a real benchmark would be in the order of magnitude of the gcc speed up). I would appreciate if somebody measured the performance with proper tools and tested it on more platforms. Sincerely, Martin Bidlingmaier -- NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie! Jetzt informieren: http://www.gmx.net/de/go/freephone
On Wed, Aug 31, 2011 at 5:16 PM, Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de> wrote:
Hi,
[...] It does not depend on rtti and uses a static integer value instead of std::type_info to store type information. [...]
Quote from any.hpp: //use static class member to force initialization at program start to make type_id thread safe (and more efficient) template< class T > class type_id { public: static unsigned int value; }; template< class T > unsigned int type_id< T >::value = next_id(); I do not think you can initialize a class static in a header. If you include any.hpp in more than one cpp you will have the same static been initialized more than once. MS C++ linker complains. Though the standard requires no diagnostic. See "9.4.2 Static data members" paragraph 5. Ilya Bobyr
On Wed, Aug 31, 2011 at 5:55 PM, Ilya Bobir <ilya.bobir@gmail.com> wrote:
On Wed, Aug 31, 2011 at 5:16 PM, Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de> wrote:
Hi,
[...] It does not depend on rtti and uses a static integer value instead of std::type_info to store type information. [...]
Quote from any.hpp:
//use static class member to force initialization at program start to make type_id thread safe (and more efficient) template< class T > class type_id { public: static unsigned int value; }; template< class T > unsigned int type_id< T >::value = next_id();
I do not think you can initialize a class static in a header. If you include any.hpp in more than one cpp you will have the same static been initialized more than once. MS C++ linker complains. Though the standard requires no diagnostic. See "9.4.2 Static data members" paragraph 5.
In addition, in general, the initialization of statics and globals may be postponed until after main() is entered. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On 09/01/2011 05:26 AM, Emil Dotchevski wrote:
On Wed, Aug 31, 2011 at 5:55 PM, Ilya Bobir<ilya.bobir@gmail.com> wrote:
On Wed, Aug 31, 2011 at 5:16 PM, Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de> wrote:
Hi,
[...] It does not depend on rtti and uses a static integer value instead of std::type_info to store type information. [...]
Quote from any.hpp:
//use static class member to force initialization at program start to make type_id thread safe (and more efficient) template< class T> class type_id { public: static unsigned int value; }; template< class T> unsigned int type_id< T>::value = next_id();
I do not think you can initialize a class static in a header. If you include any.hpp in more than one cpp you will have the same static been initialized more than once. MS C++ linker complains. Though the standard requires no diagnostic. See "9.4.2 Static data members" paragraph 5.
In addition, in general, the initialization of statics and globals may be postponed until after main() is entered.
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules. These instances will be initialized independently and most likely will have different ids. And since next_id() is also module-private, inter-module passing of boost::any becomes totally impossible.
On Wed, Aug 31, 2011 at 10:26 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
[...]
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules. [...]
Can you elaborate on this? Are not you supposed to provide an explicit initialization for the type_id<T>::value for every T you are using and that would be the only instance? I can not find anything in the standard that would contradict your statement, at the moment, except that if you treat a template instantiation as a class in this case you may say that 9.4.2 para. 5 applies to template instantiations and then there should be no more than once instance of a static member for a particular set of template arguments.
Hi all,
I do not think you can initialize a class static in a header. If you include any.hpp in more than one cpp you will have the same static been initialized more than once.
Out of curiosity, would a static member function with a static variable solve that kind of issue ? (Let's forget potential threading issues mentioned in the Singularity discussion). If yes, by what magic can the compiler (or the linker?) solve the unicity of the static member function ? Can't it (the magic ;) be applied to a static member ? Thanks for your insight, Julien
On 01/09/2011 2:14, Julien Nitard wrote:
Out of curiosity, would a static member function with a static variable solve that kind of issue ? (Let's forget potential threading issues mentioned in the Singularity discussion).
It can't, you will end up with a different function static variable for each translation unit. Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com
2011/9/1 Agustín K-ballo Bergé <kaballo86@hotmail.com>
On 01/09/2011 2:14, Julien Nitard wrote:
Out of curiosity, would a static member function with a static variable solve that kind of issue ? (Let's forget potential threading issues mentioned in the Singularity discussion).
It can't, you will end up with a different function static variable for each translation unit.
This isn't the case. If you have an inline function with a static variable in it, it'll be the same variable in all translation units. *7.1.2p4 A static local variable in an extern inline function always refers to the same object.* Roman Perepelitsa.
It can't, you will end up with a different function static variable for each translation unit.
This isn't the case. If you have an inline function with a static variable in it, it'll be the same variable in all translation units.
*7.1.2p4 A static local variable in an extern inline function always refers to the same object.*
... which I guess means you can still end up with several definitions when using dynamic libraries ? Thanks, Julien
2011/9/1 Julien Nitard <julien.nitard@m4tp.org>
It can't, you will end up with a different function static variable for each translation unit.
This isn't the case. If you have an inline function with a static
variable
in it, it'll be the same variable in all translation units.
*7.1.2p4 A static local variable in an extern inline function always refers to the same object.*
... which I guess means you can still end up with several definitions when using dynamic libraries ?
If they don't export the function properly, then yes. By messing with the set of exported symbols in shared libraries one can end up with all sorts of anomalies: failure to dynamic_cast std::string to std::string, or failure to catch exceptions even when the type of the exception thrown is the same as the type of the exception in the catch clause. If I wanted to guarantee that there is exactly one instance of the variable regardless of the symbol export map, I'd put the variable in a shared library. Roman Perepelitsa.
On Wed, Aug 31, 2011 at 11:25 PM, Julien Nitard <julien.nitard@m4tp.org> wrote:
It can't, you will end up with a different function static variable for each translation unit.
This isn't the case. If you have an inline function with a static variable in it, it'll be the same variable in all translation units.
*7.1.2p4 A static local variable in an extern inline function always refers to the same object.*
... which I guess means you can still end up with several definitions when using dynamic libraries ?
Dynamic libraries are outside the scope of the C/C++ standard. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders. I see only one possible way out without breaking existing code (and still use the new version, if it is considered superior): Let the user explicitly declare he wants to use the version with statics by introducing a new configuration macro, e.g. BOOST_ANY_NO_DLL_CROSSING, or use an existing macro that does the same thing. If not defined, type_info comparsion would be used. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
2011/9/1 Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de>
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders.
The existing version of boost::any has the same limitation. If you make rtti info local to dynamic libraries, you won't be able to extra data from any in one dynamic library if it was put in in another. I personally don't consider this to be a limitation. If you want to be resilient to any kind of dynamic library barriers, you can't even use exceptions. Roman Perepelitsa.
On Thu, Sep 1, 2011 at 2:24 PM, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
2011/9/1 Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de>
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders.
The existing version of boost::any has the same limitation. If you make rtti info local to dynamic libraries, you won't be able to extra data from any in one dynamic library if it was put in in another.
MSVC bakes the RTTI statically in each DLL, but it does work across DLL boundaries. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
2011/9/2 Emil Dotchevski <emildotchevski@gmail.com>
On Thu, Sep 1, 2011 at 2:24 PM, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote:
2011/9/1 Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de>
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders.
The existing version of boost::any has the same limitation. If you make rtti info local to dynamic libraries, you won't be able to extra data from any in one dynamic library if it was put in in another.
MSVC bakes the RTTI statically in each DLL, but it does work across DLL boundaries.
It doesn't work on Linux, though. Roman Perepelitsa.
On 09/02/2011 09:49 AM, Roman Perepelitsa wrote:
2011/9/2 Emil Dotchevski<emildotchevski@gmail.com>
The existing version of boost::any has the same limitation. If you make rtti info local to dynamic libraries, you won't be able to extra data from any in one dynamic library if it was put in in another.
MSVC bakes the RTTI statically in each DLL, but it does work across DLL boundaries.
It doesn't work on Linux, though.
It does, if you make RTTI public for relocation.
2011/9/2 Andrey Semashev <andrey.semashev@gmail.com>
On 09/02/2011 09:49 AM, Roman Perepelitsa wrote:
2011/9/2 Emil Dotchevski<emildotchevski@**gmail.com<emildotchevski@gmail.com>
The existing version of boost::any has the same limitation. If you make
rtti
info local to dynamic libraries, you won't be able to extra data from any
in
one dynamic library if it was put in in another.
MSVC bakes the RTTI statically in each DLL, but it does work across DLL boundaries.
It doesn't work on Linux, though.
It does, if you make RTTI public for relocation.
The existing implementation of any works unless you make RTTI local to dynamic libraries. The new and faster implementation of any works unless you make type_id local to dynamic libraries. In both cases it's a matter of specifying the export maps correctly. Roman Perepelitsa.
On 09/02/2011 10:03 AM, Roman Perepelitsa wrote:
2011/9/2 Andrey Semashev<andrey.semashev@gmail.com>
It does, if you make RTTI public for relocation.
The existing implementation of any works unless you make RTTI local to dynamic libraries. The new and faster implementation of any works unless you make type_id local to dynamic libraries. In both cases it's a matter of specifying the export maps correctly.
Well, it's not the same, actually. If you actually do limit export tables in your application, you can export all RTTI by a wildcard rule in the symbols map. I would expect you to do this regardless whether you use boost::any or not, just to keep basic C++ features working. Note that you can even do export RTTI with a single GCC option -fvisibility-ms-compat, no symbol maps required in this case. Now if boost::any requires its own symbols exported, that is additional work to know which these symbols are and explicitly exporting them, possibly by modifying Boost code to alter their visibility. This cannot be done by a compiler option and it won't match the common wildcard rules for RTTI in your symbols map. Lastly, these problems only exist on Linux. On other platforms you don't have to do _anything_ to make RTTI working. That is unlike ids.
On 09/02/2011 01:24 AM, Roman Perepelitsa wrote:
2011/9/1 Martin Bidlingmaier<Martin.Bidlingmaier@gmx.de>
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders.
The existing version of boost::any has the same limitation. If you make rtti info local to dynamic libraries, you won't be able to extra data from any in one dynamic library if it was put in in another.
I personally don't consider this to be a limitation. If you want to be resilient to any kind of dynamic library barriers, you can't even use exceptions.
AFAIK, by default it does work out of the box on most (all?) platforms. Yes, if you make RTTI private you get all sorts of problems but you have to do it explicitly and if you do you are assumed to know what you're doing. I think that this would be a significant limitation of boost::any. I often use shared libraries and I consider it only natural that objects I create are not tied to the module.
On 1 September 2011 14:45, Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de> wrote:
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders.
Does the current version of boost::any work when instances cross dll borders? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 09/02/2011 01:28 AM, Nevin Liber wrote:
On 1 September 2011 14:45, Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de> wrote:
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders.
Does the current version of boost::any work when instances cross dll borders?
Yes, it does.
On 09/01/2011 11:45 PM, Martin Bidlingmaier wrote:
Ok, so obviously the proposed version won't work when instances of boost::any cross dll borders. I see only one possible way out without breaking existing code (and still use the new version, if it is considered superior): Let the user explicitly declare he wants to use the version with statics by introducing a new configuration macro, e.g. BOOST_ANY_NO_DLL_CROSSING, or use an existing macro that does the same thing. If not defined, type_info comparsion would be used.
I don't really like the macro idea because it breaks ABI. Consider this. On Linux, and probably other UNIX systems, Boost libraries are provided as shared libraries. So if I use system Boost.ProgramOptions, for instance, I'm linking with a shared library. But Boost.ProgramOptions uses boost::any and AFAIR it passes it across library boundaries. So my application will not be able to use the optimized boost::any. I understand that there are cases when you link with no shared libraries and eager to squeeze that little extra bit of performance. But honestly, does that change really make a difference in the context of your application? And if it does, perhaps your case is special enough to create a separate component, say, local_any? Or take a different approach in your design altogether?
On 09/01/2011 08:16 AM, Ilya Bobir wrote:
On Wed, Aug 31, 2011 at 10:26 PM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
[...]
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules. [...]
Can you elaborate on this?
Are not you supposed to provide an explicit initialization for the type_id<T>::value for every T you are using and that would be the only instance?
I can not find anything in the standard that would contradict your statement, at the moment, except that if you treat a template instantiation as a class in this case you may say that 9.4.2 para. 5 applies to template instantiations and then there should be no more than once instance of a static member for a particular set of template arguments.
Yes, except that the Standard doesn't specify how that translates to a multi-module application (i.e. which consists of exe and dll/so/dylib). Because the Standard doesn't know of modules. Suppose you use boost::any with types int and string in your main executable and in one of the dlls linked in. Exe and dll will have separate instances of both type_id<int>::value and type_id<string>::value, each of them being initialized independently. What's worse, exe and dll will have separate next_id() functions with its local static counter. Depending on the circumstances, type_id<int>::value in exe may become initialized equal to type_id<string>::value in dll, for instance. Needless to say what will happen if you try to interoperate with boost::any's created in different modules. In practice, I'm aware of only one platform (Linux), which will by default attempt to maintain a single instance of these ids, but even there care must be taken.
On 01/09/2011 19:00, Andrey Semashev wrote:
Suppose you use boost::any with types int and string in your main executable and in one of the dlls linked in. Exe and dll will have separate instances of both type_id<int>::value and type_id<string>::value
Which is no different than when compiling multiple translation units.
Depending on the circumstances, type_id<int>::value in exe may become initialized equal to type_id<string>::value in dll, for instance.
In practice, a good linker is supposed to remove duplicate weak symbols.
In practice, I'm aware of only one platform (Linux), which will by default attempt to maintain a single instance of these ids, but even there care must be taken.
Quite the opposite, only DLLs don't support weak symbols.
On 09/05/2011 03:40 PM, Mathias Gaunard wrote:
On 01/09/2011 19:00, Andrey Semashev wrote:
Suppose you use boost::any with types int and string in your main executable and in one of the dlls linked in. Exe and dll will have separate instances of both type_id<int>::value and type_id<string>::value
Which is no different than when compiling multiple translation units.
You are assuming runtime linking, again.
In practice, I'm aware of only one platform (Linux), which will by default attempt to maintain a single instance of these ids, but even there care must be taken.
Quite the opposite, only DLLs don't support weak symbols.
Are you saying that, say, on MacOS X or Solaris there is no need to do anything to export these symbols and the runtime linker will relocate them to a single instance? That's news to me.
--- On Mon, 9/5/11, Andrey Semashev <andrey.semashev@gmail.com> wrote:
From: Andrey Semashev <andrey.semashev@gmail.com>
Quite the opposite, only DLLs don't support weak
symbols.
Are you saying that, say, on MacOS X or Solaris there is no need to do anything to export these symbols and the runtime linker will relocate them to a single instance? That's news to me.
It is actually correct for all ELF platforms that all modern operating systems use (yep... I don't consider windows modern system :-) ). There is some control depending on compiler on hiding symbols or not but generally there is no huge headache that exists on DLL platform (a.k.a. Windows) Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On 05/09/2011 19:00, Andrey Semashev wrote:
On 09/05/2011 03:40 PM, Mathias Gaunard wrote:
On 01/09/2011 19:00, Andrey Semashev wrote:
Suppose you use boost::any with types int and string in your main executable and in one of the dlls linked in. Exe and dll will have separate instances of both type_id<int>::value and type_id<string>::value
Which is no different than when compiling multiple translation units.
You are assuming runtime linking, again.
Hm no, I was drawing a parallel with static linking here. When you use DLL, so, or dylib, you use runtime linking which, ideally, should be essentially the same.
Are you saying that, say, on MacOS X or Solaris there is no need to do anything to export these symbols and the runtime linker will relocate them to a single instance? That's news to me.
Whether you have to export the symbols or not is a separate issue. The linkers above support symbols that are "weak", while DLL do not
On 01/09/2011 05:26, Andrey Semashev wrote:
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules.
That's not a problem, type_id<T>::value is a weak symbol.
These instances will be initialized independently and most likely will have different ids. And since next_id() is also module-private, inter-module passing of boost::any becomes totally impossible.
You could make next_id a function with weak extern linkage, which should be able to make it work.
On 01/09/2011 10:30, Mathias Gaunard wrote:
On 01/09/2011 05:26, Andrey Semashev wrote:
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules.
That's not a problem, type_id<T>::value is a weak symbol.
These instances will be initialized independently and most likely will have different ids. And since next_id() is also module-private, inter-module passing of boost::any becomes totally impossible.
You could make next_id a function with weak extern linkage, which should be able to make it work.
The attached testcase appears to work. It doesn't, of course, if next_id is static.
On 09/01/2011 12:30 PM, Mathias Gaunard wrote:
On 01/09/2011 05:26, Andrey Semashev wrote:
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules.
That's not a problem, type_id<T>::value is a weak symbol.
It doesn't matter. I wasn't speaking of different translation units, but different modules (i.e. dll, so, dylib). Unless you do explicit exporting/importing of this symbol, you'll have separate instances.
These instances will be initialized independently and most likely will have different ids. And since next_id() is also module-private, inter-module passing of boost::any becomes totally impossible.
You could make next_id a function with weak extern linkage, which should be able to make it work.
The problem is not with the function itself but rather its local static variable, which is subject to the same issues as with type_id<T>::value.
On 01/09/2011 18:46, Andrey Semashev wrote:
On 09/01/2011 12:30 PM, Mathias Gaunard wrote:
On 01/09/2011 05:26, Andrey Semashev wrote:
In addition, on most platforms there will be multiple instances of type_id<T>::value for a single given T if the application uses type_id<T> in multiple modules.
That's not a problem, type_id<T>::value is a weak symbol.
It doesn't matter. I wasn't speaking of different translation units, but different modules (i.e. dll, so, dylib). Unless you do explicit exporting/importing of this symbol, you'll have separate instances.
Shared objects do not work by exporting/importing, but with visibility. The default visibility will make it work correctly. On windows though, there is no good solution to this.
From: Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de>
I've written a new version of boost::any. It does not depend on rtti and uses a static integer value instead of std::type_info to store type information.
Please don't do this! unsigned int next_id() { static unsigned int previous_id = 0; //0 is not assigned to a type ++previous_id; return previous_id; } But what is even more horrible that it would not work on DLL platform without making Boost.Any non-header only library: Example: /tmp/any$ cat dll.cpp #include "any.hpp" __declspec(dllexport) boost::proposal::any get_int() { boost::proposal::any a = int(10); return a; } /tmp/any$ cat main.cpp #include "any.hpp" #include <iostream> __declspec(dllimport) boost::proposal::any get_int(); int main() { boost::proposal::any d=double(3.14); boost::proposal::any i=get_int(); try { std::cout << boost::proposal::any_cast<double>(d) << std::endl; std::cout << boost::proposal::any_cast<int>(i) << std::endl; } catch(std::exception const &e) { std::cerr << e.what() << std::endl; } } /tmp/any$ wine ./a.exe 3.14 boost::bad_any_cast: failed conversion using boost::any_cast And you can't solve this without making any compiled library... So please.... -------------------- Do not reinvent RTTI -------------------- Best, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On Fri, Sep 2, 2011 at 7:28 AM, Artyom Beilis <artyomtnk@yahoo.com> wrote:
From: Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de>
I've written a new version of boost::any. It does not depend on rtti and uses a static integer value instead of std::type_info to store type information.
Please don't do this!
unsigned int next_id() { static unsigned int previous_id = 0; //0 is not assigned to a type
++previous_id; return previous_id; }
[...]
Would not this be non-thread safe?
On 2 September 2011 11:01, Ilya Bobir <ilya.bobir@gmail.com> wrote:
unsigned int next_id() { static unsigned int previous_id = 0; //0 is not assigned to a type
++previous_id; return previous_id; }
[...]
Would not this be non-thread safe?
That's the second problem that has to be tackled with this code. Would this work: unsigned next_id() { static std::atomic<unsigned> previous_id; return ++previous_id; } -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On Fri, Sep 2, 2011 at 12:44 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
On 2 September 2011 11:01, Ilya Bobir <ilya.bobir@gmail.com> wrote:
unsigned int next_id() { static unsigned int previous_id = 0; //0 is not assigned to a type
++previous_id; return previous_id; }
[...]
Would not this be non-thread safe?
That's the second problem that has to be tackled with this code.
Would this work:
unsigned next_id() { static std::atomic<unsigned> previous_id; return ++previous_id; }
It is not exactly the second problem. The only reason for the new library is speed, but if one uses atomics or full-flagged locking it may become slower than the current boost::any. If this is the case it does not make any sense to look at the new library at all. What follows is a benchmarking of Boost.Any and the new any with some tweaks. I have included the actual output so that someone interested my double check my logic but I also summarized the numbers after every run, so if you read just the text, skipping the benchmarks output, you should get the picture anyway. And there is a summary in the last two paragraphs if you really want to look just at the end result. OK, so I started this because I was wondering how is it possible that we can skip a virtual function call when we need to figure out our real type id. Maybe I missed an explanation somewhere earlier in the thread but there is a tradeoff going on. We increase the size of the any instances and store the type id directly instead of relying on a virtual function call to figure it out. And this tradeoff is IIUC unrelated to the way we actually tag types. I have run the benchmark on my machine and figured out that the 50 000% gain on MSVC is a reasult of an optimization. After "fixing" the benchmark a little (attached as any_becnhmark.cpp) MS C++ gives me numbers of the same order of magnitude as GCC. I was compiling against Boost 1.44. Here is the output on my box: $ g++ --version g++ (GCC) 4.3.4 20090804 (release) 1 Ilya@Ilya-PC ~/works/tests/any $ g++ -O3 -I /d/works/boost/ any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./a.exe Testing any with int copying: old any: 249 new any: 250 moving: old any: 281 new any: 452 any_cast: old any: 187 new any: 63 Testing any with double copying: old any: 234 new any: 249 moving: old any: 312 new any: 437 any_cast: old any: 187 new any: 47 Testing any with std::string copying: old any: 265 new any: 265 moving: old any: 344 new any: 483 any_cast: old any: 203 new any: 47 sizeof(old any): 4 sizeof(new any): 8 Moving is actually ~30% slower in the new version, but any_cast is ~4 times faster. And the instance size is doubled. Ilya@Ilya-PC ~/works/tests/any $ cl Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. This is a MS Visual Studio 2010 compiler. Ilya@Ilya-PC ~/works/tests/any $ cl -EHs -O2 -I 'D:\works\boost' any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./any_benchmark.exe Testing any with int copying: old any: 61 new any: 61 moving: old any: 75 new any: 102 any_cast: old any: 477 new any: 59 Testing any with double copying: old any: 61 new any: 61 moving: old any: 75 new any: 104 any_cast: old any: 476 new any: 59 Testing any with std::string copying: old any: 78 new any: 79 moving: old any: 88 new any: 124 any_cast: old any: 480 new any: 58 sizeof(old any): 8 sizeof(new any): 16 Note that this is a 64 bit compiler. Move is ~30% slower, any_cast is ~8 times faster. Instance size is doubled. Now about the generations of ids for types. If RTTI is available typeid(T).name() will be different for all types and at the same time it returns a pointer that would have the same value for all Ts across all compilation units (not considering dynamic libraries) and will be thread safe. So, I replaced the unsigned integers with const char pointers (any.typeid.name.hpp). Here are the numbers: Ilya@Ilya-PC ~/works/tests/any $ g++ -O3 -I /d/works/boost/ any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./a.exe Testing any with int copying: old any: 234 new any: 249 moving: old any: 297 new any: 452 any_cast: old any: 187 new any: 63 Testing any with double copying: old any: 249 new any: 250 moving: old any: 296 new any: 453 any_cast: old any: 187 new any: 62 Testing any with std::string copying: old any: 250 new any: 249 moving: old any: 344 new any: 468 any_cast: old any: 187 new any: 62 sizeof(old any): 4 sizeof(new any): 8 For the new version of any_cast test I was getting "62" or "47" as the average time for both unsinged interger and char pointer versions depending on the run, so for GCC this change did not actually affect the run time. At the same time this version is thread safe, but requires typeid to be accessible. Ilya@Ilya-PC ~/works/tests/any $ cl -EHs -O2 -I 'D:\works\boost' any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./any_benchmark.exe Testing any with int copying: old any: 61 new any: 67 moving: old any: 79 new any: 115 any_cast: old any: 488 new any: 95 Testing any with double copying: old any: 65 new any: 65 moving: old any: 78 new any: 115 any_cast: old any: 491 new any: 94 Testing any with std::string copying: old any: 79 new any: 80 moving: old any: 90 new any: 132 any_cast: old any: 486 new any: 93 sizeof(old any): 8 sizeof(new any): 16 64 bit cl on the other hand is persistently ~30% slower for the char pointer case. I guess it is again some kind of optimization. But I did not look at the generated code. The new version any_cast is still ~5 times faster. Then I though, well, why not use the type_info objects themselves? They are guaranteed to exist through the application lifetime. id is now "const std::type_info *". Here are the numbers (any.typeid.hpp): Ilya@Ilya-PC ~/works/tests/any $ g++ -O3 -I /d/works/boost/ any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./a.exe Testing any with int copying: old any: 249 new any: 250 moving: old any: 281 new any: 436 any_cast: old any: 188 new any: 62 Testing any with double copying: old any: 234 new any: 250 moving: old any: 296 new any: 421 any_cast: old any: 187 new any: 63 Testing any with std::string copying: old any: 249 new any: 266 moving: old any: 343 new any: 468 any_cast: old any: 187 new any: 47 sizeof(old any): 4 sizeof(new any): 8 No change from the char pointer case for GCC. Ilya@Ilya-PC ~/works/tests/any $ cl -EHs -O2 -I 'D:\works\boost' any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./any_benchmark.exe Testing any with int copying: old any: 60 new any: 61 moving: old any: 74 new any: 103 any_cast: old any: 464 new any: 59 Testing any with double copying: old any: 60 new any: 60 moving: old any: 74 new any: 102 any_cast: old any: 467 new any: 59 Testing any with std::string copying: old any: 77 new any: 79 moving: old any: 88 new any: 124 any_cast: old any: 461 new any: 58 sizeof(old any): 8 sizeof(new any): 16 MS C++ on the other hand was able to perform better than for the char pointer. Essentially the picture is the same as for the unsigned int case. OK, there is a trade-off that can be done to make any_cast 4 to 8 times faster by making move ~30% slower and increasing the size of any instances from one to two pointers. Let's try doing that with the Boost.Any source (boost.any.doubleSize.hpp): Ilya@Ilya-PC ~/works/tests/any $ g++ -O3 -I /d/works/boost/ any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./a.exe Testing any with int copying: old any: 234 new any: 249 moving: old any: 297 new any: 421 any_cast: old any: 187 new any: 62 Testing any with double copying: old any: 234 new any: 250 moving: old any: 296 new any: 437 any_cast: old any: 172 new any: 62 Testing any with std::string copying: old any: 250 new any: 281 moving: old any: 327 new any: 468 any_cast: old any: 187 new any: 47 sizeof(old any): 8 sizeof(new any): 8 No change?! I guess, GCC can optimize to a level when it does not care for a change like this. Ilya@Ilya-PC ~/works/tests/any $ cl -EHs -O2 -I 'D:\works\boost' any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./any_benchmark.exe Testing any with int copying: old any: 61 new any: 64 moving: old any: 78 new any: 110 any_cast: old any: 125 new any: 57 Testing any with double copying: old any: 63 new any: 63 moving: old any: 77 new any: 107 any_cast: old any: 124 new any: 57 Testing any with std::string copying: old any: 80 new any: 81 moving: old any: 91 new any: 128 any_cast: old any: 127 new any: 57 sizeof(old any): 16 sizeof(new any): 16 MS C++ on the other hand does care. Note that the change only affects the any_cast speed - almost 4 times faster, nor copy, nor move are affected. So, it seems that for GCC (at least 4.3.4 on Cyginw at O3) the difference has nothing to do with the way we store and retrieve the type information. Lets compare just Boost.Any with and without the patch side by side (boost.any_benchmark.cpp): Ilya@Ilya-PC ~/works/tests/any $ g++ -O3 -I /d/works/boost/ boost.any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./a.exe Testing any with int copying: old any: 249 new any: 234 moving: old any: 297 new any: 296 any_cast: old any: 187 new any: 172 Testing any with double copying: old any: 249 new any: 234 moving: old any: 297 new any: 296 any_cast: old any: 187 new any: 188 Testing any with std::string copying: old any: 265 new any: 249 moving: old any: 328 new any: 343 any_cast: old any: 187 new any: 172 sizeof(old any): 4 sizeof(new any): 8 Same times for GCC. Only the instance sizes are different. Ilya@Ilya-PC ~/works/tests/any $ cl -EHs -O2 -I 'D:\works\boost' boost.any_benchmark.cpp Ilya@Ilya-PC ~/works/tests/any $ ./boost.any_benchmark.exe Testing any with int copying: old any: 60 new any: 61 moving: old any: 75 new any: 74 any_cast: old any: 459 new any: 125 Testing any with double copying: old any: 60 new any: 62 moving: old any: 73 new any: 73 any_cast: old any: 465 new any: 122 Testing any with std::string copying: old any: 78 new any: 78 moving: old any: 87 new any: 88 any_cast: old any: 462 new any: 124 sizeof(old any): 8 sizeof(new any): 16 MS C++ on the other hand likes the change a lot. An almost 4 times speed increase for any_cast with no speed changes for other operations. I guess that now it is time to look at the generated code to figure out why GCC does not care for this change or what else is different between Boost.Any and the version presented by Martin, but I will stop here for now. The bottom line: there is a change that will make any_cast almost 4 times faster for MS C++, does not change speed on GCC and increases size of all any instances from one pointer to two pointers. The change is thread safe. I think that in order to compare apples to apples one need to change the "unsigned integers as type ids" case to be thread safe and only then benchmark. A non-thread safe any is probably of a limited use, isn't it? Ilya Bobyr
Do not reinvent RTTI
And yet, many code bases DO reinvent RTTI, for various reasons. I work with code that is not allowed to depend on C++ runtime libraries, so standard RTTI is out of the question.
Please don't do this!
unsigned int next_id() { static unsigned int previous_id = 0; //0 is not assigned to a type ++previous_id; return previous_id; }
Indeed, runtime allocation of unique identifiers is problematic. But perhaps there is some kind of compile-time trick, apart from manually assigning enums in some central header. And ideally, portable across compilers so that foo.dll and bar.dll would be consistant without being build by the same vendor, or toolchains. - Nigel
On Fri, Sep 2, 2011 at 9:06 AM, Nigel Stewart <nigels.com@gmail.com> wrote: [...]
Please don't do this!
unsigned int next_id() { static unsigned int previous_id = 0; //0 is not assigned to a type ++previous_id; return previous_id; }
Indeed, runtime allocation of unique identifiers is problematic. But perhaps there is some kind of compile-time trick, apart from manually assigning enums in some central header. And ideally, portable across compilers so that foo.dll and bar.dll would be consistant without being build by the same vendor, or toolchains.
For the "compile-time trick", I'd guess the closest thing would be what Boost.TypeOf does. And I don't see that being practical for this application. - Jeff
On Fri, Sep 2, 2011 at 11:03 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 02/09/2011 19:33, Jeffrey Lee Hellrung, Jr. wrote:
For the "compile-time trick", I'd guess the closest thing would be what Boost.TypeOf does.
There is better than what Boost.Typeof does. Regardless, it would only work at the translation unit level.
I know of a compile-time trick that always works. It's called RTTI. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
So there are actually two main issues that need to be taken care of: - 1. dlls I think a good solution would be to add a new class, e.g. as Andrey Semashev proposed 'local_any', that derives from the current version of any. The normal version could be used for inter dll passing, the new version when the user can assure that a local_any instance won't be passed between dlls. Conversion could be provided from local_any to any. - 2. thread safety In c++03, variables defined at namespace scope are not necessarily initialized before main(), so there could be data races for the previous_id in next_id() in multi threaded applications. One simple way out would be to lock the variabe when used, but this would add the dependency on a threading library (does boost provide locking header only or does it need building?). It would be interesting to know, what c++11 says about the initialization of static data members. If it prohibits more than one initialization at a time or requires single threaded initialization before main() , locking will not be needed. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de
On 02/09/2011 20:58, Martin Bidlingmaier wrote:
So there are actually two main issues that need to be taken care of:
- 1. dlls I think a good solution would be to add a new class, e.g. as Andrey Semashev proposed 'local_any', that derives from the current version of any. The normal version could be used for inter dll passing, the new version when the user can assure that a local_any instance won't be passed between dlls. Conversion could be provided from local_any to any.
I don't think Boost libraries should be designed for a single platform.
- 2. thread safety In c++03, variables defined at namespace scope are not necessarily initialized before main()
Yes they are.
, so there could be data races for the previous_id in next_id() in multi threaded applications.
That's not namespace scope, that's function scope. The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
On 05/09/2011 13:18, Mathias Gaunard wrote:
, so there could be data races for the previous_id in next_id() in multi threaded applications.
That's not namespace scope, that's function scope.
The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
Sorry, that is irrelevant here, you'd need the full body of the function to be thread-safe if you need thread-safety even in code that happens before main.
AMDG On 09/05/2011 04:18 AM, Mathias Gaunard wrote:
On 02/09/2011 20:58, Martin Bidlingmaier wrote:
- 2. thread safety In c++03, variables defined at namespace scope are not necessarily initialized before main()
Yes they are.
No they aren't. From 3.6.2: "It is implementation-defined whether or not the dynamic initialization (8.5, 9.4, 12.1, 12.6.2) of an object of namespace scope is done before the first statement of main. If the initialization is deferred to some point in time after the first statement of main, it shall occur before the first use of any function or object defined in the same translation unit as the object to be initialized." In Christ, Steven Watanabe
on Mon Sep 05 2011, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
Really? I didn't pay attention to ever twist or turn of the process of standardizing multithreading, but it greatly surprises me to hear that, because it would impose an overhead on those function-static variables that don't need synchronization. Can you cite the paragraphs that give this guarantee? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Sep 5, 2011, at 2:17 PM, Dave Abrahams wrote:
on Mon Sep 05 2011, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
Really? I didn't pay attention to ever twist or turn of the process of standardizing multithreading, but it greatly surprises me to hear that, because it would impose an overhead on those function-static variables that don't need synchronization. Can you cite the paragraphs that give this guarantee?
SC-22-N-411, 6.7/4 "Declaration statement" says, while discussing initialization of an object with static storage duration the first time control passes through its declaration: If control enters the declaration concurrently while the object is being initialized, the concurrent execution shall wait for completion of the initialization.
On Mon, 2011-09-05 at 21:17 +0300, Dave Abrahams wrote:
on Mon Sep 05 2011, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
Really? I didn't pay attention to ever twist or turn of the process of standardizing multithreading, but it greatly surprises me to hear that, because it would impose an overhead on those function-static variables that don't need synchronization. Can you cite the paragraphs that give this guarantee?
In this draft version http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf the relevant paragraph seems to be 6.7.4. Mika Heiskanen
on Mon Sep 05 2011, Mika Heiskanen <mika.heiskanen-AT-fmi.fi> wrote:
On Mon, 2011-09-05 at 21:17 +0300, Dave Abrahams wrote:
on Mon Sep 05 2011, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
Really? I didn't pay attention to ever twist or turn of the process of standardizing multithreading, but it greatly surprises me to hear that, because it would impose an overhead on those function-static variables that don't need synchronization. Can you cite the paragraphs that give this guarantee?
In this draft version
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf
the relevant paragraph seems to be 6.7.4.
Thanks for the reference. FWIW, the FDIS (FINAL Draft International Standard) is N3290. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Sep 13, 2011 at 01:48:31PM -0400, Dave Abrahams wrote:
FWIW, the FDIS (FINAL Draft International Standard) is N3290.
And for some reason, not publically available since FDIS was set in stone, unless you managed to sneak a copy before it was obliterated from public access. It's in my opinion, profit be damned, quite silly to have the standard for one of the largest languages out there locked down behind a paywall. -- Lars Viklund | zao@acc.umu.se
Lars Viklund wrote:
On Tue, Sep 13, 2011 at 01:48:31PM -0400, Dave Abrahams wrote:
FWIW, the FDIS (FINAL Draft International Standard) is N3290.
And for some reason, not publically available since FDIS was set in stone, unless you managed to sneak a copy before it was obliterated from public access.
It's in my opinion, profit be damned, quite silly to have the standard for one of the largest languages out there locked down behind a paywall.
Running the standards organizations is not without costs. Charging for their output is a means to cover those costs. What's more, the standards are often considered of interest to implementers, not practitioners, of a language. (I'm not arguing whether the prices charged are appropriate, just that charging is not inappropriate.) _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"Stewart, Robert" wrote: [...]
Running the standards organizations is not without costs. Charging for their output is a means to cover those costs.
How come that ALL of ECMA standards (and technical reports) are available for downloading free of charge? http://www.ecma-international.org/publications/index.html "Ecma Standards and Technical Reports are made available as download to all interested persons or organizations, free of charge in PDF format (to obtain a PDF reader, go to e.g. the Adobe webpage or to a free software PDF reader). All Ecma Standards and Technical Reports are covered by the Ecma copyright disclaimer. How to obtain Ecma publications on CD-ROM and as paper document" regards, alexander.
Alexander Terekhov wrote:
"Stewart, Robert" wrote: [...]
Running the standards organizations is not without costs. Charging for their output is a means to cover those costs.
How come that ALL of ECMA standards (and technical reports) are available for downloading free of charge?
I have no certain idea. I think that the ECMA standardization process is less rigid, so that probably helps. However, the costs must be covered somehow. There are, no doubt, different models for doing so. I was just noting that there are costs and that charging for products is a means to cover those costs. I was not suggesting that there weren't other or possibly better ways. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
"Stewart, Robert" wrote:
Alexander Terekhov wrote:
"Stewart, Robert" wrote: [...]
Running the standards organizations is not without costs. Charging for their output is a means to cover those costs.
How come that ALL of ECMA standards (and technical reports) are available for downloading free of charge?
I have no certain idea. . . .
http://www.ecma-international.org/memento/ordinary.htm "For this category of membership, the annual fee for 2010 is CHF 70000.-. The following companies are currently ordinary members of Ecma: . . ." http://www.ecma-international.org/memento/associat.htm "For this category of membership, the annual fee for 2010 is CHF 35000.-. The following companies are currently associate members of Ecma: . . ." http://www.ecma-international.org/memento/SME.htm "For this category of membership, the annual fee for 2010 is CHF 17500.-. The following companies are currently SME members of Ecma: . . ." http://www.ecma-international.org/memento/SPC.htm "For this category of membership, the annual fee for 2010 is CHF 3500.-." http://www.ecma-international.org/memento/NFP.htm "Not-for-profit Members (NFP) NFP members are non-profit-making organizations. If an NFP is an organization with several organizations as members, then normally it can only become an NFP member in Ecma if its members do not qualify for Company membership in Ecma. For this category of membership, there is no annual fee. The following organizations are currently NFP members of Ecma: . . ." regards, alexander.
At this point I think this thread is, well, not quite OT, but not very usefully-located. This isn't really a Boost or library issue, and the people who can answer the burning questions are mostly not on this list. I suggest moving it to comp.std.c++ on Fri Sep 16 2011, Alexander Terekhov <terekhov-AT-web.de> wrote: <lots of stuff> Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Fri, Sep 16, 2011 at 3:00 PM, Dave Abrahams <dave@boostpro.com> wrote:
At this point I think this thread is, well, not quite OT, but not very usefully-located. This isn't really a Boost or library issue, and the people who can answer the burning questions are mostly not on this list. I suggest moving it to comp.std.c++
on Fri Sep 16 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
<lots of stuff>
+1 Also, from a C++ committee mailing list post yesterday, "INCITS [aka ANSI] has started the process to adopt ISO/IEC 14882:2011 [C++11]; early 2012 is a realistic target date; once the process is complete, the cost of the INCITS standard will be $30 (USD)." --Beman
Beman Dawes wrote: [...]
Also, from a C++ committee mailing list post yesterday, "INCITS [aka ANSI] has started the process to adopt ISO/IEC 14882:2011 [C++11]; early 2012 is a realistic target date; once the process is complete, the cost of the INCITS standard will be $30 (USD)."
As a matter of principle I don't want to finance INCITS (merely U.S. organization) and won't pay even $0.03. regards, alexander.
on Tue Sep 13 2011, Lars Viklund <zao-AT-acc.umu.se> wrote:
On Tue, Sep 13, 2011 at 01:48:31PM -0400, Dave Abrahams wrote:
FWIW, the FDIS (FINAL Draft International Standard) is N3290.
And for some reason, not publically available since FDIS was set in stone, unless you managed to sneak a copy before it was obliterated from public access.
It's in my opinion, profit be damned, quite silly to have the standard for one of the largest languages out there locked down behind a paywall.
FWIW 1: It's a big concern among committee members, too, and there has recently been lots of discussion about this on our reflector. Unfortunately, prices are set by ISO. FWIW 2: We expect INCITS to start selling the standard for $30 early next year. HTH, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
on Tue Sep 13 2011, Lars Viklund <zao-AT-acc.umu.se> wrote:
On Tue, Sep 13, 2011 at 01:48:31PM -0400, Dave Abrahams wrote:
FWIW, the FDIS (FINAL Draft International Standard) is N3290.
And for some reason, not publically available since FDIS was set in stone, unless you managed to sneak a copy before it was obliterated from public access.
It's in my opinion, profit be damned, quite silly to have the standard for one of the largest languages out there locked down behind a paywall.
FWIW 1: It's a big concern among committee members, too, and there has recently been lots of discussion about this on our reflector. Unfortunately, prices are set by ISO.
FWIW 2: We expect INCITS to start selling the standard for $30 early next year.
There are very many ISO/IEC standards priced at zero, see: http://standards.iso.org/ittf/PubliclyAvailableStandards/ What is the problem to set zero price for ISO/IEC IS 14882? regards, alexander.
On Fri, Sep 16, 2011 at 12:21:18PM +0200, Alexander Terekhov wrote:
Dave Abrahams wrote:
FWIW 1: It's a big concern among committee members, too, and there has recently been lots of discussion about this on our reflector. Unfortunately, prices are set by ISO.
FWIW 2: We expect INCITS to start selling the standard for $30 early next year.
I never realized why some venues sold it for 1/10th of the price, as I didn't really notice the distinction between INCITS/BSI and ISO before. While $30 is a decent price point, it's still a bit bothersome as you cannot reliably point people at chapter&verse when discussing or teaching the language, instead having to paraphrase, extract a snippet or insist that the standard really says what you claim it does. Personally I'm going to buy the cheap PDF when it's available or continue using my copy of N3290, but there's a lot of people out there for which $30 has significant value (young people, developing countries, etc.).
There are very many ISO/IEC standards priced at zero, see:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
What is the problem to set zero price for ISO/IEC IS 14882?
A wild guess is that they might have had much less overhead than the C++ and C standards. After all, not all standards take over a decade of work to produce with multiple meetings every year all over the world. -- Lars Viklund | zao@acc.umu.se
on Fri Sep 16 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote:
on Tue Sep 13 2011, Lars Viklund <zao-AT-acc.umu.se> wrote:
On Tue, Sep 13, 2011 at 01:48:31PM -0400, Dave Abrahams wrote:
FWIW, the FDIS (FINAL Draft International Standard) is N3290.
And for some reason, not publically available since FDIS was set in stone, unless you managed to sneak a copy before it was obliterated from public access.
It's in my opinion, profit be damned, quite silly to have the standard for one of the largest languages out there locked down behind a paywall.
FWIW 1: It's a big concern among committee members, too, and there has recently been lots of discussion about this on our reflector. Unfortunately, prices are set by ISO.
FWIW 2: We expect INCITS to start selling the standard for $30 early next year.
There are very many ISO/IEC standards priced at zero, see:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
What is the problem to set zero price for ISO/IEC IS 14882?
Sorry, I just don't know. As convener, Herb Sutter deals with the governing bodies a lot. If you're curious, you might ask him. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote: [... setting zero price for C++ standard ...]
Sorry, I just don't know. As convener, Herb Sutter deals with the governing bodies a lot. If you're curious, you might ask him.
Perhaps he could share his insights in a post to this thread? Could you please drop him an email (an email from me is more likely to die in his spam folder). BTW, I found this: http://www.iso.org/iso/iso_in_figures_2010.pdf (Financing) "140 million CHF per year is the estimated cost for the operation of committee secretariats financed 38 by member bodies holding these secretariats 36 million CHF represents the operational cost of the ISO Central Secretariat financed 53% through membership fees 47% through sales of publications and other income from services" It would be really interesting to know how much exactly ISO gets from sales of C++ PDFs (and whether making them free would really bankrupt ISO)... See also: http://www.acm.org/tsc/acmfree.htm regards, alexander.
on Sat Sep 17 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote:
[... setting zero price for C++ standard ...]
Sorry, I just don't know. As convener, Herb Sutter deals with the governing bodies a lot. If you're curious, you might ask him.
Perhaps he could share his insights in a post to this thread?
Could you please drop him an email (an email from me is more likely to die in his spam folder).
I doubt he would post here, because, well, this isn't really the best forum for it. Please take your question over to comp.std.c++ and I'll be sure that he knows you're posting over there.
BTW, I found this:
http://www.iso.org/iso/iso_in_figures_2010.pdf (Financing)
"140 million CHF per year is the estimated cost for the operation of committee secretariats financed 38 by member bodies holding these secretariats 36 million CHF represents the operational cost of the ISO Central Secretariat financed 53% through membership fees 47% through sales of publications and other income from services"
It would be really interesting to know how much exactly ISO gets from sales of C++ PDFs (and whether making them free would really bankrupt ISO)...
See also:
http://www.acm.org/tsc/acmfree.htm
regards, alexander.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote: [...]
I doubt he would post here, because, well, this isn't really the best forum for it. Please take your question over to comp.std.c++
Done, see below.
and I'll be sure that he knows you're posting over there.
-------- Original Message -------- X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Message-ID: <4E74D9DE.A49152FC@web.de> Date: Sat, 17 Sep 2011 19:33:18 +0200 From: Alexander Terekhov <terekhov@web.de> Reply-To: terekhov@web.de X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.std.c++ Subject: Cost of standards documents (was: [any] new version)] [was: boost] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit < forward quoted > Dave Abrahams wrote:
on Sat Sep 17 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote:
[... setting zero price for C++ standard ...]
Sorry, I just don't know. As convener, Herb Sutter deals with the governing bodies a lot. If you're curious, you might ask him.
Perhaps he could share his insights in a post to this thread?
Could you please drop him an email (an email from me is more likely to die in his spam folder).
I doubt he would post here, because, well, this isn't really the best forum for it. Please take your question over to comp.std.c++ and I'll be sure that he knows you're posting over there.
BTW, I found this:
http://www.iso.org/iso/iso_in_figures_2010.pdf (Financing)
"140 million CHF per year is the estimated cost for the operation of committee secretariats financed 38 by member bodies holding these secretariats 36 million CHF represents the operational cost of the ISO Central Secretariat financed 53% through membership fees 47% through sales of publications and other income from services"
It would be really interesting to know how much exactly ISO gets from sales of C++ PDFs (and whether making them free would really bankrupt ISO)...
See also:
http://www.acm.org/tsc/acmfree.htm
regards, alexander.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
regards, alexander.
Dave Abrahams wrote: [...]
I doubt he would post here, because, well, this isn't really the best forum for it. Please take your question over to comp.std.c++ and I'll be sure that he knows you're posting over there.
<ping> Is Herb Sutter alive? regards, alexander.
on Tue Sep 27 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote: [...]
I doubt he would post here, because, well, this isn't really the best forum for it. Please take your question over to comp.std.c++ and I'll be sure that he knows you're posting over there.
<ping>
Is Herb Sutter alive?
I don't know; I sometimes think he's a brilliantly-engineered cyborg. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
on Tue Sep 27 2011, Alexander Terekhov <terekhov-AT-web.de> wrote:
Dave Abrahams wrote: [...]
I doubt he would post here, because, well, this isn't really the best forum for it. Please take your question over to comp.std.c++ and I'll be sure that he knows you're posting over there.
<ping>
Is Herb Sutter alive?
I don't know; I sometimes think he's a brilliantly-engineered cyborg.
A more or less functional cyborg Herb Sutter would have no problems to post a reply to http://groups.google.com/group/comp.std.c++/browse_thread/thread/d277050e453... Is he currently in a shutdown mode? I guess so. regards, alexander.
Alexander Terekhov wrote:
Dave Abrahams wrote:
on Tue Sep 13 2011, Lars Viklund <zao-AT-acc.umu.se> wrote:
On Tue, Sep 13, 2011 at 01:48:31PM -0400, Dave Abrahams wrote:
FWIW, the FDIS (FINAL Draft International Standard) is N3290.
And for some reason, not publically available since FDIS was set in stone, unless you managed to sneak a copy before it was obliterated from public access.
It's in my opinion, profit be damned, quite silly to have the standard for one of the largest languages out there locked down behind a paywall.
FWIW 1: It's a big concern among committee members, too, and there has recently been lots of discussion about this on our reflector. Unfortunately, prices are set by ISO.
FWIW 2: We expect INCITS to start selling the standard for $30 early next year.
There are very many ISO/IEC standards priced at zero, see:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
What is the problem to set zero price for ISO/IEC IS 14882?
Those free standards seem to have a large corporation or international organization as a sponsor. So we have already payed for them. Bo Persson
Bo Persson wrote: [...]
There are very many ISO/IEC standards priced at zero, see:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
What is the problem to set zero price for ISO/IEC IS 14882?
Those free standards seem to have a large corporation or international organization as a sponsor.
Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/meetings I see names of not small corporations such as IBM, Microsoft, Google, etc. listed as Corporate Sponsors. regards, alexander.
Alexander Terekhov wrote:
Bo Persson wrote: [...]
There are very many ISO/IEC standards priced at zero, see:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
What is the problem to set zero price for ISO/IEC IS 14882?
Those free standards seem to have a large corporation or international organization as a sponsor.
Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/meetings I see names of not small corporations such as IBM, Microsoft, Google, etc. listed as Corporate Sponsors.
Yes, that might be the problem. For some reason the free standards seem to have a SINGLE sponsor. Wonder why? Bo Persson
Bo Persson wrote:
Alexander Terekhov wrote:
Bo Persson wrote: [...]
There are very many ISO/IEC standards priced at zero, see:
http://standards.iso.org/ittf/PubliclyAvailableStandards/
What is the problem to set zero price for ISO/IEC IS 14882?
Those free standards seem to have a large corporation or international organization as a sponsor.
Looking at http://www.open-std.org/jtc1/sc22/wg21/docs/meetings I see names of not small corporations such as IBM, Microsoft, Google, etc. listed as Corporate Sponsors.
Yes, that might be the problem.
For some reason the free standards seem to have a SINGLE sponsor. Wonder why?
The names I mentioned are listed as ECMA ordinary members http://www.ecma-international.org/memento/ordinary.htm and that doesn't prevent all of ECMA standards to be free of charge for downloading. I never understood why C++ committee members do not want to simply get rid of ISO for development and develop under ECMA with fast tracing to ISO finished ECMA standard... regards, alexander.
On 17/09/2011 13:42, Alexander Terekhov wrote:
Bo Persson wrote:
...
Yes, that might be the problem.
For some reason the free standards seem to have a SINGLE sponsor. Wonder why?
The names I mentioned are listed as ECMA ordinary members
http://www.ecma-international.org/memento/ordinary.htm
and that doesn't prevent all of ECMA standards to be free of charge for downloading.
I never understood why C++ committee members do not want to simply get rid of ISO for development and develop under ECMA with fast tracing to ISO finished ECMA standard...
simple really. ECMA is commercial organization with high membership fees (which explains why they can afford to give away standards). Its role is mostly rubber-stamping standards agreed internally by the member(s) and so the quality varies by a large degree. The are no panels of technical experts, the process is only as open as convenient to member organizations and takes no, or very little, external input. You probably wouldn't be able to contribute to ECMA work in any manner if not employed by a member organization. Due to fees involved few small organizations are involved in ECMA. ISO is international organization whose members are national standarization bodies, membership fees (if any) are smaller than in ECMA and quality of standards is uniformly higher. It is possible for both individuals and small organizations to contribute to ISO work. Of course it may look differently in different countries, depending on bureaucracy surrounding any particular national standarization body, but in general the process is open and works. Few bother to actually contribute to ISO (majority just whine), but some do and their work is not ignored. Having said that, I agree the price for a copy of C++ 2011 standard is much too high and was happy to learn it's going to be much lower by 2012. If you don't want to buy it from American standarization body, go to your national one and ask if you can contribute to work of ISO/IEC committee JTC1/SC22/WG21 - technical experts have free access to relevant ISO documents, including copy of standard. B. PS. just this one post in case someone read Alexander's post and wondered "yes, why?"
Bronek Kozicki wrote: [...]
simple really. ECMA is commercial organization . . .
Full stop right here. http://www.ecma-international.org/activities/General/presentingecma.pdf (Facts 2 of 3) "Ecma International is a not-for-profit association under Swiss Law/Geneva, established in 1961 Purpose of Ecma: Development and publication of standards/TRs for Information & Communication Technology and Consumer Electronics Track record: 499 publications, many also published by ISO/IEC Ecma publications are free of charge and can be freely downloaded from the Ecma website www.ecma-international.org A-liaison with ISO/IEC JTC 1 accelerates Ecma technical input into JTC 1 ISO/IEC fast-track procedure (5-month international ballot) originally proposed by Ecma and accepted in 1987" regards, alexander.
On 17/09/2011 17:45, Alexander Terekhov wrote:
Bronek Kozicki wrote: [...]
simple really. ECMA is commercial organization . . .
Full stop right here.
is anything else I wrote incorrect? B. On 17/09/2011 17:10, Bronek Kozicki wrote: ... with high membership fees
(which explains why they can afford to give away standards). Its role is mostly rubber-stamping standards agreed internally by the member(s) and so the quality varies by a large degree. The are no panels of technical experts, the process is only as open as convenient to member organizations and takes no, or very little, external input. You probably wouldn't be able to contribute to ECMA work in any manner if not employed by a member organization. Due to fees involved few small organizations are involved in ECMA.
ISO is international organization whose members are national standarization bodies, membership fees (if any) are smaller than in ECMA and quality of standards is uniformly higher. It is possible for both individuals and small organizations to contribute to ISO work. Of course it may look differently in different countries, depending on bureaucracy surrounding any particular national standarization body, but in general the process is open and works. Few bother to actually contribute to ISO (majority just whine), but some do and their work is not ignored.
Having said that, I agree the price for a copy of C++ 2011 standard is much too high and was happy to learn it's going to be much lower by 2012. If you don't want to buy it from American standarization body, go to your national one and ask if you can contribute to work of ISO/IEC committee JTC1/SC22/WG21 - technical experts have free access to relevant ISO documents, including copy of standard.
Bronek Kozicki wrote:
On 17/09/2011 17:45, Alexander Terekhov wrote:
Bronek Kozicki wrote: [...]
simple really. ECMA is commercial organization . . .
Full stop right here.
is anything else I wrote incorrect?
I think yes, but before you ask me for details, check with Abrahams and Dawes whether we can continue the discussion here without being called to stop once again. regards, alexander.
On 17 September 2011 14:06, Alexander Terekhov <terekhov@web.de> wrote:
I think yes, but before you ask me for details, check with Abrahams and Dawes whether we can continue the discussion here without being called to stop once again.
1. This has nothing to do with Boost. 2. You already got answers to ISO vs. ECMA when your brought it up on Usenet 3 months ago. Feigning ignorance of that discussion is bad form. https://groups.google.com/forum/#!search/Latest$20draft$20of$20C$2B$2B$2011$... (For those who aren't going to read it, the rough answer is that the price to participate for for-profit organizations is an order of magnitude more, which would result in even fewer people working on the standardization effort.) -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
Nevin Liber wrote: [...] https://groups.google.com/forum/#!search/Latest$20draft$20of$20C$2B$2B$2011$...
(For those who aren't going to read it, the rough answer is that the price to participate for for-profit organizations is an order of magnitude more, which would result in even fewer people working on the standardization effort.)
If you mean a message from Pete Becker saying that "Last time I looked, it would have cost me $15,000 per year to participate in ECMA. For ISO, through INCITS, the fee is $1200. It's very generous of you to suggest that I pay over ten times as much as I currently do so that you can get a free copy of the standard." please note that he may participate in ECMA as a hired expert by some non-profit ECMA member for even less than $1200 (for $0 in fees to ECMA). Recall also that many corporate sponsors of WG21 are already members of ECMA. So the conclusion that ECMA "would result in even fewer people working on the standardization effort" is without evidence, to say the least. regards, alexander.
On 9/17/2011 11:10 AM, Bronek Kozicki wrote:
[...]
Having said that, I agree the price for a copy of C++ 2011 standard is much too high and was happy to learn it's going to be much lower by 2012. If you don't want to buy it from American standarization body, go to your national one and ask if you can contribute to work of ISO/IEC committee JTC1/SC22/WG21 - technical experts have free access to relevant ISO documents, including copy of standard.
ISO web site actually says
Orders for *ISO standards* and other *ISO publications* should normally be addressed to the ISO member in your country.
http://www.iso.org/iso/store/purchasing_from_iso_members.htm It means that if you are not in the United States you are not supposed to by the $30 version and pay anything to any US organizations. I guess it addresses this issue:
As a matter of principle I don't want to finance INCITS (merely U.S. organization) and won't pay even $0.03.
-- Ilya Bobyr
On 05/09/2011 20:17, Dave Abrahams wrote:
on Mon Sep 05 2011, Mathias Gaunard<mathias.gaunard-AT-ens-lyon.org> wrote:
The C++11 standard (the only one aware of multithreading) mandates that initialization of static variables at function scope is thread-safe.
Really? I didn't pay attention to ever twist or turn of the process of standardizing multithreading, but it greatly surprises me to hear that, because it would impose an overhead on those function-static variables that don't need synchronization. Can you cite the paragraphs that give this guarantee?
It's not surprising, it's the only way to make them usable. GCC had already been doing this for a long time.
Mathias Gaunard wrote:
On 05/09/2011 20:17, Dave Abrahams wrote:
Really? I didn't pay attention to ever twist or turn of the process of standardizing multithreading, but it greatly surprises me to hear that, because it would impose an overhead on those function-static variables that don't need synchronization. Can you cite the paragraphs that give this guarantee?
It's not surprising, it's the only way to make them usable. GCC had already been doing this for a long time.
As you obviously didn't answer the question, you seem to be unable to cite the paragraphs at the moment. But I'm curious. Did you actually read this in the standard yourself (and now just have problems to find the paragraphs again), or did you pick up this information indirectly (for example by browsing clang, gcc or msvc related information like bug reports or mailing lists)? Regards, Thomas
On 6 September 2011 12:41, Thomas Klimpel <Thomas.Klimpel@synopsys.com> wrote:
But I'm curious. Did you actually read this in the standard yourself (and now just have problems to find the paragraphs again), or did you pick up this information indirectly (for example by browsing clang, gcc or msvc related information like bug reports or mailing lists)?
GCC 4.5 man pages: " -fno-threadsafe-statics Do not emit the extra code to use the routines specified in the C++ ABI for thread-safe initialization of local statics. You can use this option to reduce code size slightly in code that doesn't need to be thread-safe." C++11 6.7p4 Declaration statement (talking about block-scope variables with static storage duration)t: "If control enters the declaration concurrently while the variable is being initialized, the concurrent execution shall wait for completion of the initialization." -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 06/09/2011 19:41, Thomas Klimpel wrote:
As you obviously didn't answer the question, you seem to be unable to cite the paragraphs at the moment.
I didn't give the citation because it was already given in another sub-thread. I was just reacting to part of his comment, I guess I didn't quote very well. I do not find this decision that the standard took surprising; it seems like the natural and logical choice. It requires overhead, but it's the only way to make it work with re-entrant functions, which is the most basic guarantee all multi-threaded functions should fulfill.
Hi all, I see another solution for the cross-dll problem, but it has two disavantages: 1) it is not possible in a header-only library. 2) initialization type_id< T >::value is much slower. ( but any_cast() will be as fast ) If this is unacceptable, then it doesn't worth to continue reading this. Otherwise, the solution is to combine the numerical id approach ( to gain performance in any_cast() ) with RTTI Instead of using function next_id(), we do: template< class T > unsigned int type_id< T >::value = get_int_type_id<T>(); Function get_int_type_id<T> aways returns the same value for the same type T regardless of the library it is called from. To achieve this, a std::map is used ( although std::set maybe is more approprieate. I used std::map to make the sample code simpler ). This map takes typeid(T).name() as the key, and returns a unique integer value. This map would be instantiated in the compiled library any.a ( or any.so or any.dll ) Regards, Roberto Hinz
From: Martin Bidlingmaier <Martin.Bidlingmaier@gmx.de>
I've written a new version of boost::any. It does not depend on rtti and uses a static integer value instead of std::type_info to store type information.
Instead of reinventing the RTTI wheel. See following: There are 5 implementations of any using different methods linux windows boost 8.45 70.8 boost.any 1.46 any1 8.45 31.4 virtual impl->type() == typeid(Cast) any2 3.9 17.1 *this->type_ == typeid(Cast) any3 10.15 35.2 strcmp(this->type_->name(),typeid(Cast).name()) == 0 any4 4.5 12.5 this->type_ == &typeid(Cast) || *this->type_ == typeid(Cast) The first any implements the Boost.Any method - virtual call to get type compare to casted type and then cast. Other any2 to any 4 store pointer to typeid in the any object itself eliminating needless virtual call so any looks like { std::type_info const *type_; clone_ptr<impl> *impl; } 3 methods proposed: any2. compare types as is any3. compare names any4. compare pointer and then types. The 4th one should has the same efficiency as comparing integers and in fact on windows it was the fastest and on Linux comparing typeids was the fastest. What is good about it? 1. No virtual function calls at all 2. It is as fast as comparison of pointers or integers 3. It is fully dll/thread/standard safe and use native RTTI So... You want to improve any? Keep RTTI just use it in a smart way. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/ ----------------------- any.h -------- #include <booster/clone_ptr.h> #include <typeinfo> #include <iostream> #include <string.h> #ifdef USE_BOOST #include <boost/any.hpp> using boost::any; using boost::any_cast; #elif defined(USE_ANY1) class any { struct impl { virtual std::type_info const &type() const = 0; virtual impl *clone() const = 0; virtual ~impl() {} }; template<typename T> struct impl_of : public impl{ impl_of(T const &v) : v_(v) {} virtual impl *clone() const { return new impl_of(*this); } virtual std::type_info const &type() const { return typeid(T); } T v_; }; public: template<typename T> any(T const &v) : o(new impl_of<T>(v)) { } any(any const &other) : o(other.o) {} any const &operator=(any const &other) { o = other.o; return *this; } template<typename V> V &cast() { if(o->type() == typeid(V)) return static_cast<impl_of<V> *>(o.get())->v_; throw std::bad_cast(); } private: booster::clone_ptr<impl> o; }; template<typename T> T &any_cast(any &v) { return v.cast<T>(); } #elif defined USE_ANY2 || defined USE_ANY3 || defined USE_ANY4 class any { struct impl { virtual impl *clone() const = 0; virtual ~impl() {} }; template<typename T> struct impl_of : public impl{ impl_of(T const &v) : v_(v) {} virtual impl *clone() const { return new impl_of(*this); } T v_; }; public: template<typename T> any(T const &v) : o(new impl_of<T>(v)), type(&typeid(T)) { } any(any const &other) : o(other.o) {} any const &operator=(any const &other) { o = other.o; return *this; } template<typename V> V &cast() { #ifdef USE_ANY3 if(strcmp(type->name(),typeid(V).name())==0) #elif defined(USE_ANY2) if(*type==typeid(V)) #elif defined USE_ANY4 if(type == &typeid(V) || *type==typeid(V)) #else #error #endif return static_cast<impl_of<V> *>(o.get())->v_; throw std::bad_cast(); } private: booster::clone_ptr<impl> o; std::type_info const *type; }; template<typename T> T &any_cast(any &v) { return v.cast<T>(); } #endif test.cpp ---------- #include "any.h" // prevent inlining int get_val(any &v); int main() { any a=int(2); int sum=0; for(int i=0;i<1000000000;i++) { sum+= get_val(a); } std::cout << sum << std::endl; } getval.cpp ---------- #include "any.h" int get_val(any &v) { return any_cast<int>(v); }
On 09/03/2011 06:25 PM, Artyom Beilis wrote:
linux windows boost 8.45 70.8 boost.any 1.46 any1 8.45 31.4 virtual impl->type() == typeid(Cast) any2 3.9 17.1 *this->type_ == typeid(Cast) any3 10.15 35.2 strcmp(this->type_->name(),typeid(Cast).name()) == 0 any4 4.5 12.5 this->type_ ==&typeid(Cast) || *this->type_ == typeid(Cast)
The first any implements the Boost.Any method - virtual call to get type compare to casted type and then cast.
What if we keep the pointer to the type_info in impl, but make it directly accessible, not via a virtual call? This would keep sizeof(any) to one pointer and only add one indirection to any4. IMHO, that would be the best solution.
----- Original Message -----
From: Andrey Semashev <andrey.semashev@gmail.com> To: boost@lists.boost.org Cc: Sent: Sunday, September 4, 2011 10:19 AM Subject: Re: [boost] [any] new version
On 09/03/2011 06:25 PM, Artyom Beilis wrote:
linux windows boost 8.45 70.8 boost.any 1.46 any1 8.45 31.4 virtual impl->type() == typeid(Cast) any2 3.9 17.1 *this->type_ == typeid(Cast) any3 10.15 35.2 strcmp(this->type_->name(),typeid(Cast).name())
== 0
any4 4.5 12.5 this->type_ ==&typeid(Cast) || *this->type_ == typeid(Cast)
The first any implements the Boost.Any method - virtual call to get type compare to casted type and then cast.
What if we keep the pointer to the type_info in impl, but make it directly accessible, not via a virtual call? This would keep sizeof(any) to one pointer and only add one indirection to any4. IMHO, that would be the best solution.
This is fine as well. However I don't see too much advantage of having one pointer instead of two. The most important is **not reinvent** RTTI as it would not work well. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On 09/04/2011 11:32 AM, Artyom Beilis wrote:
What if we keep the pointer to the type_info in impl, but make it directly accessible, not via a virtual call? This would keep sizeof(any) to one pointer and only add one indirection to any4. IMHO, that would be the best solution.
This is fine as well. However I don't see too much advantage of having one pointer instead of two.
Empty anys will take less space, which may be significant. Moving and swapping will also be cheaper.
The most important is **not reinvent** RTTI as it would not work well.
No argument from me on that. :)
on Sun Sep 04 2011, Andrey Semashev <andrey.semashev-AT-gmail.com> wrote:
On 09/04/2011 11:32 AM, Artyom Beilis wrote:
What if we keep the pointer to the type_info in impl, but make it directly accessible, not via a virtual call? This would keep sizeof(any) to one pointer and only add one indirection to any4. IMHO, that would be the best solution.
This is fine as well. However I don't see too much advantage of having one pointer instead of two.
Empty anys will take less space, which may be significant. Moving and swapping will also be cheaper.
+1 -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (26)
-
Agustín K-ballo Bergé -
Alexander Terekhov -
Andrey Semashev -
Artyom Beilis -
Beman Dawes -
Bo Persson -
Bronek Kozicki -
Dave Abrahams -
Emil Dotchevski -
Emil Dotchevski -
Ilya Bobir -
Ilya Bobyr
-
Jeffrey Lee Hellrung, Jr. -
Julien Nitard -
Kim Barrett -
Lars Viklund -
Martin Bidlingmaier -
Mathias Gaunard -
Mika Heiskanen -
Nevin Liber -
Nigel Stewart -
Roberto Hinz -
Roman Perepelitsa -
Steven Watanabe -
Stewart, Robert -
Thomas Klimpel