C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  preprocessor hack Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message anton muhin Guest Posted: Thu Feb 19, 2004 10:33 am    Post subject: preprocessor hack Dear gurus! I need to do the following preprocessor trick in the most conformant way. I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete However, I need to be able to use old new. E.g. there is another macro: #define CREATE(<params>) <blah> new <blah> and some code: CREATE(...) When I get this source code preprocesed, it looks like: <blah> SOMETHING, new <blah> but I need it to be <blah> new <blah> without SOMETHING. Is there a way? tia, anton. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alp Oezmert Guest Posted: Fri Feb 20, 2004 11:25 am    Post subject: Re: preprocessor hack Quote: Dear gurus! hell, I'm none! :) Quote: I need to do the following preprocessor trick in the most conformant way. I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete -------- I think the preprocessor just ignores everything after the coma, thus #define'ing new as 'SOMETHING,' Quote: However, I need to be able to use old new. E.g. there is another macro: #define CREATE(<params>) <blah> new <blah and some code: CREATE(...) When I get this source code preprocesed, it looks like: It should be changed into , bacause new is SOMETHING, Quote: blah> SOMETHING, new <blah but I need it to be blah> new without SOMETHING. Is there a way? Spaces are not nice things, especially if they are within your identifiers. use new_SOMETHING :) Quote: tia, C ya! Quote: anton. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Feb 20, 2004 1:16 pm    Post subject: Re: preprocessor hack In message <c1005m$1bs7ri$1 (AT) ID-217427 (DOT) news.uni-berlin.de>, anton muhin <antonmuhin (AT) rambler (DOT) ru> writes Quote: Dear gurus! I need to do the following preprocessor trick in the most conformant way. I don't think you can as you are playing with keywords. But why do you need to do so? Quote: I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete You mean you 'need' to replace 'new' with SOMETHING, new? Seems bizarre to me. Quote: However, I need to be able to use old new. E.g. there is another macro: #define CREATE(<params>) <blah> new <blah and some code: CREATE(...) When I get this source code preprocesed, it looks like: blah> SOMETHING, new <blah but I need it to be blah> new without SOMETHING. Is there a way? Even if there were, I would still question doing it. Considering that the pre-processor has no understanding of scope I would think the above would be a recipe for fragile code, difficult to maintain and probably bug ridden. I think you would be much better off telling us what problem you are trying to solve. I.e. I think you are asking the wrong question. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jonathan Turkanis Guest Posted: Fri Feb 20, 2004 1:44 pm    Post subject: Re: preprocessor hack "anton muhin" <antonmuhin (AT) rambler (DOT) ru> wrote Quote: Dear gurus! I need to do the following preprocessor trick in the most conformant way. I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete Sounds horrible! Why? Are you familiar with 17.4.3.1.1 (refering to standard headers): "A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords" ? Jonathan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Feb 20, 2004 8:54 pm    Post subject: Re: preprocessor hack In message <c124ht$i8h$1 (AT) nets3 (DOT) rz.RWTH-Aachen.DE>, Alp Oezmert <polarma (AT) gmx (DOT) net> writes Quote: Dear gurus! hell, I'm none! :) I need to do the following preprocessor trick in the most conformant way. I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete -------- I think the preprocessor just ignores everything after the coma, thus #define'ing new as 'SOMETHING,' No, the critical punctuation for a #define is the first whitespace which delimits what is being replaced, everything after that first whitespace becomes what is substituted. As the rest of your post is contingent on this misconception it is irrelevant to the problem. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top anton muhin Guest Posted: Sat Feb 21, 2004 4:18 am    Post subject: Re: preprocessor hack Francis Glassborow wrote: Quote: In message <c1005m$1bs7ri$1 (AT) ID-217427 (DOT) news.uni-berlin.de>, anton muhin [email]antonmuhin (AT) rambler (DOT) ru[/email]> writes Dear gurus! I need to do the following preprocessor trick in the most conformant way. I don't think you can as you are playing with keywords. But why do you need to do so? I needed it to change new & delete operators behaviour a little bit. Yes, I do understand that it's ugly, bad, etc... and, hopefully, I found another way that is, again hopefully, much better. Actually, I'm trying to implement memory management system with pools and I've found that it can be a real headache. Placement forms of new a good, but not that perfect to handle placed allocation of arrays (due to overhead they may impose). Absence of placed delete leads to templates that might be not acceptable due to code bloat (we need to squeeze or application into 8M including a heap). If anybody has refernces to nice implemetations of pool memory management with C++, I would really appreciate them. Thank you all for your time, regards, anton. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Mon Feb 23, 2004 6:55 pm    Post subject: Re: preprocessor hack Hi, Quote: Actually, I'm trying to implement memory management system with pools and I've found that it can be a real headache. Placement forms of new a good, but not that perfect to handle placed allocation of arrays (due to overhead they may impose). Why? The placement argument of new is a perfect "place" (uhm) to put the pool argument. What's the overhead you're refering to? Quote: Absence of placed delete leads to templates that might be not acceptable due to code bloat (we need to squeeze or application into 8M including a heap). No, why? On allocation, reserve size_t + sizeof(Pool *) bytes, store the pointer to the pool in the first byte, then return the rest. Also overload operator delete, get the pool from ((Pool *)object)[-1] and release the memory to the pool. No templates. This stores the pool along with the object, making mixture of pools pretty safe. You even don't have to overload the global operator new for it. Instead, it is sufficient to have a base class that does, and derive all objects you want to take from the pool from this base. Of course, you should offer an overloaded operator new[] and delete[] along with it, and the placement syntax for operator delete in case something goes wrong in a constructor of the object. So long, Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top anton muhin Guest Posted: Tue Feb 24, 2004 1:48 pm    Post subject: Re: preprocessor hack Thomas Richter wrote: Quote: Hi, Actually, I'm trying to implement memory management system with pools and I've found that it can be a real headache. Placement forms of new a good, but not that perfect to handle placed allocation of arrays (due to overhead they may impose). Why? The placement argument of new is a perfect "place" (uhm) to put the pool argument. What's the overhead you're refering to? I might be wrong but according to Standard new (pointer) Foo[N] can call operator new [] with size = sizeof(Foo)*N + x, where x is some non-negative constant. This constant can depend on type (e.g., vc6.0). Quote: Absence of placed delete leads to templates that might be not acceptable due to code bloat (we need to squeeze or application into 8M including a heap). No, why? On allocation, reserve size_t + sizeof(Pool *) bytes, store the pointer to the pool in the first byte, then return the rest. Also overload operator delete, get the pool from ((Pool *)object)[-1] and release the memory to the pool. No templates. This stores the pool along with the object, making mixture of pools pretty safe. You even don't have to overload the global operator new for it. Instead, it is sufficient to have a base class that does, and derive all objects you want to take from the pool from this base. Of course, you should offer an overloaded operator new[] and delete[] along with it, and the placement syntax for operator delete in case something goes wrong in a constructor of the object. Here comes the problem --- storing pool pointer could lead to overhead I cannot tolerate: there are too many small objects and I'm quite limited with memory. The idea with base class that defines allocation policy isn't quite suitable for my problem as well --- I have to implement memory managemenet with minial modificaion of sources. with best regards, anton. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Tue Feb 24, 2004 7:20 pm    Post subject: Re: preprocessor hack Thomas Richter <thor (AT) cleopatra (DOT) math.tu-berlin.de> wrote Quote: Actually, I'm trying to implement memory management system with pools and I've found that it can be a real headache. Placement forms of new a good, but not that perfect to handle placed allocation of arrays (due to overhead they may impose). Why? The placement argument of new is a perfect "place" (uhm) to put the pool argument. What's the overhead you're refering to? Absence of placed delete leads to templates that might be not acceptable due to code bloat (we need to squeeze or application into 8M including a heap). No, why? On allocation, reserve size_t + sizeof(Pool *) bytes, store the pointer to the pool in the first byte, then return the rest. And don't forget alignment issues. On my machine, if I write something like: void* operator new( size_t n, Pool* pool ) { Pool* result = static_cast< Pool* >( pool->alloc( n + sizeof( Pool* ) ) ) ; if ( result == NULL ) { throw std::bad_alloc() ; } *result = pool ; return result + 1 ; } I'll probably get quite a number of bus errors. If (and only if) the actual allocated type contains doubles, of course. Regretfully, I know of no portable solution for the alignment issues. For the moment, I use a union of a fair variety of basic types and pointers, with the hope that it covers all possible alignment issues. In practice, I think it is pretty portable, but formally, there is no real guarantee. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Graeme Prentice Guest Posted: Wed Feb 25, 2004 2:55 pm    Post subject: Re: preprocessor hack On 20 Feb 2004 23:18:18 -0500, anton muhin wrote: Quote: If anybody has refernces to nice implemetations of pool memory management with C++, I would really appreciate them. Loki and boost are held in high regard http://www.boost.org/libs/pool/doc/ http://sourceforge.net/projects/loki-lib/ Loki has versions for both VC6 and 7. It provides a fast allocator for small objects. You might need Andrei Alexandrescu's book to understand it. "Modern C++ Design" ISBN 0201704315 http://www.dinkumware.com/libDCorX.html Dinkumware library has a selection of allocators. You could explain what you need to them and see what they recommend. You'll find plenty of links such as this http://www.mathtools.net/C++/Memory_management/ by searching here http://groups.google.com/advanced_group_search Templates won't necessarily cause you code bloat so perhaps don't reject Loki and Boost for that. You might get some ideas from them anyway. Graeme [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Dylan Nicholson Guest Posted: Wed Feb 25, 2004 3:09 pm    Post subject: Re: preprocessor hack "Jonathan Turkanis" <technews (AT) kangaroologic (DOT) com> wrote Quote: "anton muhin" <antonmuhin (AT) rambler (DOT) ru> wrote in message news:c1005m$1bs7ri$1 (AT) ID-217427 (DOT) news.uni-berlin.de... Dear gurus! I need to do the following preprocessor trick in the most conformant way. I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete Sounds horrible! Why? Are you familiar with 17.4.3.1.1 (refering to standard headers): "A translation unit that includes a header shall not contain any macros that define names declared or defined in that header. Nor shall such a translation unit define macros for names lexically identical to keywords" Well I'm not sure what the OP is trying to do, but I don't know how to pass file/line # information to debug-enabled heap allocators without #defining new. It's a common-enough technique: void* operator new(size_t size, const char* file, int line); #define new new(__FILE__, __LINE__) And extremely useful for tracking down memory-leaks (including one in a particular implementation of std::deque<> that I would probably have never found otherwise). Dylan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Wed Feb 25, 2004 3:16 pm    Post subject: Re: preprocessor hack Hi, Quote: Actually, I'm trying to implement memory management system with pools and I've found that it can be a real headache. Placement forms of new a good, but not that perfect to handle placed allocation of arrays (due to overhead they may impose). Why? The placement argument of new is a perfect "place" (uhm) to put the pool argument. What's the overhead you're refering to? I might be wrong but according to Standard new (pointer) Foo[N] can call operator new [] with size = sizeof(Foo)*N + x, where x is some non-negative constant. This constant can depend on type (e.g., vc6.0). Yes, but? Sorry, but I still don't see your problem. You get the proper size passed in to your operator new, so what's the trouble? Quote: No, why? On allocation, reserve size_t + sizeof(Pool *) bytes, store the pointer to the pool in the first byte, then return the rest. Also overload operator delete, get the pool from ((Pool *)object)[-1] and release the memory to the pool. No templates. This stores the pool along with the object, making mixture of pools pretty safe. You even don't have to overload the global operator new for it. Instead, it is sufficient to have a base class that does, and derive all objects you want to take from the pool from this base. Of course, you should offer an overloaded operator new[] and delete[] along with it, and the placement syntax for operator delete in case something goes wrong in a constructor of the object. Here comes the problem --- storing pool pointer could lead to overhead I cannot tolerate: there are too many small objects and I'm quite limited with memory. The idea with base class that defines allocation policy isn't quite suitable for my problem as well --- I have to implement memory managemenet with minial modificaion of sources. In that case, I would suggest to use a "factory" approach of a base class that buffers a pool of your tiny objects and returns objects from that pool. If you allocate a lot of them, using heap allocation for each single object might also cause a noticable overhead, so you can only get better. (-; So long, Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Thomas Richter Guest Posted: Wed Feb 25, 2004 3:17 pm    Post subject: Re: preprocessor hack Hi James, Quote: And don't forget alignment issues. On my machine, if I write something like: void* operator new( size_t n, Pool* pool ) { Pool* result = static_cast< Pool* >( pool->alloc( n + sizeof( Pool* ) ) ) ; if ( result == NULL ) { throw std::bad_alloc() ; } *result = pool ; return result + 1 ; } I'll probably get quite a number of bus errors. If (and only if) the actual allocated type contains doubles, of course. Regretfully, I know of no portable solution for the alignment issues. For the moment, I use a union of a fair variety of basic types and pointers, with the hope that it covers all possible alignment issues. In practice, I think it is pretty portable, but formally, there is no real guarantee. Yes, thanks for the hint. This seems to be a real problem, in fact. Since I've come across this "memory pool" issue now more than once, I come to believe that the C++ language lacks some support for this design pattern. Would this be an issue for an enhancement request for future C++ developments? Enhancements could be a) some portable way to define alignment and/or b) some "memory pool" version of "operator new" and friends. The current "standard solution" still looks rather like a hack to me. So long, Thomas [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jonathan Turkanis Guest Posted: Thu Feb 26, 2004 12:07 am    Post subject: Re: preprocessor hack "Dylan Nicholson" <wizofaus (AT) hotmail (DOT) com> wrote Quote: "Jonathan Turkanis" <technews (AT) kangaroologic (DOT) com> wrote "anton muhin" <antonmuhin (AT) rambler (DOT) ru> wrote in message I have to define macros new and delete like this: #define new SOMETHING, new #define delete SOMETHIG, delete Sounds horrible! Why? Are you familiar with 17.4.3.1.1 (refering to standard headers): <snip> Quote: Well I'm not sure what the OP is trying to do, but I don't know how to pass file/line # information to debug-enabled heap allocators without #defining new. It's a common-enough technique: void* operator new(size_t size, const char* file, int line); #define new new(__FILE__, __LINE__) And extremely useful for tracking down memory-leaks (including one in a particular implementation of std::deque<> that I would probably have never found otherwise). My expression of horror was not entiery response to the idea of defining new; the OP wanted to define new to be a partial expression involving the comma operator. It also turned out in a later post he was trying to solve a design problem. Defining #define new new(__FILE__, __LINE__) seems much less likely to lead to disaster, and okay for debugging. (But still usually undefined behavior.) Jonathan [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top News Subsystem Guest Posted: Fri Feb 27, 2004 2:15 am    Post subject: Re: preprocessor hack Quote: Defining #define new new(__FILE__, __LINE__) seems much less likely to lead to disaster, and okay for debugging. (But still usually undefined behavior.) But still causes problems when using placement new as it expands to new(__FILE__, __LINE__)(ptr) T; which is invalid. In the past I've either had to unsure that the define is undef'd before using a placement new and redefine after or use replacement functions / macros for new / placement new. Is there a common way around this problem? Cheers Martin [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.