Nicola Musatti wrote:
>

> Here the conversion of A_HUNDRED to a double representation could be
> performed directly by the compiler, while the convertion of aThousand
> can only be performed at runtime (I realize that these conversions are
> really trivial, but I hope I conveyed the idea).

Of course as you have written it, aThousand isn't a constant expression
anymore.  But instead:

// constants.h
#define A_HUNDRED 100
const int aThousand = 1000;

Nuke constants.cpp, and then in some_file (presuming it #include's constants.h)
will do the same conversion for both d and e.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ron Natalie wrote:
[...]
> > The possible difference is that when using macros the compiler always
> > sees the actual value, so it can perform conversions directly. If you
> > refer to a const its value might not be visible, so conversions will
> > have to take place at runtime.
>
> You've lost me there.  What conversions and what types aren't visible.

I was thinking of something like:

// constants.h

#define A_HUNDRED 100

extern const int aThousand;

// constants.cpp

const int aThousand = 1000;

// some_file.cpp

double d = A_HUNDRED;
double e = aThousand;

Here the conversion of A_HUNDRED to a double representation could be
performed directly by the compiler, while the convertion of aThousand
can only be performed at runtime (I realize that these conversions are
really trivial, but I hope I conveyed the idea).

Cheers,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Al Grant" <tnarga@arm.REVERSE-NAME.com> wrote in message
news:a406ks$dj5$1@cam-news1.cambridge.arm.com...
> "Greg Comeau" <comeau@panix.com> wrote in message
> news:a3plpi$9ub$1@panix3.panix.com...
> > In article <3C604CBB.B8FED8EA@sensor.com>, Ron Natalie  <ron@sensor.com>
> wrote:
> > >Provided 1000000 fits in an int.  Otherwise it might be a long
> >
> > Yup, actually, I think that there is even some more otherwise's
> > there (too tired to look).
>
> Yes, it might be unsigned long.  (But not in C99, where large
> decimal constants can be long long instead.)  Octal and hex have
> a different rule with a wider choice of types.

... and in C++ [2.13.1] it appears that unsigned long is no
longer an option, it's undefined instead.



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Greg Comeau" <comeau@panix.com> wrote in message
news:a3plpi$9ub$1@panix3.panix.com...
> In article <3C604CBB.B8FED8EA@sensor.com>, Ron Natalie  <ron@sensor.com>
wrote:
> >Provided 1000000 fits in an int.  Otherwise it might be a long
>
> Yup, actually, I think that there is even some more otherwise's
> there (too tired to look).

Yes, it might be unsigned long.  (But not in C99, where large
decimal constants can be long long instead.)  Octal and hex have
a different rule with a wider choice of types.



---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Nicola Musatti" <objectway@divalsim.it> wrote in message
news:3C590C76.77B7FFBC@divalsim.it...
> Nothing really; I believe the OP invented a misleading syntax, where
> something like
>
> inline const int   bla = 17;
> inline const char  author[] = "James Kuyper Jr.";
>
> would better convey the underlying intent. As to the actual usefullness
> of this, I have my doubts.

It might be useful to have something compatible with macros
in the sense that the constant's address (when passed to a
function taking reference-to-const, or for a string literal)
was not guaranteed to be unique.  This would allow the
compiler to generate multiple instances of the constant,
if this was better for memory performance.

"inline" is possibly not the right word though.

The other issue that hasn't been mentioned is how to replace
  #define MILLION 1000000
with a const.  What is its type?



---
[ 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.research.att.com/~austern/csc/faq.html                ]

Al Grant wrote:
[...]
> The other issue that hasn't been mentioned is how to replace
>   #define MILLION 1000000
> with a const.  What is its type?

Literals are always typed, introducing them with macros makes no
difference. Your MILLION is an int.

The possible difference is that when using macros the compiler always
sees the actual value, so it can perform conversions directly. If you
refer to a const its value might not be visible, so conversions will
have to take place at runtime.

Cheers,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Nicola Musatti wrote:
>
> Al Grant wrote:
> [...]
> > The other issue that hasn't been mentioned is how to replace
> >   #define MILLION 1000000
> > with a const.  What is its type?
>
> Literals are always typed, introducing them with macros makes no
> difference. Your MILLION is an int.

Provided 1000000 fits in an int.  Otherwise it might be a long
>
> The possible difference is that when using macros the compiler always
> sees the actual value, so it can perform conversions directly. If you
> refer to a const its value might not be visible, so conversions will
> have to take place at runtime.

You've lost me there.  What conversions and what types aren't visible.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C5FA6D8.A3F45E24@divalsim.it>,
Nicola Musatti  <Nicola.Musatti@ObjectWay.it> wrote:
>Al Grant wrote:
>> The other issue that hasn't been mentioned is how to replace
>>   #define MILLION 1000000
>> with a const.  What is its type?
>
>Literals are always typed, introducing them with macros makes no
>difference. Your MILLION is an int.

I say it's not, or at least, doesn't have to be.
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C604CBB.B8FED8EA@sensor.com>, Ron Natalie  <ron@sensor.com> wrote:
>Nicola Musatti wrote:
>> Al Grant wrote:
>> > The other issue that hasn't been mentioned is how to replace
>> >   #define MILLION 1000000
>> > with a const.  What is its type?
>>
>> Literals are always typed, introducing them with macros makes no
>> difference. Your MILLION is an int.
>
>Provided 1000000 fits in an int.  Otherwise it might be a long

Yup, actually, I think that there is even some more otherwise's
there (too tired to look).
--
Greg Comeau  GA BETA:4+ New Windows Backends  PLUS 'export' beta online!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

David R Tribble wrote:
>
> Rudy Velthuis wrote:
> >> So
> >>
> >>    const bla = 17;
> >>    const author = "James Kuyper Jr.";
> >>
> >> would have exactly the same effect as
> >>
> >>    #define bla 17
> >>    #define author "James Kuyper Jr."
>
> Nicola Musatti wrote:
> > ...with the added value of being full-fledge language elements and not
> > just subject to textual substitution.
> >
> > Note however that in the current acception both 17 and "James Kuyper
> > Jr." *are* typed.
>
> So how do they really differ from:
>
>     const int   bla = 17;
>     const char  author[] = "James Kuyper Jr.";
>
> What is to be gained by omitting the explicit type info?

Nothing really; I believe the OP invented a misleading syntax, where
something like

inline const int   bla = 17;
inline const char  author[] = "James Kuyper Jr.";

would better convey the underlying intent. As to the actual usefullness
of this, I have my doubts.

Cheers,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Rudy Velthuis wrote:
>> So
>>
>>    const bla = 17;
>>    const author = "James Kuyper Jr.";
>>
>> would have exactly the same effect as
>>
>>    #define bla 17
>>    #define author "James Kuyper Jr."

Nicola Musatti wrote:
> ...with the added value of being full-fledge language elements and not
> just subject to textual substitution.
>
> Note however that in the current acception both 17 and "James Kuyper
> Jr." *are* typed.

So how do they really differ from:

    const int   bla = 17;
    const char  author[] = "James Kuyper Jr.";

What is to be gained by omitting the explicit type info?

-- David R Tribble, mailto:david@tribble.com --

---
[ 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.research.att.com/~austern/csc/faq.html                ]

David R Tribble <david@tribble.com> wrote:
: Rudy Velthuis wrote:
:>> So
:>>
:>>    const bla = 17;
:>>    const author = "James Kuyper Jr.";

[...]

: So how do they really differ from:

:     const int   bla = 17;
:     const char  author[] = "James Kuyper Jr.";

Not at all.

: What is to be gained by omitting the explicit type info?

Time and effort.

Tom Payne




















---
[ 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.research.att.com/~austern/csc/faq.html                ]

Rudy Velthuis wrote:
[...]
> So
>
>    const bla = 17;
>    const author = "James Kuyper Jr.";
>
> would have exactly the same effect as
>
>    #define bla 17
>    #define author "James Kuyper Jr."

...with the added value of being full-fledge language elements and not
just subject to textual substitution.

Note however that in the current acception both 17 and "James Kuyper
Jr." *are* typed.

Cheers,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Ron Natalie wrote:
>
> Olaf Krzikalla wrote:
> :
> >
> > mydefs.h:
> > inline const std::string empty_string = std::string();
> >
> Hey, that I like.  Inlined variables.

So do I. and if we add a hypothetical explicit type inference mechanism
we might get:

inline auto empty_string = std::string();

Cheers,
Nicola Musatti

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In comp.std.c++ Stephen Clamage <stephen.clamage@sun.com> wrote:
[...]
: On the other hand, what the compiler figures out for itself might not
: be what the programmer intended.

What I type in is often not what I intended.

: Requiring declarations introduces a
: redundancy that documents what the programmer intended, and enables
: the compiler to find conflicts between the programmer's intentions and
: the code actually written.

Maybe programmers should be required to program everything twice in
two different ways, like filling out the amounts on a check.

On the other hand, I've not heard of a lot of complaints about the
optionality of type arguments at calls to template functions.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <iqnf3ukdlhddv7ggp6qlqu86sb0ak2k26e@4ax.com>,
Stephen Clamage  <stephen.clamage@sun.com> wrote:
>On Thu,  3 Jan 2002 22:09:37 GMT, thp@cs.ucr.edu wrote:
>
>>
>>Regarding #2, good type inferencing technology has been available for
>>a very long time, so there is no reason to restrict implicit typing to
>>constants.  It is well known, however, that requiring programmers to
>>provide information that compiler can figure out for itself builds
>>character and keeps the programmer focused -- think of it as an
>>impromptu quiz.
>
>On the other hand, what the compiler figures out for itself might not
>be what the programmer intended. Requiring declarations introduces a
>redundancy that documents what the programmer intended, and enables
>the compiler to find conflicts between the programmer's intentions and
>the code actually written.

True, but the proposed feature is intended to replace uses of #define.
These don't require type declarations.  So the proposed mechanism is no
worse than what it replaces in this regard.  If you require type
declarations on these no-storage constant definitions, programmers who want
to not have to do it will just stick with #define.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Tue,  8 Jan 2002 05:40:53 GMT, Barry Margolin <barmar@genuity.net> wrote:
>  In article <slrna3co8q.gk.news_comp.std.c++_expires-2002-03-01@nightrunner.nmhq.net>,
>  Niklas Matthies <news_comp.std.c++_expires-2002-03-01@nmhq.net> wrote:
> >On Fri,  4 Jan 2002 21:49:43 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
> >>  Greg Comeau wrote:
> >> > Of course, taking the addr doesn't have to mean there is storage
> >> > allocated.
> >>
> >>  What else *could* it mean?
> >
> >It could come about that all uses of the object whose address was taken
> >can be optimized in such a way that no storage needs to be allocated for
> >it.
> >
> >For example, the translation unit
> >
> >   static int foo(int *ip) { return 42 - (*--ip + 23); }
> >
> >   int bar() { int x = 5; return 3 * foo(&x + 1); }
> >
> >is equivalent to
> >
> >   int bar() { return 42; }
> >
> >No storage needed for object 'x' here, in spite of the fact that its
> >address was taken.
>
>  You're talking about an optimizer that performs enough flow analysis that
>  it can optimize away the entire call to foo().

In this particular example, yes. There's nothing unsusual about this.
GCC 3.0 for example produces object code for exactly one function bar()
immediately returning 42 (with -O3).

>  The C virtual machine requires storage to be allocated for x and foo() to
>  be called; it's only the "as if" rule that allows an optimizer to ignore
>  these requirements.

Right, but we aren't talking about the abstract (not virtual) machine.
"const int x = 5;" does also need storage to be allocated in the
abstract machine. In this thread it was noted that this doesn't mean
that actual storage necessarily needs to be allocated (which would have
been the motivation for introducing the proposed "pure" constants),
because of optimizations. Greg Comeau simply noted that this is still
true even if the object's address is being taken.

-- Niklas Matthies
--
Pain is inevitable. Suffering is optional.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Rudy Velthuis wrote:
>
> In article <3C399B9A.F91CF3FE@wizard.net>, James Kuyper Jr. says...
...
> > and execution time. This is quite likely to be the case. Any constant
> > used more than once is likely to take up more space if built into the
> > code at each place where it is used, than it would if retrieved from a
> > single storage space each time.
>
> Unless it is an immediate value, like 13 or 'A'. These can be used
> directly in most CPUs, and take up just as much code as a variable
> access:
>
>   load reg,17
>
> normally takes up as much or less code as
>
>   load reg,[someaddress]

You're correct, I wasn't thinking about small integers; probably because
the example given involved a floating point constant. My apologies.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <m4q_7.19$Mb4.305861@burlma1-snr2>,
Barry Margolin  <barmar@genuity.net> wrote:
>In article <slrna3co8q.gk.news_comp.std.c++_expires-2002-03-01@nightrunner.nmhq.net>,
>Niklas Matthies <news_comp.std.c++_expires-2002-03-01@nmhq.net> wrote:
>>On Fri,  4 Jan 2002 21:49:43 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>>>  Greg Comeau wrote:
>>> > Of course, taking the addr doesn't have to mean there is storage
>>> > allocated.
>>>  What else *could* it mean?
>>...
>>For example, the translation unit
>>
>>   static int foo(int *ip) { return 42 - (*--ip + 23); }
>>
>>   int bar() { int x = 5; return 3 * foo(&x + 1); }
>>
>>is equivalent to
>>
>>   int bar() { return 42; }
>>
>>No storage needed for object 'x' here, in spite of the fact that its
>>address was taken.
>
>You're talking about an optimizer that performs enough flow analysis that
>it can optimize away the entire call to foo().
>
>The C virtual machine requires storage to be allocated for x and foo() to
>be called; it's only the "as if" rule that allows an optimizer to ignore
>these requirements.

Nonetheless, the effect can be the same.  I'll change my original
statement then: Of course, taking the addr doesn't have to mean there
is storage allocated, in the real machine.

Since the OP was referring to how real code would be generated
on a real CPU, I just assumed the context was understood.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

ron@sensor.com (Ron Natalie) wrote (abridged):
> How is the compiler going to "figure it out".

Probably the same way it figures out the type of i in:

    template <typename T>
    void func( T i ) {
    }

    void demo() {
        func( 5 );
    }

In other words, C++ already has some type-inference, albeit in a form
which is not always convenient. There has been much discussion of adding
more, eg with a new keyword like "typeof" and/or reusing an existing one
like "auto".

The notion is orthogonal to optimisation of constants. It'd be nice to be
able to write:

    for (auto i = container.begin(); i != container.end(); ++i)

and have i automatically adapt to whatever type of container we are using.
The most important uses are by template authors.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C35CAA0.527F257F@sensor.com>, Ron Natalie  <ron@sensor.com> wrote:
>Greg Comeau wrote:
>> Of course, taking the addr doesn't have to mean there is
>> storage allocated.
>
>Then what is the value of the resultant expression?

There may not be one (if it too is optimizaed away).
The real machine is allowed to be different than the abstract
machine if (aspect of) the behavior is the same.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

prenom_nomus@yahoo.com (Mark) wrote in message news:<c5b88987.0201030634.66b33b1e@posting.google.com>...
> The motivation for this posting is Dan Saks on-going series in ESP
> magazine about constants in C++ and C. See for example:
>   http://www.embedded.com/story/OEG20011129S0065

  the first segment
  http://www.embedded.com/story/OEG20011016S0116

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In comp.std.c Dave Harris <brangdon@cix.co.uk> wrote:
[...]
: The notion is orthogonal to optimisation of constants. It'd be nice to be
: able to write:

:     for (auto i = container.begin(); i != container.end(); ++i)

: and have i automatically adapt to whatever type of container we are using.
: The most important uses are by template authors.

Exactly!  The compiler already knows the type of container and the
type of container's contents.  So why make programmers write:

 for (container_type<container_member_type>::iterator i=container.begin(); ...

other than to drill them?

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <d1a33011.0201032338.12cfdfa5@posting.google.com>, apm
says...

> That is true for this example because buffer_size happens to be
> mappable onto a fundamental type. For other constants this might not
> be so. For example suppose I wanted to define the imaginary number 'j'
> as a constant. It would be of type complex so the ctor code would have
> to be linked in.

I think the original poster wants const values like in Pascal. Coming
from Pascal myself, I also wondered why one had to use a #define or an
enum for pure constants.

In Pascal, pure constants are only possible for simple types. They have
no immediate type, and will only get a type when assigned to something
that has a type, like a variable or parameter. Since type resolution is
only done on assignment, different types can use the same constant.

They are in fact merely symbolic names for literals like 'A', 13,
3.141592, 0x1234 or "Hello", like simple #defines are. They don't have
to have an explicit type, like most literals don't have to have one.

But even Pascal doesn't guarantee that no storage is used. Of course
string literals must be stored somewhere in the executable, and often
floating point values, or other values (like extra long integers) that
do not fit in a CPU register, too.
--
Rudy Velthuis

"There is no idea so simple and powerful that you can't get zillions
 of people to misunderstand it." -- Alan Kay

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Dave Harris wrote:
>
> ron@sensor.com (Ron Natalie) wrote (abridged):
> > How is the compiler going to "figure it out".
>
> Probably the same way it figures out the type of i in:
>
>     template <typename T>
>     void func( T i ) {
>     }
>
>     void demo() {
>         func( 5 );
>     }
>

This doesn't figure anything out.  5 has type int (via the
rules for numeric literals) and T becomes that type.  5 has
a type.  The argument was that you could get away without
ever having to provide a type, and that I don't agree with.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Rudy Velthuis wrote:
...
> I think the original poster wants const values like in Pascal. Coming
> from Pascal myself, I also wondered why one had to use a #define or an
> enum for pure constants.

Using #define or enum is the C approach. In C++, you just use 'static
const' for pure constants. Any decent implementation will do with
'static const' exactly what is wanted, whenever the implementation
thinks it makes sense. That is to say, it will set aside seperate
storage for the constant, if and only if doing so saves on overall space
and execution time. This is quite likely to be the case. Any constant
used more than once is likely to take up more space if built into the
code at each place where it is used, than it would if retrieved from a
single storage space each time. In fact, there's only a few cases where
a pure constant would take up less space when built into the code, even
if used only once. There's a few special numbers that can be loaded into
some floating point processors with commands that take up less space
than the number itself, but in general that's not an option.

The only reason for proposing a special keyword is a lack of trust in
the implementation. In fact, if the keyword is made enforceable (I have
no idea how this could be done), it could easily end up forcing the use
of the techniques that waste far more code space than the amount of data
space that they save.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <3C399B9A.F91CF3FE@wizard.net>, James Kuyper Jr. says...

I was only explaining why I wondered about this, coming from Pascal.

> That is to say, it will set aside seperate
> storage for the constant, if and only if doing so saves on overall space
> and execution time. This is quite likely to be the case. Any constant
> used more than once is likely to take up more space if built into the
> code at each place where it is used, than it would if retrieved from a
> single storage space each time.

Unless it is an immediate value, like 13 or 'A'. These can be used
directly in most CPUs, and take up just as much code as a variable
access:

  load reg,17

normally takes up as much or less code as

  load reg,[someaddress]

> In fact, there's only a few cases where
> a pure constant would take up less space when built into the code, even
> if used only once.

See above. I disagree. Normally, direct values laod faster and do not
take up more space than variable references. Accessing a const from a
single location normally only makes sense if a reference is smaller than
the value itself.

> There's a few special numbers that can be loaded into
> some floating point processors with commands that take up less space
> than the number itself, but in general that's not an option.

I am thinking of simple values like 17, 1234L, 'A', etc. It makes no
sense to reserve storage for them.

> The only reason for proposing a special keyword is a lack of trust in
> the implementation. In fact, if the keyword is made enforceable (I have
> no idea how this could be done), it could easily end up forcing the use
> of the techniques that waste far more code space than the amount of data
> space that they save.

The OP was not proposing a special keyword. He was simply advocating
typeless consts, as can be found in other languages. Now I'm sure that
C++ compilers are prefectly capable of eliminating storage where
possible, so this request is not very necessary. But I disagree with
you, in that immediate simples values often require less storage, and
are faster. Accessing them from storage requires that you specify the
location each time, which in itself becomes kind of a constantly
repeating value. Why the indirection if you can use the value directly?

IOW: untyped consts would be just symbolic names for literal values. No
more, no less.

So

   const bla = 17;
   const author = "James Kuyper Jr.";

would have exactly the same effect as

   #define bla 17
   #define author "James Kuyper Jr."

Of course storage is required for anything more than simple, native
(native to the language, like int or char, not necessarily native to the
CPU) values. But for these, also Pascal most of the time needs typed
constants.

And like I said, I don't think you can make a portable language enforce
the requirement that storage is not reserved.
--
Rudy Velthuis (TeamB)

"There is no idea so simple and powerful that you can't get zillions
 of people to misunderstand it." -- Alan Kay

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> Type checking integral versus float assignments would still be valid.
> This type of construct can be found in other languages.

The Ada language calls these:
Number Declarations:
 http://www.adahome.com/rm95/rm9x-03-03-02.html

versus
Object Declarations
 http://www.adahome.com/rm95/rm9x-03-03-01.html

No one can accuse Ada of not being type sensitive.

===================================

  I guess I'll stick to #define or depend on compiler specific pragmas.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Fri,  4 Jan 2002 21:49:43 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>  Greg Comeau wrote:
> > Of course, taking the addr doesn't have to mean there is storage
> > allocated.
>
>  What else *could* it mean?

It could come about that all uses of the object whose address was taken
can be optimized in such a way that no storage needs to be allocated for
it.

For example, the translation unit

   static int foo(int *ip) { return 42 - (*--ip + 23); }

   int bar() { int x = 5; return 3 * foo(&x + 1); }

is equivalent to

   int bar() { return 42; }

No storage needed for object 'x' here, in spite of the fact that its
address was taken.

-- Niklas Matthies
--
The future ain't what it used to be...

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Thu,  3 Jan 2002 22:09:37 GMT, thp@cs.ucr.edu wrote:

>
>Regarding #2, good type inferencing technology has been available for
>a very long time, so there is no reason to restrict implicit typing to
>constants.  It is well known, however, that requiring programmers to
>provide information that compiler can figure out for itself builds
>character and keeps the programmer focused -- think of it as an
>impromptu quiz.

On the other hand, what the compiler figures out for itself might not
be what the programmer intended. Requiring declarations introduces a
redundancy that documents what the programmer intended, and enables
the compiler to find conflicts between the programmer's intentions and
the code actually written.

---
Steve Clamage, stephen.clamage@sun.com

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In comp.std.c++ Ron Natalie <ron@sensor.com> wrote:
[...]
: The argument was that you could get away without
: ever having to provide a type, and that I don't agree with.

I understood (part of) the original proposal to be that types be
optional in const declarations that have initializers.  I suggested
that this need not be limited to const declarations.

When the type is omitted, then the default type of the identifier
could be based on that of the initializing expression, plus the
subsequent uses of the declared identifier.  If this default type is
not what the programmer has in mind, it could be overridden via an
explicit type in the standard way.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <%Z7Z7.21971$g24.669365439@newssvr21.news.prodigy.com>,
Carl Daniel <cpdaniel@pacbell.net> wrote:
>
>"Andrew Koenig" <ark@research.att.com> wrote in message
>news:yu99heq3ut1h.fsf@europa.research.att.com...
>> Mark>  Because memory space is usually precious in embedded systems, I
>would
>> Mark> like to see a pure constant construct in the language that would
>> Mark> guarantee no memory is allocated by the compiler.
>>
>> Mark>    example:
>> Mark>       const buffer_size = 256;
>>
>> Suppose the standard did offer such a ``pure constant.''
>> How would you test whether an implementation was supporting
>> the standard's requirements correctly?
>>
>
>By direct examination of the generated machine code?  I understand the point
>though - it's hard (impossible?) to prove that a compiler _doesn't_ do
>something.

In general, programming language standards can only make binding
requirements on implementations that have an effect on the program's output
(on terminals, in files, etc.) and compiler diagnostics.  Anything that
just relates to implementation details, such as memory layout, is difficult
to express in the language standard.  The best it can do is make
suggestions of the form "if the implementation can do X, the following
syntax may be used to request it."

Inline functions and register variables are examples of this.  The standard
describes the expected behavior of them, and also some restrictions that
are placed on the program's use of them that are a corollary of these
expectations, but it can't force an implementation to perform open coding
or really put the variable in a register.  In fact, I believe an
implementation that requires you to put "#pragma inline <functionname>" in
the program to force it to open code the function would still be
conforming.

I don't see why this suggestion couldn't be considered for inclusion in the
same way.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <slrna3co8q.gk.news_comp.std.c++_expires-2002-03-01@nightrunner.nmhq.net>,
Niklas Matthies <news_comp.std.c++_expires-2002-03-01@nmhq.net> wrote:
>On Fri,  4 Jan 2002 21:49:43 GMT, Douglas A. Gwyn <DAGwyn@null.net> wrote:
>>  Greg Comeau wrote:
>> > Of course, taking the addr doesn't have to mean there is storage
>> > allocated.
>>
>>  What else *could* it mean?
>
>It could come about that all uses of the object whose address was taken
>can be optimized in such a way that no storage needs to be allocated for
>it.
>
>For example, the translation unit
>
>   static int foo(int *ip) { return 42 - (*--ip + 23); }
>
>   int bar() { int x = 5; return 3 * foo(&x + 1); }
>
>is equivalent to
>
>   int bar() { return 42; }
>
>No storage needed for object 'x' here, in spite of the fact that its
>address was taken.

You're talking about an optimizer that performs enough flow analysis that
it can optimize away the entire call to foo().

The C virtual machine requires storage to be allocated for x and foo() to
be called; it's only the "as if" rule that allows an optimizer to ignore
these requirements.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

The motivation for this posting is Dan Saks on-going series in ESP
magazine about constants in C++ and C. See for example:
  http://www.embedded.com/story/OEG20011129S0065

 Because memory space is usually precious in embedded systems, I would
like to see a pure constant construct in the language that would
guarantee no memory is allocated by the compiler.

   example:
      const buffer_size = 256;

only the compiler needs to know about "buffer_size" not the linker.
Dan Saks suggests using a enum for this but I feel that enumerated
types were meant to define related entities. Also, enum is not valid
for floating point types such as:

       const pi = 3.14159;

I would like to see this so I can stop using #define macros for
symbolic constants that I don't want to take any precious memory
space. I also don't want to count on a specific compiler
implementation to decide this for me which is the case with

      int const buffer_size = 256;

which may or may not allocate an int for buffer_size.

Type checking integral versus float assignments would still be valid.
This type of construct can be found in other languages.


   Mark


======================================= MODERATOR'S COMMENT:
 Watch crossposts.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

I don't find anything in the article you quote that has any bearing
on the rest of this (other than using variables or enumerators is
better than #define).

>  Because memory space is usually precious in embedded systems, I would
> like to see a pure constant construct in the language that would
> guarantee no memory is allocated by the compiler.
>  only the compiler needs to know about "buffer_size" not the linker.
>    example:
>       const buffer_size = 256;

I bristle at the lack of a type.  While this works well for integers,
it's pretty hard to nail down a specific type (how do you do an unsigned
short with your syntax).  It's also culturally incompatible with the
syntax of both C and C++.

If this proposal has any merit, I'd rather see it as a different storage
class specifier rather than this kludge.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Mark>  Because memory space is usually precious in embedded systems, I would
Mark> like to see a pure constant construct in the language that would
Mark> guarantee no memory is allocated by the compiler.

Mark>    example:
Mark>       const buffer_size = 256;

Suppose the standard did offer such a ``pure constant.''
How would you test whether an implementation was supporting
the standard's requirements correctly?

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Andrew Koenig wrote:
> Suppose the standard did offer such a ``pure constant.''
> How would you test whether an implementation was supporting
> the standard's requirements correctly?

Presumably, if a test program containing the construct worked,
that would be evidence that the implementation at least
understood the syntax (since implicit int is now outlawed).
And something like
 struct s {
  char a;
  const pi = 3.1416;
  char b;
 };
could be tested by offsetof(struct s,pi)==offsetof(struct s,b).

I think your actual point is that there is no reasonable way
to require that storage not be allocated, and I agree with
that, but only because Standard C does not allow 0-sized
objects.  (They could be supported as an extension.)

I agree with Ron that any such facility ought to require a
type specification as well as a value.  Using that syntax,
we already have this in C and C++ for the kinds of usage the
OP seems to have had in mind; whether storage is allocated
wastefully is a matter of quality of implementation.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Mark wrote:
>        const pi = 3.14159;
> I would like to see this so I can stop using #define macros for
> symbolic constants that I don't want to take any precious memory
> space.

Your wish, in itself, is not sufficient to justify changing
anything that others have to use.

> This type of construct can be found in other languages.

Ditto.

There is already functionality for this in C, just not
using the syntax that you seem to prefer.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In comp.std.c Mark <prenom_nomus@yahoo.com> wrote:
: The motivation for this posting is Dan Saks on-going series in ESP
: magazine about constants in C++ and C. See for example:
:   http://www.embedded.com/story/OEG20011129S0065

:  Because memory space is usually precious in embedded systems, I would
: like to see a pure constant construct in the language that would
: guarantee no memory is allocated by the compiler.

:    example:
:       const buffer_size = 256;

: only the compiler needs to know about "buffer_size" not the linker.
: Dan Saks suggests using a enum for this but I feel that enumerated
: types were meant to define related entities. Also, enum is not valid
: for floating point types such as:

:        const pi = 3.14159;

: I would like to see this so I can stop using #define macros for
: symbolic constants that I don't want to take any precious memory
: space. I also don't want to count on a specific compiler
: implementation to decide this for me which is the case with
:
:       int const buffer_size = 256;

: which may or may not allocate an int for buffer_size.

: Type checking integral versus float assignments would still be valid.
: This type of construct can be found in other languages.

You seem to be making two proposals:

  1. That implementations be prohibited from wasting space on
     constants that are known at compile time.

  2. That programmers not be required provide types for constants.

Regarding #1, if you don't take the address of an initialized static
const int variable, it shouldn't be given space in implementations
that do even an elementary amount of optimization.

Regarding #2, good type inferencing technology has been available for
a very long time, so there is no reason to restrict implicit typing to
constants.  It is well known, however, that requiring programmers to
provide information that compiler can figure out for itself builds
character and keeps the programmer focused -- think of it as an
impromptu quiz.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Douglas> Andrew Koenig wrote:
>> Suppose the standard did offer such a ``pure constant.''
>> How would you test whether an implementation was supporting
>> the standard's requirements correctly?

Douglas> Presumably, if a test program containing the construct worked,
Douglas> that would be evidence that the implementation at least
Douglas> understood the syntax (since implicit int is now outlawed).
Douglas> And something like
Douglas>  struct s {
Douglas>   char a;
Douglas>   const pi = 3.1416;
Douglas>   char b;
Douglas>  };

Douglas> could be tested by offsetof(struct s,pi)==offsetof(struct s,b).

You mean you would define offsetof(struct s,pi) even though pi is
supposed to be guaranteed not to occupy memory?

Douglas> I think your actual point is that there is no reasonable way
Douglas> to require that storage not be allocated, and I agree with
Douglas> that, but only because Standard C does not allow 0-sized
Douglas> objects.  (They could be supported as an extension.)

My actual point is that I do not know a way of testing such a
requirement, whether or not 0-sized objects are allowed.

--
Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> Regarding #2, good type inferencing technology has been available for
> a very long time, so there is no reason to restrict implicit typing to
> constants.  It is well known, however, that requiring programmers to
> provide information that compiler can figure out for itself builds
> character and keeps the programmer focused -- think of it as an
> impromptu quiz.

How is the compiler going to "figure it out".  Literals in C and C++
have types via definite rules.  However, they are not all inclusive.
There are types that can't be reached with any combination of the
designation of literals.

C and C++ don't "inference" literals or any other type, they have
definite rules for determining the type of an expression in a given
context.  As I stated before,
 const short i = 5;

is not expressable as a pure numeric literal or via the proposed
new syntax.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Mark wrote:
>
>  Because memory space is usually precious in embedded systems, I would
> like to see a pure constant construct in the language that would
> guarantee no memory is allocated by the compiler. [...]

    So instead of

 load  reg,value
 ...
 value: word 12345

you would prefer to see

 sub  reg,reg
 inc  reg
 add  reg,reg
 inc  reg
 add  reg,reg
 add  reg,reg
 add  reg,reg
 add  reg,reg
 add  reg,reg
 add  reg,reg
 add  reg,reg
 inc  reg
 add  reg,reg
 inc  reg
 add  reg,reg
 inc  reg
 add  reg,reg
 add  reg,reg
 add  reg,reg
 inc  reg

I suppose there may exist processors for which the latter uses
less memory than the former.  In three-plus decades I haven't
encountered any such processor, but there are more things in
Heaven and Earth than are dreamt of in my philosophy ...

--
Eric.Sosman@sun.com

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <c5b88987.0201030634.66b33b1e@posting.google.com>,
Mark <prenom_nomus@yahoo.com> wrote:
> Because memory space is usually precious in embedded systems, I would
>like to see a pure constant construct in the language that would
>guarantee no memory is allocated by the compiler.

Since the need for this is very environment-specific, and such systems may
already require special compiler options or #pragma's, I think it would be
better to leave this out of the standard.

However, I was thinking that if the standard were to provide a way to
request this, a possible notation might be:

const register int a = 123;

Since these constants don't have storage assigned to them, taking their
address would presumably be prohibited, and that's already the case with
the register storage class.  With this, even a compiler that doesn't
optimize away the storage could still be required to produce a diagnostic
if you attempt to take the address of the constant, so it would be easier
to check out the program with an ordinary compiler prior to compiling for
the embedded environment.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <c5b88987.0201030634.66b33b1e@posting.google.com>,
Mark <prenom_nomus@yahoo.com> wrote:
> Because memory space is usually precious in embedded systems, I would
>like to see a pure constant construct in the language that would
>guarantee no memory is allocated by the compiler.
>
>   example:
>      const buffer_size = 256;
>
>only the compiler needs to know about "buffer_size" not the linker.

C++ already allows this to occur, although it does not require it
(though it does not use that syntax, assuming you're suggesting
a syntax here, and that the above isn't instead a typo).
I realize that you are seeking some sort of limited code footprint,
however, I'm not clear how requiring the above guarantees that
will be the end result.

>Dan Saks suggests using a enum for this but I feel that enumerated
>types were meant to define related entities. Also, enum is not valid
>for floating point types such as:
>
>       const pi = 3.14159;

Well, for integral consts, they are allowed to be used a
constants in a number of contexts, so the enum is not always
necessary.

>I would like to see this so I can stop using #define macros for
>symbolic constants that I don't want to take any precious memory
>space. I also don't want to count on a specific compiler
>implementation to decide this for me which is the case with
>
>      int const buffer_size = 256;
>
>which may or may not allocate an int for buffer_size.

True, but as above, I'm not convinced your proposal also
still does not put you at the mercy of the compiler vendor.
So in the end, this boils down to a qualify of implementation issue.

>Type checking integral versus float assignments would still be valid.
>This type of construct can be found in other languages.

With the guarantee?   Then I don't understand.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <Er7Z7.3$Tr2.21531@burlma1-snr2>,
Barry Margolin  <barmar@genuity.net> wrote:
>However, I was thinking that if the standard were to provide a way to
>request this, a possible notation might be:
>
>const register int a = 123;
>
>Since these constants don't have storage assigned to them, taking their
>address would presumably be prohibited, and that's already the case with
>the register storage class.

In C, not in C++.

>With this, even a compiler that doesn't
>optimize away the storage could still be required to produce a diagnostic
>if you attempt to take the address of the constant, so it would be easier
>to check out the program with an ordinary compiler prior to compiling for
>the embedded environment.

Of course, taking the addr doesn't have to mean there is
storage allocated.
--
Greg Comeau   What's next: additional Windows backends and 'export'!
Comeau C/C++ ONLINE ==>     http://www.comeaucomputing.com/tryitout
World Class Compilers:  Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

prenom_nomus@yahoo.com (Mark) wrote in message news:<c5b88987.0201030634.66b33b1e@posting.google.com>...
> The motivation for this posting is Dan Saks on-going series in ESP
> magazine about constants in C++ and C. See for example:
>   http://www.embedded.com/story/OEG20011129S0065
>
>  Because memory space is usually precious in embedded systems, I would
> like to see a pure constant construct in the language that would
> guarantee no memory is allocated by the compiler.
>
>    example:
>       const buffer_size = 256;
>
> only the compiler needs to know about "buffer_size" not the linker.

That is true for this example because buffer_size happens to be
mappable onto a fundamental type. For other constants this might not
be so. For example suppose I wanted to define the imaginary number 'j'
as a constant. It would be of type complex so the ctor code would have
to be linked in.

Regards,

Andrew M.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Thu,  3 Jan 2002 19:15:32 GMT Mark wrote:
> Because memory space is usually precious in embedded systems, I would
>like to see a pure constant construct in the language that would
>guarantee no memory is allocated by the compiler.
>
>   example:
>      const buffer_size = 256;
>
>only the compiler needs to know about "buffer_size" not the linker.
>Dan Saks suggests using a enum for this but I feel that enumerated
>types were meant to define related entities. Also, enum is not valid
>for floating point types such as:
>
>       const pi = 3.14159;
>
>I would like to see this so I can stop using #define macros for
>symbolic constants that I don't want to take any precious memory
>space. I also don't want to count on a specific compiler

Even if you are using #define or direct literal immediately in your
expression, you can't have the guarantee about not allocating any space
for constants (literal or not) by the compiler. Any compiler could put
any literal into it's own storage, even in expression like

a=2+2;

It's merely code generation issue.

Furthermore, if you eliminate putting constants into their storage, then
compiler must spend some bytes in code itself in program text section.

--
jk

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Hi,

how about using inline for this purpose.
Example:

mydefs.h:
inline const std::string empty_string = std::string();

instead of:

mydefs.h:
extern const std::string empty_string;  //with a definition somewhere in
.cpp


In the latter case the compiler is quite always forced to allocate
storage for empty_string, while the inline version often enough easily
could get optimized, when used.
Non-extern integral constants should be inlined implicitly (as today).


Best regards
Olaf Krzikalla

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Eugene Karpachov wrote:
> ... Any compiler could put any literal into it's own storage, ...

Most ISAs actually require that.
I think the OP had in mind avoiding the *unnecessary*
allocation of storage; as many have remarked, that's
currently a quality of implementation issue, and it
doesn't seem to be a major problem in practice.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

In comp.std.c Ron Natalie <ron@sensor.com> wrote:

:> Regarding #2, good type inferencing technology has been available for
:> a very long time, so there is no reason to restrict implicit typing to
:> constants.  It is well known, however, that requiring programmers to
:> provide information that compiler can figure out for itself builds
:> character and keeps the programmer focused -- think of it as an
:> impromptu quiz.

: How is the compiler going to "figure it out".

There is a section on type inference in the Dragon Book (i.e., the compiler
book by Aho, Sethi, and Ullman).  I don't recall all of the techniques but
I remember mention of the unification algorithm.  I've heard of more recent
work in a talk by Jens Palsburg about translating Smalltalk programs into
Java.

: Literals in C and C++ have types via definite rules.  However, they are
: not all inclusive.  There are types that can't be reached with any
: combination of the designation of literals.

At least not via those rules.  As I recall, type-inferencing systems
look at the uses of a variable and try to find the most economical
type that they can get by with.

: C and C++ don't "inference" literals or any other type, they have
: definite rules for determining the type of an expression in a given
: context.

I understand that the proposal is to change that in certain cases.

: As I stated before,

:  const short i = 5;

: is not expressable as a pure numeric literal or via the proposed
: new syntax.

As I understand the proposal, it doesn't eliminate the option of
explicit typing of constants.

Tom Payne

---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Thu,  3 Jan 2002 23:32:25 GMT, Ron Natalie <ron@sensor.com> wrote:
>
> > Regarding #2, good type inferencing technology has been available for
> > a very long time, so there is no reason to restrict implicit typing to
> > constants.  It is well known, however, that requiring programmers to
> > provide information that compiler can figure out for itself builds
> > character and keeps the programmer focused -- think of it as an
> > impromptu quiz.
>
>  How is the compiler going to "figure it out".  Literals in C and C++
>  have types via definite rules.  However, they are not all inclusive.
>  There are types that can't be reached with any combination of the
>  designation of literals.

This is easily solved by allowing constant expressions instead of mere
plain literals.

>   const short i = 5;

const i = (short) 5;

(Of course, this doesn't actually save any typing. :))

-- Niklas Matthies
--
Money can't buy happiness, but it can make you awfully comfortable while
you're being miserable.   -- C.B. Luce

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> Of course, taking the addr doesn't have to mean there is
> storage allocated.

Then what is the value of the resultant expression?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Andrew Koenig" <ark@research.att.com> wrote in message
news:yu99heq3ut1h.fsf@europa.research.att.com...
> Mark>  Because memory space is usually precious in embedded systems, I
would
> Mark> like to see a pure constant construct in the language that would
> Mark> guarantee no memory is allocated by the compiler.
>
> Mark>    example:
> Mark>       const buffer_size = 256;
>
> Suppose the standard did offer such a ``pure constant.''
> How would you test whether an implementation was supporting
> the standard's requirements correctly?
>

By direct examination of the generated machine code?  I understand the point
though - it's hard (impossible?) to prove that a compiler _doesn't_ do
something.

-cd


---
[ 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.research.att.com/~austern/csc/faq.html                ]

In article <c5b88987.0201030634.66b33b1e@posting.google.com>,
prenom_nomus@yahoo.com (Mark) wrote:
> Because memory space is usually precious in embedded systems, I would
>like to see a pure constant construct in the language that would
>guarantee no memory is allocated by the compiler.
>
>   example:
>      const buffer_size = 256;
>
>only the compiler needs to know about "buffer_size" not the linker.

Well, one can inline functions, so why not adding that for "const"
constants as well:

There is still no guarantee for inlining, but compilers would be able do
that whenever possible.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Barry Margolin wrote:

> Since the need for this is very environment-specific, and such systems may
> already require special compiler options or #pragma's, I think it would be
> better to leave this out of the standard.
>
Or, as has been suggested from time to time, some standard pragmas
(which some jokingly have referred to as #dogmas).  Of course, I'd
first just wish C++'s preprocessor was required to support Pragmas
as operators.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Greg Comeau wrote:
> Of course, taking the addr doesn't have to mean there is
> storage allocated.

What else *could* it mean?

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Olaf Krzikalla wrote:
:
>
> mydefs.h:
> inline const std::string empty_string = std::string();
>
Hey, that I like.  Inlined variables.

---
[ 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.research.att.com/~austern/csc/faq.html                ]