sizeof member - c++

On 5 Okt., 22:17, "Alexander Arhipenko" <arhip...@gmail.com> wrote:
> Is sizeof expression in following code snippet valid?
>
> struct SomeStructure
> {
> char some_member[10];};
>
> const size_t size = sizeof(SomeStructure::some_member);
>
> Some compilers passes it without errors and give valid results (e.g.,
> IBM Visual Age).

Currently the above expression is not not supported by
Our Holy Standard. But note that there exists a proposal
to fix exactly this:

http://www.open-std.org/jtc1/sc22/wg...007/n2253.html

Also note that the current draft of upcoming C++0x does
already contain the proposed wording changes.

Greetings from Bremen,

Daniel Krügler



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On 6 Oct, 00:17, "Alexander Arhipenko" <arhip...@gmail.com> wrote:
> Is sizeof expression in following code snippet valid?
>
> struct SomeStructure
> {
> char some_member[10];};
>
> const size_t size = sizeof(SomeStructure::some_member);

No, it is not. 5.1[expr.prim]/10 explicitly lists the cases in which
an id-expression (SomeStructure::some_member in this case) for
nonstatic member functions is legal. These are:

1. On the right side of operator. or operator->, for qualified member
access
2. As operand of unary &, to create function pointers
3. To invoke members of base classes in constructors nonstatic member
functions of a derived class

Any other possible use, including argument of sizeof, is not allowed.
The usual trick to do what you want is to do some cast trickery:

const size_t size = sizeof(static_cast<SomeStructure*>(0)-
>some_member);

Note that, since argument of sizeof is not evaluated, dereferencing a
null pointer is not a problem in this case.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> But note that there exists a proposal to fix exactly this:
>
> http://www.open-std.org/jtc1/sc22/wg...007/n2253.html
>

Interesting. That proposal has an example which has

int i = sizeof(S::m); // ok
int j = sizeof(S::m + 42); // error: reference to non-static member in
subexpression

Surely that should be

size_t i = sizeof(S::m); // ok
size_t j = sizeof(S::m + 42); // error: reference to non-static member in
subexpression

Stephen Howe


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

On Oct 18, 2:40 am, "Stephen Howe"
<sjhoweATdialDOTpipexDOT...@giganews.com> wrote:
> > But note that there exists a proposal to fix exactly this:
>
> >http://www.open-std.org/jtc1/sc22/wg...007/n2253.html
>
> Interesting. That proposal has an example which has
>
> int i = sizeof(S::m); // ok
> int j = sizeof(S::m + 42); // error: reference to non-static member in
> subexpression
>
> Surely that should be
>
> size_t i = sizeof(S::m); // ok
> size_t j = sizeof(S::m + 42); // error: reference to non-static member in
> subexpression

No, a C++ program should favor "int" variables for storing integral
values - unless there is a reason for using a different type. In this
example, there is no doubt the the result of the sizeof expression
will fit in an int. Whereas, a size_t variable would likely be less
efficient than an int - by likely being larger (and much larger than
is needed here). A size_t type would have the additional disadvantage
of being unsigned (a fact that the "size_t" typedef name tends to
obscure).

Furthermore, none of the existing code examples in the current C++
Standard ever show the result of a sizeof() expression being assigned
to a variable of size_t; instead, the sizeof value is - in every case
- assigned to a variable of type int.

Greg



--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]