August 21, 2004 Re: Bitfields | ||||
---|---|---|---|---|
| ||||
Posted in reply to nail | On Fri, 20 Aug 2004 13:13:20 +0000 (UTC), nail <nail_member@pathlink.com> wrote: >> bar(1); //cannot implicitly convert expression 1 of type int to A >> bar(1|A.AA); //cannot implicitly convert expression 1 | cast(A)1 of >> type int to A >> bar(B.BB|A.AA); //cannot implicitly convert expression cast(B)4 | cast(A)1 >> of type B to A >> bar(A.AA|1); //ok >> bar(A.AA|B.BB); //ok >> >> it appears | causes each operand to be converted to 'int' then the result >> is converted back to the first operands type. So the following: >> >> bar(A.AA|<anything that can implicitly be converted to int>); >> >> will work. Walter can tell us for sure. >> > > I'm not sure, that this behaviour of compiler is the best case. First: how can I > in a language with strong types use combination of different types?! There are degrees of "strong" in D's case, it's not that strongly typed. > No mater > that implicitly they are integers. I even can't understand how I can use > combination of constants of one type while function accepts value of enumerated, > enum(!), enumeration(!), case value(!), one value(!) in other words. Enum's can take a base type eg. enum A : ubyte {A} But Enums *must* be integral types you cannot say: enum A : double {A} As they are all integral types you can implicitly convert them. It does still check things like.. enum A : ubyte {A} enum B : {A} void foo(A a){} void main() { foo(A.A|B.A); } test4.d(8): function foo (A a) does not match argument types (int) test4.d(8): cannot implicitly convert expression cast(int)(0) | cast(B)0 of type int to A > Predecoration looks little ugly. I prefer use <enum value> instead of <enum > type> enum value. IMHO the best case for D if the following code will compile as > expected in comments: > > enum Color > { > RED = 1, > GREEN = 2, > ORANGE = 4, > } > > enum Fruit > { > ORANGE = 1, > APPLE = 8, > } > > void xxx(Color color) {...} > void yyy(bitfield Color colors) {...} > void zzz(Fruit f) {...} > > void main() > { > xxx(RED); // ok. > xxx(RED | GREEN); // error: bitfield not accepted > xxx(ORANGE); // ok. Value 4 (not 1) used > > yyy(RED | ORANGE); // ok. Value 4 for ORANGE used > yyy(RED | APPLE); // error: APPLE not fount in Color enum > > zzz(ORANGE); // ok. Value 1 (not 4) used > } See my other thread entitled 'Enums are annoyingly verbose'. I think some times the 'decoration' is superfluous, there are several occasions when it is not however. (the other thread has some examples) Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
August 21, 2004 Re: Bitfields | ||||
---|---|---|---|---|
| ||||
Posted in reply to Arcane Jill | "Arcane Jill" <Arcane_member@pathlink.com> escribió en el mensaje news:cg5jte$m33$1@digitaldaemon.com | In article <cg54eu$e1t$1@digitaldaemon.com>, nail says... | || It can be not power of two. | | Good point. That's more like the old struct { int x : n }; objects you got in C. | But in the D overview, Walter lists among the things to drop: "Bit fields of | arbitrary size. Bit fields are a complex, inefficient feature rarely used." So | that takes us back to ANDing and ORing constants together, which is back where | we started. | | ||| # (xxx[Color.RED] || xxx[Color.BLUE]) ||| ||| Will that not do? || || This is not type safe | | You'll get no argument from me there! But then, D is not a typesafe language. If | it were, then bool, int, char and enum would not be mutually implicitly | convertible. | | || and bulky | | I've never been particularly bothered by that. Still, I'm quite happy to accept | syntactic sugar so long as things stay readable. | | Arcane Jill IMHO, the way Delphi deals with it is better: they're not enums, they're sets. So you don't check if a certaing bit is set, but if a certain element is present. They /could/ be implemented as bitfields, but for the user they look like sets. IMHO ----------------------- Carlos Santander Bernal |
August 21, 2004 Re: Bitfields | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander B. | In article <cg6dun$145f$1@digitaldaemon.com>, Carlos Santander B. says... >IMHO, the way Delphi deals with it is better: they're not enums, they're sets. So you don't check if a certaing bit is set, but if a certain element is present. They /could/ be implemented as bitfields, but for the user they look like sets. IMHO Yop. Maybe this is most elegant and perfect way >----------------------- >Carlos Santander Bernal > > |
August 21, 2004 Re: Bitfields | ||||
---|---|---|---|---|
| ||||
Posted in reply to nail | In article <cg1id4$lou$1@digitaldaemon.com>, nail says... > >What about integrated bitfields in D? I guess you could use C functions underneath to do the bitfield stuff. Of course that adds overhead. |
Copyright © 1999-2021 by the D Language Foundation