On Mon, 2016-01-18 at 18:17 +0100, anonymous via Digitalmars-d-learn
wrote:
> On 18.01.2016 18:10, Russel Winder via Digitalmars-d-learn wrote:
> > So this is an error?
> >
> > union flob {
> > ulong data;
> > struct thingy {
> > uint data;
> > uint bits;
> > }
> > thingy burble;
> > };
> >
> > because you cannot have a union field with a name that is also the
> > name
> > of a struct field defined within the union.
>
> I don't see the problem. You have to access the thingy's 'data'
> through
> the 'burble' member, so there is no ambiguity, is there?
That is what I thought. There is a bit of this stuff in the real more
complicated case. But it transpires I was looking at the wrong bits…
> This would be different, and dmd rejects it accordingly:
> ----
> union flob {
> ulong data;
> struct {
> uint data; /* test.d(4): Error: variable test.flob.data
> conflicts with
> variable test.flob.data at test.d(2) */
> uint bits;
> }
> }
Ah, this is actually what is there and what the problem is.
It seems DStep is producing somewhat strange D from complicated C
unions. The problem is real as you point out in the generated code, but
the generated code is nothing like what I would have generated by hand,
which wouldn't have the problem.
I shall go away and procrastinate for some, to be decided, time about
whether to continue with D or revert back to C++.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
