- merge C callbacks into C++ class? - 9 Updates
- about name mangling - 3 Updates
- Usage of comma operator - 1 Update
- class of unsigned 32 bit and overflow - 1 Update
- The core of the core of the big data solutions -- Map - 2 Updates
| red floyd <no.spam@its.invalid>: Jun 02 04:58PM -0700 On 6/2/2015 12:43 PM, Chris Vine wrote: > extract from the standard above, that is not a requirement of the > standard, and ICC is reputed not to do so (but I have never tested > that). What would be really nice is to be able to declare static member functions with C linkage e.g.: class callback_t { static "C" callback(void *p) // not currently valid syntax { static_cast<callback_t *>(p)->handler(); } void handler(); public: register_callback() { some_C_api(&callback,this); } }; |
| "Öö Tiib" <ootiib@hot.ee>: Jun 03 05:19AM -0700 On Wednesday, 3 June 2015 02:04:36 UTC+3, Richard wrote: > >static members having the wrong linkage, but some do. > It *still* doesn't need to be friend. Friend in C++ is the unix > equivalent of "run all my servers as root". Is there really such a difference between static member and friend function? I imagine something like that: // With friend class friendly { friend extern "C" void callback_friendly(void *p) { // do what it got to do } public: register_callback() { some_C_api(&callback_friendly,this); // conforming } // ... rest of the class }; // With static class statical { static void callback_statical(void *p) { // do exactly same things like the 'friendly' did } public: register_callback() { some_C_api(&callback_statical,this); // conformance missing // but often works } // ... rest of the class }; Might be there are some nuances I miss. Can you elaborate what is the important problem? |
| "Öö Tiib" <ootiib@hot.ee>: Jun 03 05:37AM -0700 On Tuesday, 2 June 2015 20:48:32 UTC+3, Richard wrote: > The static method does not have to be declared extern "C" because > noone is linking to it from a C source file; it is linked within a C++ > source file. Your code example assumes that there are no difference between: typedef void callback_fn_t(void *context); and extern "C" typedef void callback_fn_t(void *context); It is so with gcc, but nothing guarantees that in C++ standard. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 03 06:04PM +0100 On Tue, 02 Jun 2015 16:58:08 -0700 > On 6/2/2015 12:43 PM, Chris Vine wrote: [snip] > > is responsible for resetting stack pointers on exit). > > As it happens, gcc and clang use the same calling convention for > > static member functions and for plain functions. But as mentioned By "plain functions" I of course meant "plain functions with C language linkage". > some_C_api(&callback,this); > } > }; It would be nice but there is a technical problem in doing this, which is that giving a function C language linkage suppresses name mangling: a requirement of C language linkage is that the function concerned should be callable by name (not just by function pointer) by C code expecting C language linkage. If two unrelated classes could have static member functions of the same name both of which are declared to have C language linkage, then there would be a name clash. Chris |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 03 06:04PM +0100 On Tue, 2 Jun 2015 23:04:27 +0000 (UTC) > Ian Collins <ian-news@hotmail.com> spake the secret code > <ct6cqjFj1qjU1@mid.individual.net> thusly: [snip] > >about static members having the wrong linkage, but some do. > It *still* doesn't need to be friend. Friend in C++ is the unix > equivalent of "run all my servers as root". You could say exactly the same of a public member function (static or non-static). Friend functions are the only portable way of implementing callback functions with C language linkage which require access to private or protected members of a class. The main problem with the declaration of a friend function is that you have to declare it together with the class definition, which means that you cannot confine it to the implementation (.cc/.cpp) file and give it internal linkage where that would otherwise be possible. The same is equally true of course of static and non-static member functions. Chris |
| Martin Shobe <martin.shobe@yahoo.com>: Jun 03 12:18PM -0500 On 6/3/2015 12:04 PM, Chris Vine wrote: > expecting C language linkage. If two unrelated classes could have > static member functions of the same name both of which are declared to > have C language linkage, then there would be a name clash. Is it anymore of a problem than it currently is with namespaces? Martin Shobe |
| scott@slp53.sl.home (Scott Lurndal): Jun 03 05:35PM >non-static). Friend functions are the only portable way of >implementing callback functions with C language linkage which require >access to private or protected members of a class. I disagree. extern "C" void callback_function(void *arg); void callback_function(void *arg) { Classname *classpointer = static_cast<Classname *>(arg); classpointer->callback(); } c_library_function_register_callback(callback_function, this); portable yet friendless. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 03 10:40PM +0100 On Wed, 03 Jun 2015 17:35:34 GMT > } > c_library_function_register_callback(callback_function, this); > portable yet friendless. You do not disagree. Classname::callback() must be public for this to work. If Classname::callback() were protected or private, callback_function() would need to be a friend. Chris |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 03 10:50PM +0100 On Wed, 03 Jun 2015 12:18:29 -0500 > > are declared to have C language linkage, then there would be a name > > clash. > Is it anymore of a problem than it currently is with namespaces? Not with named namespaces. As you suggest, a named namespace is ignored for any function declared within the namespace with C language linkage, leading (for those who don't know that) to the possibility of name clashes between such functions declared with the same name within different namespaces. However, in C++11/14 (but not C++98/03), unnamed namespaces are effective for functions with C linkage in enforcing internal linkage (that is, it has the same effect as applying the static keyword). The lesson: in C++11/14 do not declare functions within a named namespace with C language linkage; and with C++98/03 don't do it within an unnamed namespace either. However, I was answering a question about why static member functions cannot have C language linkage. Chris |
| Rosario19 <Ros@invalid.invalid>: Jun 03 09:34AM +0200 why here, in C++, at point of vew of name mangling int f(int a){} and char* f(int a){} have the same name? at last here seems so... |
| Wouter van Ooijen <wouter@voti.nl>: Jun 03 10:05AM +0200 Rosario19 schreef op 03-Jun-15 om 9:34 AM: > char* f(int a){} > have the same name? > at last here seems so... Because in C++ the return type is not part of the signature of a function: it plays no role in determining which function is called, hence there is no need at link time for different names for those two functions. (There are languages, for instance Ada, where the return type *is* part of the signature. This adds some power to the language, but makes parsing - both by humans and by compilers and other tools - of the language much harder.) Wouter |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 03 07:44PM On Wed, 2015-06-03, Wouter van Ooijen wrote: > of the signature. This adds some power to the language, but makes > parsing - both by humans and by compilers and other tools - of the > language much harder.) I think there is some more fundamental reason the return type is not part of the signature in C++ -- Stroustrup writes about it in "Design and Evolution", I think. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| alexis.viger@gmail.com: Jun 03 11:34AM -0700 On Wednesday, September 25th 1991 09:34:32 UTC-4, John F. Woods wrote : > Always code as if the guy who ends up maintaining your code will be a > violent psychopath who knows where you live. Code for readability. Hey John, did you know that this quote would become so popular more than twenty years later ? YOU WERE RIGHT ALL ALONG !!! |
| asetofsymbols@gmail.com: Jun 03 09:16AM -0700 I wrote:" ou32& operator*=(const ou32& a){v=u32omul(v, a.v); R *this;} ou32& operator+=(const ou32& a){v=u32oadd(v, a.v); R *this;} ou32& operator-=(const ou32& a){v=u32osub(v, a.v); R *this;} ou32& operator/=(const ou32& a){if(v==-1||a.v==-1||a.v==0) v=-1; else v=v/a.v; R *this; }" So the above would not allow this ou32 a; a=39; a/=a; But the compiler compile and the program run seems ok with a=1 |
| Wenwei Peng <pww19710430@gmail.com>: Jun 03 12:17AM -0700 Title: The core of the big data solutions -- Map. Author: pengwenwei Email: pww71@foxmail.com Language: c++ Platform: Windows, linux Technology: Perfect hash algorithm Level: Advanced Description: A high performance map algorithm Section MFC c++ map stl SubSection c++ algorithm License: (GPLv3) Map is widely used in c++ programs. Its performance is critical to programs' performance. Especially in big data and the scenarios which can't realize data distribution and parallel processing. I have been working on big data analysis for many years in telecommunition and information security industry. The data analysis is so complicated that they can't work without map. Especially in information security industry, the data is much more complicated than others. For example, ip table, mac table, telephone numbers table, dns table etc. Currently, the STL map and Google's hash map are the most popular maps. But they have some disadvantages. The STL map is based on binary chop, which causes a bad performance. Google Hash map has the best performance at present, but it has probability of collision. For big data analysis, the collision probability is unacceptable. Now I would like to publish pwwMap. It includes three different maps for different scenarios: 1. Memory Map(memMap): It has a good access speed. But its size is limited by memory size. 2. Harddisk Map(diskMap): It utilizes hard disk to store data. So it could accept much more data than memory map. 3. Hashmap(hashMap): It has the best performance and a great lookup speed, but it doesn't have 'insert' and 'delete' functionality. MemMap and diskMap could be converted to hashMap by function memMap2HashMap and diskMap2HashMap. According to the test result, my algorithms' collision probability is zero. About performance, memMap has a comparable performance with google, and hashMap's performance is 100 times better than Google's hashmap. In summary, pwwhash are perfect hash algorithms with zero collision probability. You can refer to following artical to find the key index and compress algorithm theory: http://blog.csdn.net/chixinmuzi/article/details/1727195 Source code and documents: https://sourceforge.net/projects/pwwhashmap/files/?source=navbar |
| asetofsymbols@gmail.com: Jun 03 01:47AM -0700 Il problema é che accentrano troppo il potere... Se ci fate caso i guasti più importanti sono stati creati nella storia da uomini soli al comando in cui il potere gli ha dato alla testa... Volevano il mondo... volevano essere adorati come dei... Direi che sarebbe più sicuro dare potere ai partiti (sempre nel caso che non siano organizzazioni piramidali, con pochi al comando, dove il potere **in pratica** non appartiene all'assemblea che non può decidere anche su proposte politiche e non solo su persone da eleggere) |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment