qrczak@knm.org.pl ("Marcin 'Qrczak' Kowalczyk") writes:

| An anonymous union is allowed inside an anonymous union, despite that it's
| equivalent to splicing its contents. Why would a struct in a struct be
| treated differently?

Then the standard should probably remove unnamed unions.

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

On one of the other newsgroups the perennial question about why we can
have anonymous unions as class members but not have anonymous structs.
Of course the straight forward answer is that they buy nothing. However
I then went on to think further.

What if we could write:

class myclass {
   struct & ;
// rest
};

To declare that reference to an anonymous struct/class. Note that the
compiler does not need a name for this member data because all it has to
do is to provide the mechanism for handling a reference to a
struct/class object.

In the implementation we could have something such as:

myclass::struct {
   double d;
   int i;
};

and just as we do with unions, we could use the member variable names as
if they were direct members of the enclosing class.  This would allow us
to hide the data structure of the class in an implementation file. The
gain is that if performance requires that we remove that layer of
indirection we can do so simply by replacing the anonymous struct with
the actual member declarations. We would not need to touch the
implementation code.

This is very much a raw first set of thoughts but I wonder if it is
worth going further.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

On 2004-05-02 23:36, Francis Glassborow wrote:
:
> What if we could write:
>
> class myclass {
>    struct & ;
> // rest
> };
:
> In the implementation we could have something such as:
>
> myclass::struct {
>    double d;
>    int i;
> };
>
> and just as we do with unions, we could use the member variable
> names as if they were direct members of the enclosing class.
> This would allow us to hide the data structure of the class in an
> implementation file. The gain is that if performance requires that
> we remove that layer of indirection we can do so simply by replacing
> the anonymous struct with the actual member declarations. We would
> not need to touch the implementation code.

With some variant of pimpl, you can use the same syntax as well by
making the struct a direct member of the class. E.g. (untested):

Pimpl:

   Header:

      struct M;   // forward declaration

      class C {
         M & m;
      public:
         void f();
         // rest;
      };

   Implementation:

      struct M { int n; };

      void C::f() { ++m.i; }

      // rest

Non-pimpl:

   Header:

      struct M { int n; };

      class C {
         M m;
      public:
         void f();
         // rest;
      };

   Implementation:

      void C::f() { ++m.i; }  // same as with pimpl

Or am I missing something?

-- Niklas Matthies

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

On Sun, 02 May 2004 23:36:09 +0000, Francis Glassborow wrote:

> On one of the other newsgroups the perennial question about why we can
> have anonymous unions as class members but not have anonymous structs.
> Of course the straight forward answer is that they buy nothing.

They buy something when they are used as members of a union. You can't
just splice their contents into the union.

If they were allowed in a union, it would make sense to allow them in a
class or struct for consistency.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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

francis@robinton.demon.co.uk (Francis Glassborow) writes:
[snip]
> What if we could write:
>
> class myclass {
>    struct & ;
> // rest
> };
>
> To declare that reference to an anonymous struct/class. Note that the
> compiler does not need a name for this member data because all it has to
> do is to provide the mechanism for handling a reference to a
> struct/class object.
>
> In the implementation we could have something such as:
>
> myclass::struct {
>    double d;
>    int i;
> };
>
> and just as we do with unions, we could use the member variable names as
> if they were direct members of the enclosing class.  This would allow us
> to hide the data structure of the class in an implementation file. The
> gain is that if performance requires that we remove that layer of
> indirection we can do so simply by replacing the anonymous struct with
> the actual member declarations. We would not need to touch the
> implementation code.
>
> This is very much a raw first set of thoughts but I wonder if it is
> worth going further.
[snip]

Could you post a contrast/comparison of this with the compilation
    firewall idiom?

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

"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message news:Z3wpTjb6tXlAFwDf@robinton.demon.co.uk...

| This would allow us
| to hide the data structure of the class in an implementation file. The
| gain is that if performance requires that we remove that layer of
| indirection we can do so simply by replacing the anonymous struct with
| the actual member declarations. We would not need to touch the
| implementation code.
|
| This is very much a raw first set of thoughts but I wonder if it is
| worth going further.

In general it would be great if there were some kind of compiler assistance
with implementation hiding. For example,

class X
{
   struct impl_t;
   implementation impl_t impl;
};

// X.cpp

struct X::impl_t
{
};

This might work with the restriction that X can only be heap-allocated since it size cannot
be inferred from the header.

just a crasy thought

br

Thorsten


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

usenet-nospam@nmhq.net (Niklas Matthies) writes:

> On 2004-05-02 23:36, Francis Glassborow wrote:
> :
>> What if we could write:
>>
>> class myclass {
>>    struct & ;
>> // rest
>> };
> :
>> In the implementation we could have something such as:
>>
>> myclass::struct {
>>    double d;
>>    int i;
>> };
>>
>> and just as we do with unions, we could use the member variable
>> names as if they were direct members of the enclosing class.
>> This would allow us to hide the data structure of the class in an
>> implementation file. The gain is that if performance requires that
>> we remove that layer of indirection we can do so simply by replacing
>> the anonymous struct with the actual member declarations. We would
>> not need to touch the implementation code.
>
> With some variant of pimpl, you can use the same syntax as well by
> making the struct a direct member of the class. E.g. (untested):
>
> Pimpl:
>
>    Header:
>
>       struct M;   // forward declaration

You can get closer to Francis's syntax by forward declaring the
    struct inside the class.

>       class C {
>          M & m;
>       public:
>          void f();
>          // rest;
>       };
[snip]

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

francis@robinton.demon.co.uk (Francis Glassborow) writes:

> On one of the other newsgroups the perennial question about why we can
> have anonymous unions as class members but not have anonymous structs.
> Of course the straight forward answer is that they buy nothing. However
> I then went on to think further.
>
> What if we could write:
>
> class myclass {
>    struct & ;
> // rest
> };
>
> To declare that reference to an anonymous struct/class. Note that the
> compiler does not need a name for this member data because all it has to
> do is to provide the mechanism for handling a reference to a
> struct/class object.
>
> In the implementation we could have something such as:
>
> myclass::struct {
>    double d;
>    int i;
> };
>
> and just as we do with unions, we could use the member variable names as
> if they were direct members of the enclosing class.  This would allow us
> to hide the data structure of the class in an implementation file. The
> gain is that if performance requires that we remove that layer of
> indirection we can do so simply by replacing the anonymous struct with
> the actual member declarations. We would not need to touch the
> implementation code.

So, seeing just the declaration of myclass, how does the compiler
allocate space for

     myclass x;

??

> This is very much a raw first set of thoughts but I wonder if it is
> worth going further.

It seems to be totally incompatible with C++'s compilation model.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.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                       ]

On Sun, 2 May 2004 23:36:09 +0000 (UTC), Francis Glassborow wrote:

>
>On one of the other newsgroups the perennial question about why we can
>have anonymous unions as class members but not have anonymous structs.
>Of course the straight forward answer is that they buy nothing. However
>I then went on to think further.


Is there a rationale for the argument that they buy nothing.  I had a
need for an anonymous struct recently, as shown in the following code
where I would like to use xflags instead of flags.  GCC allows the
anonymous struct and Comeau allows it with a warning but I ended up not
using it because it's non standard.  It's not a big deal but I would
have used it if it was standard C++.

(Also I'd like a guarantee that a 16 bit unsigned integral type will
always be around ...)


typedef unsigned short uint16;

struct flags
{
    bool f1:1;
    bool f2:1;
    bool f3:1;
    bool f4:1;
    // fill up with unused bools to make 16 bits
};

struct flags2
{
    union {
        uint16 whole;
        flags  bits;
    };
};

struct xflags
{
    union {
        struct
        {
            bool f1:1;
            bool f2:1;
            // ...
        };
        uint16 whole;
    };
};

int main()
{
    flags t1,t2;
    // ...
    // compare t1,t2
    flags2 x1,x2;
    x1.bits = t1;
    x2.bits = t2;
    if (x1.whole != x2.whole)
    {  // ...
    }

    xflags s1,s2;
    s1.f1 = s2.f1 = true;
    // ...
    if (s1.whole != s2.whole)
    {  // ...
    }
}

Graeme

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

usenet-nospam@nmhq.net (Niklas Matthies) writes:

> On 2004-05-02 23:36, Francis Glassborow wrote:
> :
>> What if we could write:
>>
>> class myclass {
>>    struct & ;
>> // rest
>> };
> :
>> In the implementation we could have something such as:
>>
>> myclass::struct {
>>    double d;
>>    int i;
>> };
>>
>> and just as we do with unions, we could use the member variable
>> names as if they were direct members of the enclosing class.
>> This would allow us to hide the data structure of the class in an
>> implementation file. The gain is that if performance requires that
>> we remove that layer of indirection we can do so simply by replacing
>> the anonymous struct with the actual member declarations. We would
>> not need to touch the implementation code.
>
> With some variant of pimpl, you can use the same syntax as well by
> making the struct a direct member of the class. E.g. (untested):
>
> Pimpl:
>
>    Header:
>
>       struct M;   // forward declaration

You can get closer to Francis's syntax by forward declaring>

>       class C {
>          M & m;
>       public:
>          void f();
>          // rest;
>       };
[snip]

---
[ 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 <u4qqy2txk.fsf@boost-consulting.com>, David Abrahams
<dave@boost-consulting.com> writes
>So, seeing just the declaration of myclass, how does the compiler
>allocate space for
>
>     myclass x;
>
>??

Exactly the same way that it allocates space for:

class example {
  struct cat;
  cat * smile;
// rest

};


>
>> This is very much a raw first set of thoughts but I wonder if it is
>> worth going further.
>
>It seems to be totally incompatible with C++'s compilation mode

Look again and remember that I was just sketching an idea without
filling in too much detail.

There is no magic in the class definition, indeed we could do almost the
same today as above.

The special feature comes in the implementation:

Today we can write:

example::cat {
   int i;
   double d;
};

example::example(): smile(new cat){}
example::~example(){delete smile;}

and refer to the data as smile->i and smile->d. However if the
programmer decides for performance to remove the compiler firewall and
use:

class example {
  int i;
  double d;
// rest

};

they now have to touch the whole of the implementation rather than
recompile it. What I am suggesting is that supporting

class example {
   struct &;
// rest
};

coupled with allowing the members of an anonymous struct to be referred
to as if they were members of the enclosing class allows the
implementation file to be (almost) lexically independent of whether a
'compiler firewall' is or is not used. If it is, dynamic allocation and
deallocation is automatically provided. If the data members are declared
directly in the class definition everything works as it always has.

I do not think this is completely at variance with the current C++
compilation mode. It simply delegates certain boiler plate code to the
compiler. The problem we have at the moment is that switching between a
class definition using a 'compiler firewall' and one without requires a
good deal of modification to the source code. Note that I am not
proposing link time compatibility, only maximum source level
compatibility.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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 <cevb90tmical3jnldmelnqt4uqblebrhv2@4ax.com>, Graeme Prentice
<gprenz@hotmail.com> writes
>Is there a rationale for the argument that they buy nothing.  I had a
>need for an anonymous struct recently, as shown in the following code
>where I would like to use xflags instead of flags.  GCC allows the
>anonymous struct and Comeau allows it with a warning but I ended up not
>using it because it's non standard.  It's not a big deal but I would
>have used it if it was standard C++.
>
>(Also I'd like a guarantee that a 16 bit unsigned integral type will
>always be around ...)
>
>
>typedef unsigned short uint16;
>
>struct flags
>{
>    bool f1:1;
>    bool f2:1;
>    bool f3:1;
>    bool f4:1;
>    // fill up with unused bools to make 16 bits
>};
Ah...I had missed the convenience of named bit-fields. Perhaps that does
justify reconsidering anonymous structs.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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 5p$BkgdEtolAFw22@robinton.demon.co.uk, Francis Glassborow at
francis@robinton.demon.co.uk wrote on 5/3/04 11:26 AM:

> In article <cevb90tmical3jnldmelnqt4uqblebrhv2@4ax.com>, Graeme Prentice
> <gprenz@hotmail.com> writes
>> Is there a rationale for the argument that they buy nothing.

None that I can see.  I never understood the choice.

>> I had a
>> need for an anonymous struct recently, as shown in the following code
>> where I would like to use xflags instead of flags.  GCC allows the
>> anonymous struct and Comeau allows it with a warning but I ended up not
>> using it because it's non standard.  It's not a big deal but I would
>> have used it if it was standard C++.
>>
>> (Also I'd like a guarantee that a 16 bit unsigned integral type will
>> always be around ...)
>>
>>
>> typedef unsigned short uint16;
>>
>> struct flags
>> {
>> bool f1:1;
>> bool f2:1;
>> bool f3:1;
>> bool f4:1;
>> // fill up with unused bools to make 16 bits
>> };
> Ah...I had missed the convenience of named bit-fields. Perhaps that does
> justify reconsidering anonymous structs.

The utility doesn't depend on the use of bit fields.  It is just as Marcin
'Qrczak' Kowalczyk said:

in article pan.2004.05.03.00.13.18.990024@knm.org.pl, "Marcin 'Qrczak'
Kowalczyk" at qrczak@knm.org.pl wrote on 5/2/04 11:05 PM:

> They buy something when they are used as members of a union. You can't
> just splice their contents into the union.
>
> If they were allowed in a union, it would make sense to allow them in a
> class or struct for consistency.

This is particularly important if you suddenly realize you need to create a
member that overlays other members in an arbitrary way, but previously there
was only one layer:  a struct.  Now you need to add an anonymous union and
would love to embed the original struct members (or some of them) in an
anonymous struct within that union so that you don't have to rewrite all
code references to the original member names.

For example:

    original implementation:

        struct stuff
        {
            long            field1;
            long            field2;
        };

    desired enhanced implementation, if only it were possible:

        struct stuff
        {
            long            field1;
            union
            {
                long        field2;
                struct
                {
                    short   field2a;
                    short   field2b;
                };
            };
        };

    or equally, the original implementation might have been:

        struct stuff
        {
            long            field1;
            short           field2a;
            short           field2b;
        };

    and you might have ended up in the same place.

This kind of thing has come up for me several times, once when enhancing an
interpreter in an way entirely unanticipated in the original design.

In fact for me I believe it has come up *every* time I went to use an
anonymous union.  Oh boy, I thought, until I realized that anonymous unions
weren't delivering what they promised, because to really do that anonymous
structs are also needed.

-Kurt Bigler

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

gprenz@hotmail.com (Graeme Prentice) writes:

> On Sun, 2 May 2004 23:36:09 +0000 (UTC), Francis Glassborow wrote:
>
>>
>>On one of the other newsgroups the perennial question about why we can
>>have anonymous unions as class members but not have anonymous structs.
>>Of course the straight forward answer is that they buy nothing. However
>>I then went on to think further.
>
>
> Is there a rationale for the argument that they buy nothing.

My rationale was that no-one had shown be an example. Now that I've
    seen this one, I can appreciate one use.

[snip]
> struct xflags
> {
>     union {
>         struct
>         {
>             bool f1:1;
>             bool f2:1;
>             // ...
>         };
>         uint16 whole;
>     };
> };
[snip]

---
[ 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 <BCBC01E7.1452A%kkb@breathsense.com>, Kurt Bigler
<kkb@breathsense.com> writes
>        struct stuff
>        {
>            long            field1;
>            union
>            {
>                long        field2;
>                struct
>                {
>                    short   field2a;
>                    short   field2b;
>                };

Change that to }alias;
  and you can write alias.field2a and alias.field2b. That does not seem
very difficult and distinguishes between the levels. Anonymous unions
are used to allow the same block of memory to be referenced by different
names according to the type of data being stored.
>            };
>        };

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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 <863c6h117l.fsf@Zorthluthik.local.bar>, llewelly
<llewelly.at@xmission.dot.com> writes
>gprenz@hotmail.com (Graeme Prentice) writes:
>
>> On Sun, 2 May 2004 23:36:09 +0000 (UTC), Francis Glassborow wrote:
>>
>>>
>>>On one of the other newsgroups the perennial question about why we can
>>>have anonymous unions as class members but not have anonymous structs.
>>>Of course the straight forward answer is that they buy nothing. However
>>>I then went on to think further.
>>
>>
>> Is there a rationale for the argument that they buy nothing.
>
>My rationale was that no-one had shown be an example. Now that I've
>    seen this one, I can appreciate one use.
>
>[snip]
>> struct xflags
>> {
>>     union {
>>         struct
>>         {
>>             bool f1:1;
>>             bool f2:1;
>>             // ...
>>         };

But replacing that line with
           }field;
supports:
   field.f1, field.f2 etc. which seems more expressive to me and a small
penalty in typing.

>>         uint16 whole;
>>     };
>> };

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

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

Marcin 'Qrczak' Kowalczyk wrote:
> On Sun, 02 May 2004 23:36:09 +0000, Francis Glassborow wrote:
>
>
>>On one of the other newsgroups the perennial question about why we can
>>have anonymous unions as class members but not have anonymous structs.
>>Of course the straight forward answer is that they buy nothing.
>
>
> They buy something when they are used as members of a union. You can't
> just splice their contents into the union.

Yes, anonymous structs in unions are useful, to allow overlaying data
formats without having to use artificial access qualifiers.

>
> If they were allowed in a union, it would make sense to allow them in a
> class or struct for consistency.
>

I don't see any use for anonymous structs other than in a union. Can
you provide an example?  That is, what advantage does
     struct { ... };
have inside a struct compared to writing just the "..." part?

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

francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>Kurt Bigler <kkb@breathsense.com> wrote:
>>
>>                struct
>>                {
>>                    short   field2a;
>>                    short   field2b;
>>                };
>
>Change that to }alias;
>  and you can write alias.field2a and alias.field2b. That does not seem
>very difficult and distinguishes between the levels.

What if there are thousands of lines of code to update and the names
field2a and field2b aren't unique so references can't be fixed using
search & replace?

Tony.
--
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
ST DAVIDS HEAD TO COLWYN BAY, INCLUDING ST GEORGES CHANNEL: NORTHWEST 4 OR 5
OCCASIONALLY 6 BUT LOCALLY 7 IN SOUTH BACKING WEST 5 OR 6 LATER. RAIN OR
SHOWERS. MODERATE OR GOOD. MODERATE TO ROUGH.

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

On Tue, 04 May 2004 18:17:39 +0000, Steve Clamage wrote:

>> If they were allowed in a union, it would make sense to allow them in a
>> class or struct for consistency.
>
> I don't see any use for anonymous structs other than in a union. Can
> you provide an example?

They are not very useful in another struct. But allowing them in a union
and not in a struct would probably lead to less simple rules.

An anonymous union is allowed inside an anonymous union, despite that it's
equivalent to splicing its contents. Why would a struct in a struct be
treated differently?

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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

llewelly.at@xmission.dot.com (llewelly) writes:

> gprenz@hotmail.com (Graeme Prentice) writes:
>
>> On Sun, 2 May 2004 23:36:09 +0000 (UTC), Francis Glassborow wrote:
>>
>>>
>>>On one of the other newsgroups the perennial question about why we can
>>>have anonymous unions as class members but not have anonymous structs.
>>>Of course the straight forward answer is that they buy nothing. However
>>>I then went on to think further.
>>
>>
>> Is there a rationale for the argument that they buy nothing.
>
> My rationale was that no-one had shown be an example. Now that I've
>     seen this one, I can appreciate one use.
>
> [snip]
>> struct xflags
>> {
>>     union {
>>         struct
>>         {
>>             bool f1:1;
>>             bool f2:1;
>>             // ...
>>         };
>>         uint16 whole;
>>     };
>> };
> [snip]

Sorry to reply to my own post, but I meant to add above that while
    this one use changes my previous perception that anonymous
    structs buy nothing, I don't think that this alone is enough to
    merit their inclusion in a future C++. It's a starting point, but
    IMO more compelling uses should be presented, if they exist.


---
[ 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 zAB*-DFjq@news.chiark.greenend.org.uk, Tony Finch at dot@dotat.at
wrote on 5/4/04 11:43 AM:

> francis@robinton.demon.co.uk (Francis Glassborow) wrote:
>> Kurt Bigler <kkb@breathsense.com> wrote:
>>>
>>> struct
>>> {
>>> short   field2a;
>>> short   field2b;
>>> };
>>
>> Change that to }alias;
>> and you can write alias.field2a and alias.field2b. That does not seem
>> very difficult and distinguishes between the levels.
>
> What if there are thousands of lines of code to update and the names
> field2a and field2b aren't unique so references can't be fixed using
> search & replace?

Exactly.  And if such recoding (or even *original* coding) is not an issue
then it is equally no issue in the simple anonymous union case and by that
argument there is no motivation for an anonymous union either.

-Kurt

>
> Tony.

---
[ 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 s8oURtaYL8lAFw1e@robinton.demon.co.uk, Francis Glassborow at
francis@robinton.demon.co.uk wrote on 5/4/04 10:31 AM:

> In article <BCBC01E7.1452A%kkb@breathsense.com>, Kurt Bigler
> <kkb@breathsense.com> writes
>> struct stuff
>> {
>> long            field1;
>> union
>> {
>> long        field2;
>> struct
>> {
>> short   field2a;
>> short   field2b;
>> };
>
> Change that to }alias;
> and you can write alias.field2a and alias.field2b. That does not seem
> very difficult and distinguishes between the levels. Anonymous unions
> are used to allow the same block of memory to be referenced by different
> names according to the type of data being stored.

Since I want to reply regarding a movitation for anonymous structs, I want
to make explicit what is not explicit in what you said above, so I can go
further with it clearly.  The way I read it, your last sentence above
describes a motivation for unions, not for anonymous unions.  I don't see a
way to clarify this without getting into the nitty-gritty of it.  So I'll
start by making the anonymous part explicit in this rewrite:

Anonymous unions are used to allow the same block of memory to be referenced
by different names according to the type of data being stored, while at the
same time minimizing a certain class of what I will call "typing penalties".

Exactly what kinds of typing penalties was targeted in the decision to
include anonymous unions I am not in a position to speak about.  But clearly
it was considered a good thing for some set of reasons to *in effect* be
able to have a group of consecutive "members" of an outer structure share
the same storage without having to give a name to the grouping itself.  It
seems clear to me that the name for the grouping is omitted not primarily
for the benefit of the declaration but rather for the benefit of references
elsewhere in the code.  I believe that if you look at the actual situations
that are benefited there will be no basis for distinguishing the importance
of allowing anonymous structs (within an anonymous union) from the
importance of allowing anonymous unions alone.  I believe that arguing
otherwise in in effect arguing that this goal:

(*) to allow in effect consecutive "members" of an outer structure to share
the same storage while at the same time minimizing a certain class of
"typing penalties"

is more important than this goal:

(*) to allow in effect consecutive "members" or *groups* of "members" of an
outer structure to share the same storage while at the same time minimizing
a certain class of "typing penalties"

and I can't see how such an argument can be justified.  Furthermore the
current standard's support for the first goal without the second *in my
experience* added something that is only useful in very special situations
(which in fact I have by some coincidence never encountered in all these
years) whereas supporting the broader second goal eliminates that apparently
unnecessary limitation.

In case that second goal is not clear an example of a "group" of members in
that sense is the grouping of field2a and field2b, still appearing in the
quoted material above.  I put "members" in quotes above because the members
in question are not actually direct members of the outer structure.

-Kurt Bigler


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

On Tue, 4 May 2004 17:31:07 +0000 (UTC), Francis Glassborow wrote:

>In article <BCBC01E7.1452A%kkb@breathsense.com>, Kurt Bigler
><kkb@breathsense.com> writes
>>        struct stuff
>>        {
>>            long            field1;
>>            union
>>            {
>>                long        field2;
>>                struct
>>                {
>>                    short   field2a;
>>                    short   field2b;
>>                };
>
>Change that to }alias;
>  and you can write alias.field2a and alias.field2b. That does not seem
>very difficult and distinguishes between the levels. Anonymous unions
>are used to allow the same block of memory to be referenced by different
>names according to the type of data being stored.
>>            };
>>        };


I have to disagree with you Francis :)

In our case the extra name adds nothing to the meaning and significantly
degrades the readability and writeability of the code IMO.  We have lots
of code that accesses the bitfields and not much that accesses the
bitfields as a whole so as I previously said, it wasn't a big deal but
since quite a few major C++ compilers appear to support it (VC, GCC, EDG
and Borland and probably Metrowerks and others) it seems like a
candidate for addition to the language to me.  I wonder if MS/ VC
provide it because Microsoft found it useful for encoding/decoding
function return values such as HRESULT which is sometimes accessed as a
whole and sometimes in parts.

I tend to shy away from bitfields in favour of more predictable masks
but I was persuaded by others to use bitfields in our current project.

Graeme

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