In article <dwalker07-1259DF.05503025082004@newsclstr01.news.prodigy.com> Daryle Walker wrote:
>In article
><3aqWc.503202$Gx4.145197@bgtnsc04-news.ops.worldnet.att.net>,
> ark@acm.org ("Andrew Koenig") wrote:

>>     template<class T, size_t N> size_t lengthof(T (&)[N]) { return N; }
>
>Hiding the "cute" idiom computation in a template (or macro) is still a
>problem!  I suggest that these attributes should be built-in compiler
>operators.

The template is better than the macro or your proposed extension, as it
actually checks to see that you are indeed passing in an array.

>Why should the compiler go through a template or macro computation
>(which burns nesting and/or recursion levels) for something it can
>instantly get from a table?

Any real world examples where this has been a problem?  It is a pretty
simple top level template; I'm not seeing how it burns nesting and/or
recursion levels.  If this one template (or three, if you wish to include
the other two that usually show up with it, namely converting arrays into
begin/end iterators) is overflowing your compiler, you'll have other
problems with your code.

>Even if you claim that the final result
>will be optimized, the compiler still had to waste time in resolving the
>template first.

New keywords and syntaxes do not come for free.
--
 Nevin ":-)" Liber <mailto:nevin@spies.com> (773) 961-1620

---
[ 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 <412A84DF.61C17E18@acm.org>,
 petebecker@acm.org (Pete Becker) wrote:

> Daryle Walker wrote:
> >
> > My problem with this: the compiler knew this information _already_!  Why
> > do I have to do stupid compiler tricks to sucker that information out of
> > the compiler?!
>
> Because arrays aren't first class types. They have many weaknesses, and
> most people feel that trying to fix them is a waste of time. Use
> std::vector.

I have my own issues with that (especially since the defeatist party
line is inaccurate)!  But that's for another thread....

You also missed that I was giving one case of a general problem.

> > (Not to mention that I have to hope that the compiler
> > optimizes the division out of existence.)
> >
>
> You get a compile-time constant, so the only effect of the division is
> at compile time, not runtime.

But the compiler still had to waste time computing the division instead
of looking in a table like "lengthof(x)" would have involved.  (Similar
unnecessary wastes of time are why I feel that template- or macro-based
solutions are wrong-headed.  The calculation/template/macro is just
going to sucker the compiler to look into its attribute table anyway, so
why not ask directly?)

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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 <6evWc.52137$1V3.1387415@twister2.libero.it>,
 AlbertoBarbati@libero.it (Alberto Barbati) wrote:

> Daryle Walker wrote:
[SNIP]
> > I was only going to talk about "lengthof", but we have another problem.
> > There is all sorts of information that the compiler could tell us.  We
> > need to extend the "whateverof" concept in a way that doesn't suck up
> > potential identifiers (as new keywords).  We need something like:
>
> Looks like the thing is getting out of hands... Why do you want to
> complicate things that are easy?

The problem is that the current system is _not_ extensible.  We would
have to use up another "whateverof" identifier as a new keyword for each
attribute we want to examine.

> >    struct b { long cc; double dd; }
> >    b const  ee;
> >
> >    attribute<"sizeof">(int) --> 4
> >    attribute<"sizeof">(x)   --> 12
>
> What's wrong with plain sizeof(x)?
>
> >    attribute<"length">(x)   --> 3
>
> lenghtof(x)? (if it were standardized, that is)
>
> >    attribute<"offset">(b, dd) --> 4  // 4-byte long, no padding
>
> offsetof(b, dd)? (that's standard)
[TRUNCATE]

I would suggest retiring "sizeof" and "offsetof" afterwards.  (Or at
least define them as calling the new generation versions.)

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ 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
<3aqWc.503202$Gx4.145197@bgtnsc04-news.ops.worldnet.att.net>,
 ark@acm.org ("Andrew Koenig") wrote:

> "Daryle Walker" <dwalker07@snet.net> wrote in message
> news:dwalker07-9AE10B.19023222082004@newsclstr01.news.prodigy.com...
>
> > My problem with this: the compiler knew this information _already_!  Why
> > do I have to do stupid compiler tricks to sucker that information out of
> > the compiler?!  (Not to mention that I have to hope that the compiler
> > optimizes the division out of existence.)
> >
> > Why do we have to use any "cute" idiom to extract what compiler already
> > knows?
>
> You don't:
>
>     template<class T, size_t N> size_t lengthof(T (&)[N]) { return N; }

Hiding the "cute" idiom computation in a template (or macro) is still a
problem!  I suggest that these attributes should be built-in compiler
operators.

Why should the compiler go through a template or macro computation
(which burns nesting and/or recursion levels) for something it can
instantly get from a table?  Even if you claim that the final result
will be optimized, the compiler still had to waste time in resolving the
template first.

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

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

dietmar_kuehl@yahoo.com ("dietmar_kuehl@yahoo.com") writes:

| "Andrew Koenig" wrote:
| >     template<class T, size_t N> size_t lengthof(T (&)[N]) { return N;
| }
|
| Note that this is not a constant expression (you probably know...).

True.  But I expect that we'll hopefully fix that embarassment with
the proposed constant-valued functions you're alluding to:

[...]

| Rather than adding an operator for this special case, I would prefer
| a solution which allows function calls in constant expressione. The
| functions may be restricted to be inline and/or being marked with
| some special keyword or whatever.

   http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2003/n1521.pdf

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

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

Daryle Walker wrote:
> There is all sorts of information that the compiler could tell us.  We
> need to extend the "whateverof" concept in a way that doesn't suck up
> potential identifiers (as new keywords).  We need something like:

There is proposal to add type traits, see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1424.htm and
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1519.htm

you may come up with additional traits to enhance this proposal, but
examine the latter document first.


B.

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

Daryle Walker wrote:
> Let's declare
>    int  x[] = { 3, 2, 9 };
> How do I get the number of elements in "x".

Like this:
     template <typename T, unsigned N> unsigned length(T (&)[N]) { return N; }

If you want a compile-time constant,
     template <typename T, unsigned N> char (&(alen(T (&)[N])))[N];

     int x[] = { 3, 2, 9 };
     double y[sizeof(alen(x))];

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

"Daryle Walker" <dwalker07@snet.net> wrote in message
news:dwalker07-9AE10B.19023222082004@newsclstr01.news.prodigy.com...

> My problem with this: the compiler knew this information _already_!  Why
> do I have to do stupid compiler tricks to sucker that information out of
> the compiler?!  (Not to mention that I have to hope that the compiler
> optimizes the division out of existence.)
>
> Why do we have to use any "cute" idiom to extract what compiler already
> knows?

You don't:

    template<class T, size_t N> size_t lengthof(T (&)[N]) { return N; }

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

Daryle Walker wrote:
>
> My problem with this: the compiler knew this information _already_!  Why
> do I have to do stupid compiler tricks to sucker that information out of
> the compiler?!

Because arrays aren't first class types. They have many weaknesses, and
most people feel that trying to fix them is a waste of time. Use
std::vector.

> (Not to mention that I have to hope that the compiler
> optimizes the division out of existence.)
>

You get a compile-time constant, so the only effect of the division is
at compile time, not runtime.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.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.jamesd.demon.co.uk/csc/faq.html                       ]

"Andrew Koenig" wrote:
>     template<class T, size_t N> size_t lengthof(T (&)[N]) { return N;
}

Note that this is not a constant expression (you probably know...).
A real "lengthof()" operator could produce a constant expression. For
now, getting a constant expression can be achieved through some
hackery using 'sizeof()' and a function "returning" a char array (the
function is actually never called).

Rather than adding an operator for this special case, I would prefer
a solution which allows function calls in constant expressione. The
functions may be restricted to be inline and/or being marked with
some special keyword or whatever.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.contendix.com> - Software Development & Consulting

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

dietmar_kuehl@yahoo.com wrote:
> Rather than adding an operator for this special case, I would prefer
> a solution which allows function calls in constant expressione. The
> functions may be restricted to be inline and/or being marked with
> some special keyword or whatever.

you mean something like proposal N1521?


B.

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

Let's declare

   int  x[] = { 3, 2, 9 };

How do I get the number of elements in "x".  Besides typing in a "3" by
fiat, I can do:

   std::size_t const  x_length = sizeof(x) / sizeof(x[0]);

I can even wrap this general idea with a macro or template class
construct.

My problem with this: the compiler knew this information _already_!  Why
do I have to do stupid compiler tricks to sucker that information out of
the compiler?!  (Not to mention that I have to hope that the compiler
optimizes the division out of existence.)

Why do we have to use any "cute" idiom to extract what compiler already
knows?

For this case, we could define a "lengthof" operator that works like
"sizeof"

   assert( lengthof(x) == 3 );

To complete the semantics:

   float   y;
   char *  z;
   bool    a[5][9];

   assert( lengthof(y) == 0 );
   assert( lengthof(z) == 0 );
   assert( lengthof(a) == 5 );

The "lengthof" operator only works with true compile-time arrays.  Other
types return zero.  Since we don't have true multi-dimensional arrays,
only the top-level length is returned for multi-level arrays.

I was only going to talk about "lengthof", but we have another problem.
There is all sorts of information that the compiler could tell us.  We
need to extend the "whateverof" concept in a way that doesn't suck up
potential identifiers (as new keywords).  We need something like:

   struct b { long cc; double dd; }
   b const  ee;

   attribute<"sizeof">(int) --> 4
   attribute<"sizeof">(x)   --> 12
   attribute<"length">(x)   --> 3
   attribute<"offset">(b, dd) --> 4  // 4-byte long, no padding

   type_attribute<"deref">(char *)  --> char
   type_attribute<"element">(x)     --> int

   special_attribute<"qualifier">(ee)  --> const

This probably isn't good syntax.  Hopefully this is food for thought
(and Google searches).

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

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

Daryle Walker wrote:

>
> For this case, we could define a "lengthof" operator that works like
> "sizeof"
>
>    assert( lengthof(x) == 3 );
>

I also wondered why such a macro hasn't ever been included in the C
library. The "sizeof array / sizeof array[0]" idiom is explicitly cited
in the C standard and is therefore supposed to be portable.

> I was only going to talk about "lengthof", but we have another problem.
> There is all sorts of information that the compiler could tell us.  We
> need to extend the "whateverof" concept in a way that doesn't suck up
> potential identifiers (as new keywords).  We need something like:

Looks like the thing is getting out of hands... Why do you want to
complicate things that are easy?

>    struct b { long cc; double dd; }
>    b const  ee;
>
>    attribute<"sizeof">(int) --> 4
>    attribute<"sizeof">(x)   --> 12

What's wrong with plain sizeof(x)?

>    attribute<"length">(x)   --> 3

lenghtof(x)? (if it were standardized, that is)

>    attribute<"offset">(b, dd) --> 4  // 4-byte long, no padding

offsetof(b, dd)? (that's standard)

>
>    type_attribute<"deref">(char *)  --> char
>    type_attribute<"element">(x)     --> int
>
>    special_attribute<"qualifier">(ee)  --> const

These have already being proposed as an extension, with a template
syntax. They're called type traits. You can find the proposal here:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1424.htm
See also the Boost library for an implementation.

Regards,

Alberto

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