"Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg6l0t$19ii$1@digitaldaemon.com...
> Now, someone, anyone, please try and convince me that this is not a
terrible wart. I'll eat my hat if you succeed.
>
> Maybe we don't care about C compatibility. Maybe we're not interested in
having D be _dramatically_ easier to interface
> to than .NET and Java. Maybe we're not interested in D righting the wrongs
of C and C++. Maybe we're not concerned that,
> without *massive* corporate backing, D needs to minimise its exposure to
being rightly piloried by people who want to be
> able to find glaring faults with the briefest exposure. If so, let me
know, 'cos I've been working hard (for two years)
> under a grand delusion and I clearly need to wake up.

I see, you're trying to access D from C. I really have not anticipated much need for that, but have focussed on making C accessible from D. Not all D types are accessible from C, so if you're writing a D struct to be accessed from C, you'll need to stick with types accessible from C.

"Carlos Santander B." <carlos8294@msn.com> wrote in message news:cg6e09$1462$1@digitaldaemon.com...
> However it compiled before. I don't see why it shouldn't now.

That's why 0.100 came out.

"Walter" <newshound@digitalmars.com> wrote in message news:cg848c$28t3$1@digitaldaemon.com...
>
> "Matthew" <admin.hat@stlsoft.dot.org> wrote in message news:cg6l0t$19ii$1@digitaldaemon.com...
> > Now, someone, anyone, please try and convince me that this is not a
> terrible wart. I'll eat my hat if you succeed.
> >
> > Maybe we don't care about C compatibility. Maybe we're not interested in
> having D be _dramatically_ easier to interface
> > to than .NET and Java. Maybe we're not interested in D righting the wrongs
> of C and C++. Maybe we're not concerned that,
> > without *massive* corporate backing, D needs to minimise its exposure to
> being rightly piloried by people who want to be
> > able to find glaring faults with the briefest exposure. If so, let me
> know, 'cos I've been working hard (for two years)
> > under a grand delusion and I clearly need to wake up.
>
> I see, you're trying to access D from C. I really have not anticipated much need for that, but have focussed on making C accessible from D.

I wasn't necessarily assuming any particular direction, though they'll both have to be taken into account.

> Not all D
> types are accessible from C, so if you're writing a D struct to be accessed
> from C, you'll need to stick with types accessible from C.

Which takes me back to my earlier point that bit should be banned from structs and unions.

Yeah ... best laid plans.

Perhaps it could evolve into the 'bitset' idea (a la Delphi) that was noted by Carlos? That would be very useful to have, and no need for pointers to 'bitset' members either <g>

news:cg6dun$145f$1@digitaldaemon.com


"Walter" <newshound@digitalmars.com> wrote in message news:cg83le$28jf$1@digitaldaemon.com...
>
> "antiAlias" <fu@bar.com> wrote in message news:cg6jbf$186k$1@digitaldaemon.com...
> > I think part of the problem here is that the compiler will not point out
> the
> > distinction for you. It's pretty easy for such things to get completely
> lost
> > within a sea of C structs, so it makes porting rather more tricky than
it
> > might otherwise be ... for this reason alone, I'd tend to agree with the suggestion that bool should really be an alias for ubyte.
> >
> > But, let's not start that all over again :-)
>
> Please nooooo <g>
>
> I'll admit, though, that the implementation of bit has turned out to be
more
> problematic than I'd originally anticipated, what with things like
pointers
> to bits inside bit arrays, etc.
>
>

"Walter" <newshound@digitalmars.com> escribió en el mensaje
news:cg848e$28t3$3@digitaldaemon.com
| "Carlos Santander B." <carlos8294@msn.com> wrote in message
| news:cg6e09$1462$1@digitaldaemon.com...
|| However it compiled before. I don't see why it shouldn't now.
|
| That's why 0.100 came out.

Thanks for that.

-----------------------
Carlos Santander Bernal

In article <cg8bhk$2ctl$1@digitaldaemon.com>, Matthew says...

>Which takes me back to my earlier point that bit should be banned from structs and unions.

I don't like the idea that we would be /forbidden/ from using bits in structs, just in case we might want to pass that struct to a C function, or port the code to C, or whatever. What if we /don't/ want to do any of those things?

Should we also forbid complex numbers in structs? Or classes? Or associative arrays? Or, indeed, /anything/ that D has which C doesn't?

Jill

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cg9g21$22i$1@digitaldaemon.com...
> In article <cg8bhk$2ctl$1@digitaldaemon.com>, Matthew says...
>
> >Which takes me back to my earlier point that bit should be banned from structs and unions.
>
> I don't like the idea that we would be /forbidden/ from using bits in structs, just in case we might want to pass that struct to a C function, or port the code to C, or whatever. What if we /don't/ want to do any of those things?
>
> Should we also forbid complex numbers in structs? Or classes? Or associative arrays? Or, indeed, /anything/ that D has which C doesn't?

Of course. (& don't forget unions as well)

And if that brings out a howl of protest, then I suggest that we need another aggregate class-key for what we now know as struct, since clearly we need something that is unambiguously useful and free of evil subtle pitfalls for interfacing with C. That is, after all, supposedly one of D's major plusses over other C++ evolutions!



You might counter that we are able to include non-POD types in structs in C++. There are several responses:P

1. C++ does not have an ABI. Kind of a strange argument, I grant you, but basically without an ABI there's an "excuse"
for allowing this inconsistency.
2. C++ has a pre-processor, such that one can conditionally define C++ aspects of a struct (e.g. static members, ctors,
etc.), without upsetting the equivalence of size from one language to the other.
3. <stealing myself against the inevitable abuse> C++ practitioners are going to be more able to handle issues of
complexity.
4. So what? D doesn't take on other mistakes in C++'s design.
5. C++ has a shared inclusion model, and shares fundamental types and their sizes, between C and C++. My "heat" on this
issue is primarily driven by the fact that identical looking structs in C and D can have radically different structures
(and this is *not* simply an issue of packing).

"Matthew" <admin.hat@stlsoft.dot.org> escribió en el mensaje
news:cg62d1$ukg$1@digitaldaemon.com
|| In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
|||
||| Because it would be unpleasantly inconsistent. D is already fragile in so
far as
||| one cannot include C headers into D source. If we then compound this
disconnect
||| by having not only different names for things, but having to match up bit
||| variables in D with bitfields in C, it'll just be untenable.

So should D be 100% compatible with C? I don't think that's what you meant, but that's what I can read.

|
| Asked and answered, old bean. Consider the poor hapless developer who needs to
| upgrade his struct from
|
| C:
|
| struct X
| {
|     bool    b;
|     int        i;
| };
|
| D:
|
| struct X
| {
|     bool    b;
|     int        i;
| }
|
|
| to
|
| struct X
| {
|     bool    b[2];
|     int        i;
| };
|
| D:
|
| struct X
| {
|     bool    b[2];
|     int        i;
| }
|
| (Note: we're assuming pre-release modifications, of course. I'm not going to
get
| into _that_ debate.)
|
| Something tells me that this poor soul will be left with a pretty bad taste in
his
| mouth!
|
| In fact, there's an even nastier subtlety to this
|
| Because the default packing of such a structure would have 3 pad bytes between
the
| bool(s) and the int, and because D zero initialises, this might not be
detected
| early, or at all!

I don't see that as a problem: people will have to change many times when converting from C to D.

- C int size is not defined, while it is in D
- C arrays are just pointers, while they're not in D
- D doesn't have "signed" or "unsigned"
- D doesn't have preprocessor
... and I think there're more

Walter and others have said that porting from C to D shouldn't just be a copy-and-paste operation: I agree with that. So if you need C's bool[2] in D, then use byte[2] or whatever other is the matching type.

-----------------------
Carlos Santander Bernal

"Carlos Santander B." <carlos8294@msn.com> wrote in message news:cgjk94$2qb9$1@digitaldaemon.com...
> "Matthew" <admin.hat@stlsoft.dot.org> escribió en el mensaje
> news:cg62d1$ukg$1@digitaldaemon.com
> || In article <cg4sr6$9ur$1@digitaldaemon.com>, Matthew says...
> |||
> ||| Because it would be unpleasantly inconsistent. D is already fragile in so
> far as
> ||| one cannot include C headers into D source. If we then compound this
> disconnect
> ||| by having not only different names for things, but having to match up bit
> ||| variables in D with bitfields in C, it'll just be untenable.
>
> So should D be 100% compatible with C? I don't think that's what you meant, but that's what I can read.
>
> |
> | Asked and answered, old bean. Consider the poor hapless developer who needs to
> | upgrade his struct from
> |
> | C:
> |
> | struct X
> | {
> |     bool    b;
> |     int        i;
> | };
> |
> | D:
> |
> | struct X
> | {
> |     bool    b;
> |     int        i;
> | }
> |
> |
> | to
> |
> | struct X
> | {
> |     bool    b[2];
> |     int        i;
> | };
> |
> | D:
> |
> | struct X
> | {
> |     bool    b[2];
> |     int        i;
> | }
> |
> | (Note: we're assuming pre-release modifications, of course. I'm not going to
> get
> | into _that_ debate.)
> |
> | Something tells me that this poor soul will be left with a pretty bad taste in
> his
> | mouth!
> |
> | In fact, there's an even nastier subtlety to this
> |
> | Because the default packing of such a structure would have 3 pad bytes between
> the
> | bool(s) and the int, and because D zero initialises, this might not be
> detected
> | early, or at all!
>
> I don't see that as a problem: people will have to change many times when converting from C to D.
>
> - C int size is not defined, while it is in D

<pedantic>Wrong. Implementation-defined is quite a different beastie from undefined</pedantic>

> - C arrays are just pointers, while they're not in D

C has pointers. D has pointers.

You're statement appears to address a proposition that C and D are the same somehow, or that do/must have all the same types. I have not made that proposition.

> - D doesn't have "signed" or "unsigned"

Yes it does. They're just not separated into different keywords

> - D doesn't have preprocessor

And your point is ...?

> ... and I think there're more
>
> Walter and others have said that porting from C to D shouldn't just be a copy-and-paste operation: I agree with that. So if you need C's bool[2] in D, then use byte[2] or whatever other is the matching type.

The salient part of my point is that there is one "common" (i.e. common-looking/feeling) type in C and D whose compatibility is warped by the fact that its vector form footprint is not a factor of its scalar footprint. You've not addressed that point at all in your post.

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> escribió en el mensaje
news:cgk46i$209$2@digitaldaemon.com
| "Carlos Santander B." <carlos8294@msn.com> wrote in message
| news:cgjk94$2qb9$1@digitaldaemon.com...
|| I don't see that as a problem: people will have to change many times when
|| converting from C to D.
||
|| - C int size is not defined, while it is in D
|
| <pedantic>Wrong. Implementation-defined is quite a different beastie from
| undefined</pedantic>
|
|| - C arrays are just pointers, while they're not in D
|
| C has pointers. D has pointers.
|
| You're statement appears to address a proposition that C and D are the same
| somehow, or that do/must have all the same types. I have not made that
proposition.
|
|| - D doesn't have "signed" or "unsigned"
|
| Yes it does. They're just not separated into different keywords
|
|| - D doesn't have preprocessor
|
| And your point is ...?
|
|| ... and I think there're more
||
|| Walter and others have said that porting from C to D shouldn't just be a
|| copy-and-paste operation: I agree with that. So if you need C's bool[2] in D,
|| then use byte[2] or whatever other is the matching type.
|
| The salient part of my point is that there is one "common" (i.e.
| common-looking/feeling) type in C and D whose compatibility is warped by the
fact
| that its vector form footprint is not a factor of its scalar footprint. You've
not
| addressed that point at all in your post.

Even with some errors which you pointed and that I accept, my point was that there're many things in D and C that look similar (common, as you say) but are different. Same with D and C++, C#, Java, and maybe others. But that doesn't mean they should behave the same way.

You're a C++ programmer. Maybe once you'll be porting a C++ program to D, and it has something like this:

class Foo
{
    int someVar;
};

It's a small class, but to port it to D and get the same functionality as in C++, you have to change it:

class Foo
{
    private int someVar;
}

It's the same with other things about C++, and things about C, Java, C#...

Maybe I'm not expressing myself in the best way, but what I mean is that changes will always have to be made. People will have to know that D does things differently. It's like what other folks have been talking about the char type: it's not the same as C's char. Do we change it? No: we tell people it's not the same, so they have to think first if that's the right type. It's the same with bool arrays (which happen to be bit arrays).

IMHO.

-----------------------
Carlos Santander Bernal