francis.glassborow@ntlworld.com (Francis Glassborow) wrote in message news:<RVolDUAqMJL+EwK0@robinton.demon.co.uk>...
> In article <23478c42.0301201104.4a7d96e6@posting.google.com>,
> "danielgutson@hotmail.com" <danielgutson@hotmail.com> writes
> >Al, I'm not sure I understood your last statement:
> > I agree that "abc" == "abc" will (always?) return false;
>
> He deliberately did not say that because it is not true. "abc" == "abc"
> is free to return either true or false (the result is unspecified)

As categorical as truth. Sorry.
Same 'unspecificity' still hold in
  inline const int x = 1;
  bool r = ( &x == &x );

Keeping this line: what do you think about the usability of 'inline references'?
  int z;
  inline const int& refA = z;
  inline const int& refB = 1;

I think they should not be allowed.

 Daniel.

---
[ 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                       ]

algrant@myrealbox.com (Al Grant) wrote in message news:<5765b025.0301170110.251676e4@posting.google.com>...
> It means that when you bind a const reference parameter to the
> constant the compiler is free to construct and use any object with
> that value (as for literals, enum constants etc.)

I may be wrong there; given

  bool sameaddr(int const &a, int const &b) { return &a == &b; }

is it required that sameaddr(2,2) return false, i.e. that two
different temporaries must be used?  Even more efficient would be
a way of designating a constant such that there was no uniqueness
guarantee either way, in the same way that we cannot say whether
or not "abc" == "abc".

(This is not relevant to the need to have constants that behave
identically to literals, though.)

---
[ 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                       ]

algrant@myrealbox.com (Al Grant) wrote in message news:<5765b025.0301200043.28309aae@posting.google.com>...
> algrant@myrealbox.com (Al Grant) wrote in message news:<5765b025.0301170110.251676e4@posting.google.com>...
> > It means that when you bind a const reference parameter to the
> > constant the compiler is free to construct and use any object with
> > that value (as for literals, enum constants etc.)
>
> I may be wrong there; given
>
>   bool sameaddr(int const &a, int const &b) { return &a == &b; }
>
> is it required that sameaddr(2,2) return false, i.e. that two
> different temporaries must be used?  Even more efficient would be
> a way of designating a constant such that there was no uniqueness
> guarantee either way, in the same way that we cannot say whether
> or not "abc" == "abc".

Al, I'm not sure I understood your last statement:
 I agree that "abc" == "abc" will (always?) return false; however, I
think that the compiler should be free to optimize the 'reuse' of the
[inline] constant within the same context, and should throw a warning
whenever the address is obtained (in the same sense of the 'returning
local address' warning when you return the address of a local variable
being destroyed after the return).
Did I understood you correctly?

 Daniel.

---
[ 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                       ]

In article <23478c42.0301201104.4a7d96e6@posting.google.com>,
"danielgutson@hotmail.com" <danielgutson@hotmail.com> writes
>Al, I'm not sure I understood your last statement:
> I agree that "abc" == "abc" will (always?) return false;

He deliberately did not say that because it is not true. "abc" == "abc"
is free to return either true or false (the result is unspecified)


--
ACCU Spring Conference 2003 April 2-5
The Conference you cannot afford to miss
Check the details: http://www.accuconference.co.uk/
Francis Glassborow      ACCU

---
[ 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                       ]

Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0301160559.162602ba@posting.google.com>...
> danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301130807.4e1fcf88@posting.google.com>...
> > 1) 'inline' constants: (don't know if 'inline' is the happiest term).
> > Constants may or not be allocated; the idea is differentiate
> > 'allocated constants' from enum-like constants (in the sence that they
> > are just values temporary allocated).
>
> WHat problem does this solve ?

It means that when you bind a const reference parameter to the
constant the compiler is free to construct and use any object with
that value (as for literals, enum constants etc.) rather than having
to ensure that it always binds to the same globally unique object.
This is potentially more efficient.  Macros could then be replaced
by (inline) constants with guaranteed zero impact on the program,
which is not the case at present.

---
[ 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                       ]

Al Grant <algrant@myrealbox.com> wrote:
+ Michiel.Salters@cmg.nl (Michiel Salters) wrote in message news:<cefd6cde.0301160559.162602ba@posting.google.com>...
+> danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301130807.4e1fcf88@posting.google.com>...
+> > 1) 'inline' constants: (don't know if 'inline' is the happiest term).
+> > Constants may or not be allocated; the idea is differentiate
+> > 'allocated constants' from enum-like constants (in the sence that they
+> > are just values temporary allocated).
+>
+> WHat problem does this solve ?
+
+ It means that when you bind a const reference parameter to the
+ constant the compiler is free to construct and use any object with
+ that value (as for literals, enum constants etc.) rather than having
+ to ensure that it always binds to the same globally unique object.
+ This is potentially more efficient.  Macros could then be replaced
+ by (inline) constants with guaranteed zero impact on the program,
+ which is not the case at present.

I agree. and would like to elaborate a bit.  There are constant
lvalues:

      float pi = 3.14159;

and rvalue constants:

      3.14159                      // literal rvalue constant

   or

      enum{ daysPerWeek = 7; }     // symbolic rvalue constant

But the enum idiom only works for ints and (IMHO) is an ugly hack.

Of course, we can use the preprocessor to give names to literals

      #define  PI 3.14159

but those names do not have the benefit of the scope and namespace
features of C++.

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.jamesd.demon.co.uk/csc/faq.html                       ]

danielgutson@hotmail.com (danielgutson@hotmail.com) wrote in message news:<23478c42.0301130807.4e1fcf88@posting.google.com>...
> newsgroup people:
>  I'd like to ask for feedbacks about two things:
>
> 1) 'inline' constants: (don't know if 'inline' is the happiest term).
> Constants may or not be allocated; the idea is differentiate
> 'allocated constants' from enum-like constants (in the sence that they
> are just values temporary allocated).

WHat problem does this solve ?

> 2) size/sign modifiers as template parameters.
> What I'm proposing is the ability to receive size and/or sign
> modifiers as template parameters:
>
>    template <sign_mod SIGN_MOD, size_mod> MyInt;
>
> so the following could be done:
>     MyInt<unsigned, long> X;

You can already do this:
template< typename T1, typename T2>
class int_traits;
template< >
class int_traits< signed, long> { typedef signed long int Type };
class int_traits< unsigned, long> { typedef unsigned long int Type };
class int_traits< signed, short> { typedef signed short int Type };
class int_traits< unsigned, short> { typedef unsigned short int Type };

so your template becomes

template <typename sign_mod, typename size_mod>
class MyInt {
  int_traits< sign_mod, size_mod>::Type data; // some kind of int
  // other operations go here
};

or

template <typename sign_mod, typename size_mod>
class MyFloat {
  int_traits< sign_mod, size_mod>::Type mantissa;
  int_traits< signed, size_mod>::Type exponent;
  // other operations go here
};


The reason this works is because 'unsigned' etcetera by itself already
are types in C++, so they can be template parameters.

Regards,
--
Michiel Salters

---
[ 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                       ]

newsgroup people:
 I'd like to ask for feedbacks about two things:

1) 'inline' constants: (don't know if 'inline' is the happiest term).
Constants may or not be allocated; the idea is differentiate
'allocated constants' from enum-like constants (in the sence that they
are just values temporary allocated).
The proposed idea is using the 'inline' keyword as in the following
examples:

   const float PI = 3.1415927;
VERSUS
   inline const float E = 2.718281;

In the first case, one can request &PI and will obtain always the same
value;
in the second (inline) case, E would be allocated each time is
referenced (so there's no warranty that &E is always the same).
The idea of the inline constants is that their definition DOES NOT
occupy space, in the same sense an enum doesn't. In the ultimate case,
one could compare an 'inline constant' with the legendary '#define'
for constant declarations.
(I'm not sure 'inline' is a good keyword for differentiating this).

2) size/sign modifiers as template parameters.
What I'm proposing is the ability to receive size and/or sign
modifiers as template parameters:

   template <sign_mod SIGN_MOD, size_mod> MyInt;

so the following could be done:
    MyInt<unsigned, long> X;

and, additionally, as a notation rule, if a modifier appears only in
one parameter (as the example), then it can be prefixed; the above
example would be similar to
    unsigned long MyInt x;

For the 'no size' modifier, I propose the usage of '' meaning neither
long nor short.
Rewriting the example using default values:
   template <sign_mod SIGN_MOD = signed, size_mod = '' > MyInt;

Of course, the effect is that inside the class, one can declare
   SIGN_MOD int _x;
where SIGN_MOD will be replaced with the sign modifier.

In short, for the latter, the following new keywords would be added to
the template parameter declaration context:
    sign_mod   (whose possibles values are signed/unsigned)
    size_mod   (whose possibles values are short/long/'')

together with typename, class, int, etc.

Thanks!

  Daniel.

---
[ 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                       ]