August 21, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | "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. |
August 21, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander B. | "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. |
August 21, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "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. |
August 21, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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. > > |
August 22, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | "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 |
August 22, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | 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 |
August 22, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane 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). |
August 26, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | "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 |
August 26, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander B. | "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. |
August 26, 2004 Re: bit fields in structs | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matthew | "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 |
Copyright © 1999-2021 by the D Language Foundation