Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > sizeof(Struct::Member) rationale

Reply
Thread Tools

sizeof(Struct::Member) rationale

 
 
petschy
Guest
Posts: n/a
 
      09-02-2008
Hello All,

I confronted recently with the fact that the size of a struct member
can't be determined with sizeof(Struct::Member). I'm aware of the
alternative methods to do this, however, I'm interested in the
rationale why the Struct::Member syntax is disallowed.

Thanks, P
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      09-02-2008
petschy wrote:
> Hello All,
>
> I confronted recently with the fact that the size of a struct member
> can't be determined with sizeof(Struct::Member). I'm aware of the
> alternative methods to do this, however, I'm interested in the
> rationale why the Struct::Member syntax is disallowed.
>

Was it even proposed?

If so, what benefits would it bring?

--
Ian Collins.
 
Reply With Quote
 
 
 
 
petschy
Guest
Posts: n/a
 
      09-02-2008
> Was it even proposed?

I don't know.

> If so, what benefits would it bring?


I needed the size of a member, without an actual instance and the
syntax 'felt' natural. This could be done, so I just wondered why is
it disallowed.

P
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      09-02-2008
petschy wrote:
>> Was it even proposed?

>
> I don't know.
>
>> If so, what benefits would it bring?

>
> I needed the size of a member, without an actual instance and the
> syntax 'felt' natural. This could be done, so I just wondered why is
> it disallowed.
>

In order to see the member, you have to be able to see its type, so why
not take the size of the type?

Something that hasn't been asked for can't be disallowed.

--
Ian Collins.
 
Reply With Quote
 
petschy
Guest
Posts: n/a
 
      09-02-2008
> In order to see the member, you have to be able to see its type, so why
> not take the size of the type?


Yes, that works, but then I need to remember the type of the member,
which the compiler knows anyway. Also, with arrays things get even
more uncomfortable if I want to use the type for the size. Luckily,
sizeof(Struct().Member) works, so my question was rather theoretical
than practical.

Thanks, P
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      09-02-2008
petschy wrote:
> I confronted recently with the fact that the size of a struct member
> can't be determined with sizeof(Struct::Member). I'm aware of the
> alternative methods to do this, however, I'm interested in the
> rationale why the Struct::Member syntax is disallowed.


AFAIK, it will be allowed in the next standard.
 
Reply With Quote
 
Triple-DES
Guest
Posts: n/a
 
      09-03-2008
On 2 Sep, 22:42, petschy <(E-Mail Removed)> wrote:
> Hello All,
>
> I confronted recently with the fact that the size of a struct member
> can't be determined with sizeof(Struct::Member). I'm aware of the
> alternative methods to do this, however, I'm interested in the
> rationale why the Struct::Member syntax is disallowed.
>
> Thanks, P


Hi. As Juha pointed out, this is already in the draft for the next
standard, but that does not really answer your question .

You may find these links interesting:

http://www.open-std.org/JTC1/sc22/wg...fects.html#198
http://www.open-std.org/jtc1/sc22/wg...007/n2253.html

DP
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      09-03-2008
On Sep 2, 11:31 pm, Ian Collins <(E-Mail Removed)> wrote:
> petschy wrote:
> >> Was it even proposed?


> > I don't know.


> >> If so, what benefits would it bring?


> > I needed the size of a member, without an actual instance and the
> > syntax 'felt' natural. This could be done, so I just wondered why is
> > it disallowed.


> In order to see the member, you have to be able to see its
> type, so why not take the size of the type?


Because you're in a template, and the requirement is that the
instantiation type have a member named toto? (Just guessing.
I've never needed it either.)

--
James Kanze (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
petschy
Guest
Posts: n/a
 
      09-03-2008
> You may find these links interesting:
>
> http://www.open-std.org/JTC1/sc22/wg...fects.html#198
> http://www.open-std.org/jtc1/sc22/wg...007/n2253.html


Indeed!
Thanks!
P
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Question about rationale for java.nio.Buffer design. Harald Kirsch Java 0 06-14-2004 12:15 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 42 04-06-2004 10:11 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 2 04-02-2004 08:49 PM
Re: The Sigma-Foveon pixel rationale Dave Martindale Digital Photography 2 04-01-2004 05:01 PM
Re: The Sigma-Foveon pixel rationale David J. Littleboy Digital Photography 2 04-01-2004 08:11 AM



Advertisments