C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Expanding the definition of constant expressions          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Scott Meyers Guest Posted: Sat Jul 12, 2003 6:32 pm    Post subject: Expanding the definition of constant expressions I have recently started working more with people in the embedded community, and they have a strong interest in putting as much data into ROM as they can. As a general rule, compilers are willing to ROM only constant expressions. On the face of it, this seems reasonable, but consider the following (real) example: int Var1, Var2, Var3; int* const AnotherTabROM[] = { &Var1, &Var2, &Var3 }; class cOptimizedPtrTab { static int* const TabROM[]; }; int* const cOptimizedPtrTab::TabROM[] = { AnotherTabROM[0], AnotherTabROM[1], AnotherTabROM[2] }; The Diab C++ Compiler for PowerPC maps the first array (AnotherTabROM) to ROM and the second array (TabROM) to RAM, even though the contents of the second array are the same as those in the first array. 8.5.1/14 says that TabROM is statically initialized if all the member initializer expressions are constant expressions. 5.19/4 seems to say that TabROM's initializers don't qualify, because the pointers aren't "created explicitly, using the unary & operator, or implicitly using a non-type template parameter of pointer type, or using an expression of array (4.2) or function (4.3) type." And yet it's clear that TabROM can be statically initialized and ROMed. Given the Standard's utter silence on the topic of ROM, one must officially lay the blame at the feet of the compiler vendor, but in view of the tight coupling between constant expressions (as defined by the Standard) and what compiler vendors are generally willing to ROM, it would be nice to know whether there is any chance that the Standard's definition of "constant expression" could be enlarged a bit to handle situations such as this and, ideally, other circumstances where data values can be computed prior to runtime. Is any work being done in this area for C++0x? Thanks, Scott --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top xleobx@qmailcomq.com Guest Posted: Sun Jul 13, 2003 5:37 am    Post subject: Re: Expanding the definition of constant expressions Scott Meyers <Usenet (AT) aristeia (DOT) com> wrote: Quote: I have recently started working more with people in the embedded community, and they have a strong interest in putting as much data into ROM as they can. As a general rule, compilers are willing to ROM only constant expressions. On the face of it, this seems reasonable, but consider the following (real) example: int Var1, Var2, Var3; int* const AnotherTabROM[] = { &Var1, &Var2, &Var3 }; Suppose a compilation unit end here, and in another one you have extern int* const AnotherTabROM[]; Quote: class cOptimizedPtrTab { static int* const TabROM[]; }; int* const cOptimizedPtrTab::TabROM[] = { AnotherTabROM[0], AnotherTabROM[1], AnotherTabROM[2] }; The Diab C++ Compiler for PowerPC maps the first array (AnotherTabROM) to ROM and the second array (TabROM) to RAM, even though the contents of the second array are the same as those in the first array. 8.5.1/14 says that TabROM is statically initialized if all the member initializer expressions are constant expressions. 5.19/4 seems to say that TabROM's initializers don't qualify, because the pointers aren't "created explicitly, using the unary & operator, or implicitly using a non-type template parameter of pointer type, or using an expression of array (4.2) or function (4.3) type." And yet it's clear that TabROM can be statically initialized and ROMed. Given the Standard's utter silence on the topic of ROM, one must officially lay the blame at the feet of the compiler vendor, but in view of the tight coupling between constant expressions (as defined by the Standard) and what compiler vendors are generally willing to ROM, it would be nice to know whether there is any chance that the Standard's definition of "constant expression" could be enlarged a bit to handle situations such as this and, ideally, other circumstances where data values can be computed prior to runtime. Is any work being done in this area for C++0x? The definition of a constant expression cannot be easily enlarged unless the set of operations that the linker can perform is widened. To put TabROM in the const data segment, the linker must handle relocations of a (fantasy) type DEREF_RELOC (compute the value of an expression with relocations and dereference it), and the compiler must be sure of that linker capability. Leo (axe X's and squash Q's) --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Scott Meyers Guest Posted: Mon Jul 14, 2003 5:41 pm    Post subject: Re: Expanding the definition of constant expressions On Sun, 13 Jul 2003 05:37:31 +0000 (UTC), wrote: Quote: The definition of a constant expression cannot be easily enlarged unless the set of operations that the linker can perform is widened. I agree that enlarging it across translation units would require linker support, but what about enlarging it within a single translation unit? Scott --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Leonid Broukhis Guest Posted: Mon Jul 14, 2003 9:55 pm    Post subject: Re: Expanding the definition of constant expressions [email]Usenet (AT) aristeia (DOT) com[/email] (Scott Meyers) wrote in message news:<MPG.197be6ea33ca9cd59896fd (AT) news (DOT) hevanet.com>... Quote: On Sun, 13 Jul 2003 05:37:31 +0000 (UTC), wrote: The definition of a constant expression cannot be easily enlarged unless the set of operations that the linker can perform is widened. I agree that enlarging it across translation units would require linker support, but what about enlarging it within a single translation unit? That can be done, but basing a language standard on restrictions of some N years old linker is dubious at best. Therefore, I'd prefer the standard to enlarge the definition of constant expression across translation units, then the implementors can do the part that does not require linker support right away. Leo --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Ron Natalie Guest Posted: Tue Jul 22, 2003 10:57 pm    Post subject: Re: Expanding the definition of constant expressions "Matthew Towler" <newsgroups (AT) mattnmanda (DOT) co.uk> wrote in message > A related issue is that I tend to find in practice most compilers Quote: reach a point of expression complexity where they give up trying to ROM a value even though it looks constant to the programmer. e.g. const int a = (1 << 25) ; // will get ROMed const int b = (1 << 25) | (1 << 15 ); // also will const int c = (~(((1 << 25) & 0xfffe)) | 37; // probably wont be I don't understand why any of the above are any different. All are constant integer expressions. No compiler that calls itself C++, will have any problem reducing the above to a simple compile time initialization. For it is perfectly valid to do something like: char array[ (~(((1 << 25) & 0xfffe)) | 37 ]; Now for things that the compiler is not required to do at compile time, such as floating point expressions, I could buy that. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] 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, library and standards All times are GMT Page 1 of 1   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.