digitalmars.D - Enums, typedefs and lowest common denominators
- Stewart Gordon (67/67) Nov 27 2006 http://www.digitalmars.com/d/type.html
- Dave (5/16) Nov 27 2006 Take a look at http://d.puremagic.com/issues/show_bug.cgi?id=605
- Sean Kelly (9/25) Nov 27 2006 This appears related to the bug report I just submitted:
http://www.digitalmars.com/d/type.html typedef, the result is the base type. then the result is that base type." Something's puzzling here. I first noticed a problem when the SDWF example program MDI Edit stopped compiling. For the record, the error is: ---------- mdiedit.d(284): function smjg.libs.sdwf.windowbase.WindowBase.style () does not match parameter types (uint) mdiedit.d(284): Error: cannot implicitly convert expression (((cast(WindowBase)(this.editBox)).style)() | cast(ES)cast(WS)256u) of type uint to WS ---------- This appears to be due to promotion rules that have been in place for a while, but the problem with this code has only just manifested in the light of the fix to bug 349. http://d.puremagic.com/issues/show_bug.cgi?id=349 Anyway, back to the point. It would appear that by "base type" the spec means the built-in (or class or struct or union) type from which the typedef is ultimately derived. This spec doesn't mention anything about enums, but the compiler seems to be treating enums and typedefs as a single entity in this respect. For example: ---------- import std.stdio; typedef uint EnumBase; enum Enum1 : EnumBase { Value1, Value2 } enum Enum2 : EnumBase { Value3, Value4 } void test(EnumBase e) { writefln("EnumBase: %d", e); } void test(uint e) { writefln("uint: %d", e); } void main() { test(Enum1.Value1 | Enum2.Value4); } ---------- shows that the enum values are promoted to uint, which is the ultimate base type of both enums, as passing through both enums and typedefs. When I suggested OUAT how typedef arithmetic should work, I intended typedefs with a common base type to promote to the lowest common denominator, i.e. the most-derived typedef that is a common base to both. It would make sense to apply this logic also to enums, and even to chains of typedefs and enums. But the spec certainly has holes here. Firstly, it ought to clarify what is meant by "base type"; secondly, it needs to mention what happens to enums in the same circumstance. Under the lowest common denominator principle, my code would compile without trouble. But for as long as they are always promoted to the _ultimate_ base type if at all, it's hard to make these hierarchical enums work properly and keep SDWF user-friendly to this degree. It's nice if people can still use editBox.style = editBox.style | ES.NOHIDESEL; rather than editBox.style = cast(WS) (editBox.style | ES.NOHIDESEL); Comments? Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Nov 27 2006
Stewart Gordon wrote:Something's puzzling here. I first noticed a problem when the SDWF example program MDI Edit stopped compiling. For the record, the error is: ---------- mdiedit.d(284): function smjg.libs.sdwf.windowbase.WindowBase.style () does not match parameter types (uint) mdiedit.d(284): Error: cannot implicitly convert expression (((cast(WindowBase)(this.editBox)).style)() | cast(ES)cast(WS)256u) of type uint to WS ----------Take a look at http://d.puremagic.com/issues/show_bug.cgi?id=605 In the sample code, if the definition to struct sockaddr_in is commented out, all seems to work fine w/o a cast. Hopefully that will localize the bug enough for Walter to determine the cause.
Nov 27 2006
Stewart Gordon wrote:http://www.digitalmars.com/d/type.html typedef, the result is the base type. then the result is that base type."...This appears to be due to promotion rules that have been in place for a while, but the problem with this code has only just manifested in the light of the fix to bug 349. http://d.puremagic.com/issues/show_bug.cgi?id=349This appears related to the bug report I just submitted: http://d.puremagic.com/issues/show_bug.cgi?id=580Anyway, back to the point. It would appear that by "base type" the spec means the built-in (or class or struct or union) type from which the typedef is ultimately derived. This spec doesn't mention anything about enums, but the compiler seems to be treating enums and typedefs as a single entity in this respect.I think this changed at some point. The code in which I found the bug reported in 580 worked fine until a few months ago. I made a temporary change to work around the problem and forgot to report it, and the behavior persists in 175. Sean
Nov 27 2006