digitalmars.D - A method for enum2str conversions. Reactions?
- Matthew (146/146) Mar 09 2005 Just thought I'd share what I came up with for the enum => string stuff,...
- Andrew Fedoniouk (6/147) Mar 09 2005 Matthew, could you attach this as d source file?
- Matthew (137/334) Mar 09 2005 No worries
- Andrew Fedoniouk (23/208) Mar 09 2005 Thanks a lot,
- Kris (5/216) Mar 09 2005 Why not push to get the enum-names exposed via reflection instead? I wou...
- Andrew Fedoniouk (10/260) Mar 09 2005 Hi, Kris,
- Paul Bonser (29/30) Mar 10 2005 Embedded Scripting, I'd imagine.
- Paul Bonser (9/44) Mar 10 2005 Well, I should say that I would probably write a script or program or
- Andrew Fedoniouk (11/42) Mar 10 2005 I would agree if your Script will share same basic constructions
- pragma (17/23) Mar 10 2005 AFAIK: the goal of getting an enum's name is really just a form of a "le...
- kris (10/284) Mar 10 2005 Hey Andrew;
- Matthew (15/315) Mar 10 2005 It's that, in Open-RJ, two of the three enums are error codes. In the C
- Kris (8/35) Mar 10 2005 If it is so common, then it should be exposed by the compiler via reflec...
- Matthew (2/48) Mar 10 2005
- Kris (10/24) Mar 10 2005 So how about it? What do folks think about a compiler-option to retain &...
- Matthew (10/43) Mar 10 2005 I'm certainly keen to here:
- pragma (18/43) Mar 10 2005 I'll bite. :)
- Sean Kelly (7/33) Mar 11 2005 Some reflection is better than no reflection IMO. And were I to use suc...
- Matthew (8/272) Mar 10 2005 That's what I wanted, and proposed some days ago. The code I've manually...
- Andrew Fedoniouk (18/18) Mar 09 2005 enum E {
- Matthew (15/32) Mar 10 2005 It's going to use more memory, though it's only a bit.
- Andrew Fedoniouk (28/63) Mar 10 2005 Yes, it is. See below.
- Matthew (30/43) Mar 10 2005 Agreed. The only way it'd be 'default' would be if one provided strings
- Jason Mills (4/10) Mar 10 2005 Maybe D should have enums that are Java-like. See
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (8/10) Mar 10 2005 You mean classes ? But if strings and arrays are not classes in D,
Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was successful" } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation failed" } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line tion" } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 09 2005
Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line tion" } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 09 2005
No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...begin 666 enum2str.d M+RH +R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\-"B J(%-T<G5C M"GL-"B ("!I;G0 (" ('9A;'5E.PT*(" (&-H87);72 <W1R.PT*?3L- M" T*<')I=F%T92!T96UP;&%T92!E;G5M7W1O7W-T<FEN9RA4*0T*>PT*(" M(&-H87);72!E;G5M7W1O7W-T<FEN9RA%;G5M4W1R:6YG6UT <W1R:6YG<RP M5"!T*0T*(" ('L-"B (" (" +R\ )T]P=&EM:7-E9"< <V5A<F-H+ T* M(" (" (" O+PT*(" (" (" O+R!3:6YC92!M86YY(&5N=6US('-T87)T M90T*(" (" (" O+R!L:6ME;'D =&AA="!T:&4 =F%L=64 =VEL;"!E<75A M("\O(')E='5R;B!T:&4 <W1R:6YG(&9R;VT =&AA="!I;F1E>"X-"B (" M(" :6YT(&EN9&5X(" /2 (&-A<W0H:6YT*2AT*3L-" T*(" (" ("!I M9B :6YD97 /CT ," F) T*(" (" (" (" :6YD97 /"!S=')I;F=S M+FQE;F=T:" F) T*(" (" (" (" <W1R:6YG<UMI;F1E>%TN=F%L=64 M(" ("!I9BAC87-T*&EN="DH="D /3T <RYV86QU92D-"B (" (" (" M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O M;6]D97)A=&4 =&AE(&-R96%T:6]N(&]F($1A=&%B87-E<R J+PT*<'5B;&EC M(&5N=6T 3U)*7T9,04<-"GL-"B (" (" 3U)$15)?1DE%3$13(" (" M:65L9', :6X 86QP:&%B971I8V%L(&]R9&5R(" (" (" (" (" (" M;F]R960 (" (" (" (" (" (" (" (" *B\-"GT-" T*<'5B;&EC M(&-H87);72!T;U-T<FEN9RA/4DI?1DQ!1R!F*0T*>PT*(" (&-O;G-T($5N M=6U3=')I;F< (" <W1R:6YG<UM=(#T M>R ($]22E]&3$%'+D]21$527T9)14Q$4RP (" (" (" (")!<G)A;F=E M<R!T:&4 9FEE;&1S(&EN(&%L<&AA8F5T:6-A;"!O<F1E<B( ?0T*(" (" M875S97, 8FQA;FL <F5C;W)D<R!T;R!B92!I9VYO<F5D(B (" (" ?0T* M*2AS=')I;F=S+"!F*3L-"GT-" T*+RHJ($=E;F5R86P 97)R;W( 8V]D97, M;VX =V%S('-U8V-E<W-F=6P (" (" (" (" (" (" (" (" (" M(" (" (" (" (" (" +RHA/"!4:&4 9VEV96X 9FEL92!D;V5S(&YO M+" ($Y/7U)%0T]21%, (" (" (" (" (" (" (" (" (" (" M(" +RHA/"!4:&4 9&%T86)A<V4 9FEL92!C;VYT86EN960 ;F\ <F5C;W)D M4ED (" (" (" (" (" (" (" (" (" (" +RHA/"!4:&4 05!) M('-U9F9E<F5D(&UE;6]R>2!E>&AA=7-T:6]N(" (" (" (" (" (" M(" (" (" (" (" (" +RHA/"!!(')E860 ;W!E<F%T:6]N(&9A:6QE M+" (%!!4E-%7T524D]2(" (" (" (" (" (" (" (" (" (" M(" +RHA/"!087)S:6YG(&]F('1H92!D871A8F%S92!F:6QE(&9A:6QE9"!D M15 (" (" (" (" (" (" (" (" (" (" +RHA/"!!;B!I;G9A M;&ED(&EN9&5X('=A<R!S<&5C:69I960 (" (" (" (" (" (" (" M(" (" (" (" (" (" +RHA/"!!;B!U;F5X<&5C=&5D(&-O;F1I=&EO M+" ($E.5D%,241?0T].5$5.5" (" (" (" (" (" (" (" (" M(" +RHA/"!4:&4 9&%T86)A<V4 9FEL92!C;VYT86EN960 :6YV86QI9"!C M=&]3=')I;F<H3U)*4D, 9BD-"GL-"B ("!C;VYS="!%;G5M4W1R:6YG(" M('-T<FEN9W-;72 ]( T*(" (%L-"B (" (" (" ('L ("!/4DI20RY3 M;"( (" (" (" (" (" (" (" (" (" (" (" (" ('T-"B M92!G:79E;B!F:6QE(&1O97, ;F]T(&5X:7-T+"!O<B!C86YN;W0 8F4 86-C M97-S960B(" (" (" ('T-"B (" (" +" ('L ("!/4DI20RY.3U]2 M14-/4D13+" (" (" (" (E1H92!D871A8F%S92!F:6QE(&-O;G1A:6YE M9"!N;R!R96-O<F1S(B (" (" (" (" (" (" (" ('T-"B (" M(" +" ('L ("!/4DI20RY/551?3T9?345-3U)9+" (" (" (E1H92!! M4$D <W5F9F5R960 ;65M;W)Y(&5X:&%U<W1I;VXB(" (" (" (" (" M(" (" (" (" ('T-"B (" (" +" ('L ("!/4DI20RY"041?1DE, M15]214%$+" (" (" (D$ <F5A9"!O<&5R871I;VX 9F%I;&5D(B (" M(" (" (" (" (" (" (" (" (" (" (" ('T-"B (" (" M+" ('L ("!/4DI20RY005)315]%4E)/4BP (" (" (" (E!A<G-I;F< M;V8 =&AE(&1A=&%B87-E(&9I;&4 9F%I;&5D(&1U92!T;R!A('-Y;G1A>"!E M<G)O<B( (" ('T-"B (" (" +" ('L ("!/4DI20RY)3E9!3$E$7TE. M1$58+" (" (" (D%N(&EN=F%L:60 :6YD97 =V%S('-P96-I9FEE9"( M(" (" (" (" (" (" (" (" (" (" ('T-"B (" (" +" M960 8V]N9&ET:6]N('=A<R!E;F-O=6YT97)E9"( (" (" (" (" (" M(" (" ('T (" -"B (" (" +" ('L ("!/4DI20RY)3E9!3$E$7T-/ M3E1%3E0L(" (" (E1H92!D871A8F%S92!F:6QE(&-O;G1A:6YE9"!I;G9A M73L-" T*(" (')E='5R;B!E;G5M7W1O7W-T<FEN9R$H3U)*4D,I*'-T<FEN M:6YG('=A<R!S=6-C97-S9G5L(" (" (" (" (" (" (" (" (" M($$ <F5C;W)D('-E<&%R871O<B!W87, 96YC;W5N=&5R960 9'5R:6YG(&$ M8V]N=&5N="!L:6YE(&-O;G1I;G5A=&EO;B (" (" (" J+PT*(" ("P M("!53D9)3DE32$5$7TQ)3D4 (" (" (" (" (" (" (" (" (" M("\J(3P 5&AE(&QA<W0 ;&EN92!I;B!T:&4 9&%T86)A<V4 =V%S(&YO="!T M(" +" (%5.1DE.25-(141?1DE%3$0 (" (" (" (" (" (" (" M(" (" +RHA/"!4:&4 ;&%S="!F:65L9"!I;B!T:&4 9&%T86)A<V4 9FEL M92!W87, ;F]T('1E<FUI;F%T960 8GD 82!R96-O<F0 <V5P87)A=&]R(" M*B\-"B (" L(" 54Y&24Y)4TA%1%]214-/4D0 (" (" (" (" (" M(" (" (" (" O*B$\(%1H92!L87-T(')E8V]R9"!I;B!T:&4 9&%T86)A M<V4 9FEL92!W87, ;F]T('1E<FUI;F%T960 8GD 82!R96-O<F0 <V5P87)A M15]%4E)/4B!F*0T*>PT*(" (&-O;G-T($5N=6U3=')I;F< (" <W1R:6YG M<UM=(#T M9R!W87, <W5C8V5S<V9U;"( (" (" (" (" (" (" (" (" (" M(" (" (" (" (" (" (" (" (" ('T-"B (" (" +" ('L M051)3TXL(" (D$ <F5C;W)D('-E<&%R871O<B!W87, 96YC;W5N=&5R960 M9'5R:6YG(&$ 8V]N=&5N="!L:6YE(&-O;G1I;G5A=&EO;B( (" (" ("!] M3$E.12P (" (" (" (" (" (" (")4:&4 ;&%S="!L:6YE(&EN('1H M92!D871A8F%S92!W87, ;F]T('1E<FUI;F%T960 8GD 82!L:6YE+69E960B M(" (" (" (" (" ?0T*(" (" (" L(" >R ($]22E]005)315]% M4E)/4BY53D9)3DE32$5$7T9)14Q$+" (" (" (" (" (" (" B5&AE M(&QA<W0 9FEE;&0 :6X =&AE(&1A=&%B87-E(&9I;&4 =V%S(&YO="!T97)M M:6YA=&5D(&)Y(&$ <F5C;W)D('-E<&%R871O<B( ('T-"B (" (" +" M('L ("!/4DI?4$%24T5?15)23U(N54Y&24Y)4TA%1%]214-/4D0L(" (" M(" (" (" (" (E1H92!L87-T(')E8V]R9"!I;B!T:&4 9&%T86)A<V4 M9FEL92!W87, ;F]T('1E<FUI;F%T960 8GD 82!R96-O<F0 <V5P87)A=&]R M7U!!4E-%7T524D]2*2AS=')I;F=S+"!F*3L-"GT-" T*+RH +R\O+R\O+R\O M+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O+R\O 9+R\O+R\O+R\O+R\O+R\O+R\O+R\ *B\-" `` ` endJust thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 09 2005
Thanks a lot, What about this: enum E { ZERO, ONE, TWO } char[] toString(E e) { static char[][] map = [ E.ZERO :"primordial", E.ONE :"first", E.TWO :"second" ]; return map[e]; } for simple continuous enums? Anyway enums which are sets of bits (0x01,0x02, 0x04...) in fact need different toString implementation (string composition) Andrew. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0omiq$19o7$1 digitaldaemon.com...No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 09 2005
Why not push to get the enum-names exposed via reflection instead? I wouldn't wish to have to re-type them all over again, in a different manner. Doesn't make sense. - Kris In article <d0onfb$1afp$1 digitaldaemon.com>, Andrew Fedoniouk says...Thanks a lot, What about this: enum E { ZERO, ONE, TWO } char[] toString(E e) { static char[][] map = [ E.ZERO :"primordial", E.ONE :"first", E.TWO :"second" ]; return map[e]; } for simple continuous enums? Anyway enums which are sets of bits (0x01,0x02, 0x04...) in fact need different toString implementation (string composition) Andrew. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0omiq$19o7$1 digitaldaemon.com...No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 09 2005
Hi, Kris, Ideally these Enum strings should come in different languages. Right? So reflection will not help you here. Reflection might help in other places but not too much. I can see only couple areas where it may help: persistent storages/OODB, and SOAP alike use cases. Does anybody know other areas where reflection is desirable? Andrew. "Kris" <Kris_member pathlink.com> wrote in message news:d0op0e$1bnh$1 digitaldaemon.com...Why not push to get the enum-names exposed via reflection instead? I wouldn't wish to have to re-type them all over again, in a different manner. Doesn't make sense. - Kris In article <d0onfb$1afp$1 digitaldaemon.com>, Andrew Fedoniouk says...Thanks a lot, What about this: enum E { ZERO, ONE, TWO } char[] toString(E e) { static char[][] map = [ E.ZERO :"primordial", E.ONE :"first", E.TWO :"second" ]; return map[e]; } for simple continuous enums? Anyway enums which are sets of bits (0x01,0x02, 0x04...) in fact need different toString implementation (string composition) Andrew. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0omiq$19o7$1 digitaldaemon.com...No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 09 2005
Does anybody know other areas where reflection is desirable?Embedded Scripting, I'd imagine. I'm working on a game engine (in D, of course) and I'm going to want to embed a scripting language of some sort into it (haven't decided what to use yet, but I really want something that is bytecode-compiled...but that's another topic). It would be really handy to be able to call any function (and access any variable) I wanted from a script, without having to manually add a hook for each function I wanted to call or variable I wanted to access. Just add a couple of functions that look up the name you gave, call it if it's there, give an error if it isn't. It would make the scripting language better integrated into the program, without all the extra coding of doing it manually. Also, I'd like to be able to pop up a scripting console in-game (for when I'm developing it, at least..) and instantiate objects of various types and call functions wilily-nilly, as well as modifying objects and such that already exist. (again, without having to manually tell the scripting language about each and every data type that's out there.) Oh it would make me so happy to be able to do that. I believe it is also good for debugging and adding class-browsers and did I mention scripting? :P So I guess until reflection is made part of the language (or something) I'll have to just do a "sorta" reflection by making every class a subclass of a Reflection class and have to keep an associative array of all the function names and variable names with delegates and pointers and...blah, that's what I want to not have to do :( -- -PIB -- "C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch
Mar 10 2005
Paul Bonser wrote:Well, I should say that I would probably write a script or program or whatnot to filter my files and add all this "artificial reflection" in for me. But again, I'd much rather not have to do this... -- -PIB -- "C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady BoochDoes anybody know other areas where reflection is desirable?Embedded Scripting, I'd imagine. I'm working on a game engine (in D, of course) and I'm going to want to embed a scripting language of some sort into it (haven't decided what to use yet, but I really want something that is bytecode-compiled...but that's another topic). It would be really handy to be able to call any function (and access any variable) I wanted from a script, without having to manually add a hook for each function I wanted to call or variable I wanted to access. Just add a couple of functions that look up the name you gave, call it if it's there, give an error if it isn't. It would make the scripting language better integrated into the program, without all the extra coding of doing it manually. Also, I'd like to be able to pop up a scripting console in-game (for when I'm developing it, at least..) and instantiate objects of various types and call functions wilily-nilly, as well as modifying objects and such that already exist. (again, without having to manually tell the scripting language about each and every data type that's out there.) Oh it would make me so happy to be able to do that. I believe it is also good for debugging and adding class-browsers and did I mention scripting? :P So I guess until reflection is made part of the language (or something) I'll have to just do a "sorta" reflection by making every class a subclass of a Reflection class and have to keep an associative array of all the function names and variable names with delegates and pointers and...blah, that's what I want to not have to do :(
Mar 10 2005
Embedded Scripting, I'd imagine.I would agree if your Script will share same basic constructions with D: types, classes, arrays, etc. Anyway it is extremely bad design to allow to script "to see private parts" of host implementation. So you will create an isolation layer. Which will be anyway sort of IDispatch with VARIANT or the like with function table like: delegate value (uint argn, value[] argv) functbl[symbol_t]; Andrew Fedoniouk. http://terrainformatica.com "Paul Bonser" <misterpib gmail.com> wrote in message news:d0p15l$1l13$1 digitaldaemon.com...Does anybody know other areas where reflection is desirable?Embedded Scripting, I'd imagine. I'm working on a game engine (in D, of course) and I'm going to want to embed a scripting language of some sort into it (haven't decided what to use yet, but I really want something that is bytecode-compiled...but that's another topic). It would be really handy to be able to call any function (and access any variable) I wanted from a script, without having to manually add a hook for each function I wanted to call or variable I wanted to access. Just add a couple of functions that look up the name you gave, call it if it's there, give an error if it isn't. It would make the scripting language better integrated into the program, without all the extra coding of doing it manually. Also, I'd like to be able to pop up a scripting console in-game (for when I'm developing it, at least..) and instantiate objects of various types and call functions wilily-nilly, as well as modifying objects and such that already exist. (again, without having to manually tell the scripting language about each and every data type that's out there.) Oh it would make me so happy to be able to do that. I believe it is also good for debugging and adding class-browsers and did I mention scripting? :P So I guess until reflection is made part of the language (or something) I'll have to just do a "sorta" reflection by making every class a subclass of a Reflection class and have to keep an associative array of all the function names and variable names with delegates and pointers and...blah, that's what I want to not have to do :( -- -PIB -- "C++ also supports the notion of *friends*: cooperative classes that are permitted to see each other's private parts." - Grady Booch
Mar 10 2005
In article <d0ossh$1f4t$1 digitaldaemon.com>, Andrew Fedoniouk says...Ideally these Enum strings should come in different languages. Right? So reflection will not help you here. Reflection might help in other places but not too much. I can see only couple areas where it may help: persistent storages/OODB, and SOAP alike use cases. Does anybody know other areas where reflection is desirable?AFAIK: the goal of getting an enum's name is really just a form of a "lexical cast"; something that isn't typically more than just raw reflection. I think the notion here is "locale be damned" and just give up the name of the constant used in the source. As you mentioned, generic persistence via reflection would be a welcome addition. SOAP, RPC, CORBA (et al.) and DLL interop can all benefit hugely from reflection, and is by no means a fringe use of the technology. D could easily be a business language of choice if you had runtime-generated transparent proxies like .NET. As for other areas? A (future) D-specific debugger could make very good use of deeper reflection information. Also, generic programming could benefit greatly from richer runtime (and compile time!) type information. Outside that, it really just lends to the language's flexibility overall which can only help its adoption rate. We really don't want "D.Boost" when we can have all of its capability built-into the D/phobos itself. - EricAnderton at yahoo
Mar 10 2005
Hey Andrew; I figured Matthew was using these enum-names for a non-i18n application only ~ once you start getting into locale-specifics, there's a whole lot more to consider (as I'm sure you know) and the strings themselves would very likely be externalized in one manner or another: making this topic somewhat moot? Of course, this is probably now way-off topic; so I'll mention the ICU tools/APIs once again (WRT this domain) and then shuttup ... - Kris Andrew Fedoniouk wrote:Hi, Kris, Ideally these Enum strings should come in different languages. Right? So reflection will not help you here. Reflection might help in other places but not too much. I can see only couple areas where it may help: persistent storages/OODB, and SOAP alike use cases. Does anybody know other areas where reflection is desirable? Andrew. "Kris" <Kris_member pathlink.com> wrote in message news:d0op0e$1bnh$1 digitaldaemon.com...Why not push to get the enum-names exposed via reflection instead? I wouldn't wish to have to re-type them all over again, in a different manner. Doesn't make sense. - Kris In article <d0onfb$1afp$1 digitaldaemon.com>, Andrew Fedoniouk says...Thanks a lot, What about this: enum E { ZERO, ONE, TWO } char[] toString(E e) { static char[][] map = [ E.ZERO :"primordial", E.ONE :"first", E.TWO :"second" ]; return map[e]; } for simple continuous enums? Anyway enums which are sets of bits (0x01,0x02, 0x04...) in fact need different toString implementation (string composition) Andrew. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0omiq$19o7$1 digitaldaemon.com...No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 10 2005
It's that, in Open-RJ, two of the three enums are error codes. In the C library there's a static array of structs mapping the value to a string. This is a really common idiom, but painfully verbose and also very fragile - it's all too easy to get the Doxygen doc strings out of step with the string literals used in the translation - so I figured that D might address this. I still feel that that's worthwhile. (Note: in C, one can keep it all in the DRY SPOT by using macros, which we, er, cannot do in D. <g>) Of course, this does not address localisation, and I don't suggest it does. It's just a safer shortcut for what we do now anyway. I've been thinking that rather than strings we might also associate string identifiers, which would be hooked into the i18n framework that, as yet, does not exist. ;) "kris" <fu bar.org> wrote in message news:d0ps0h$2fbt$1 digitaldaemon.com...Hey Andrew; I figured Matthew was using these enum-names for a non-i18n application only ~ once you start getting into locale-specifics, there's a whole lot more to consider (as I'm sure you know) and the strings themselves would very likely be externalized in one manner or another: making this topic somewhat moot? Of course, this is probably now way-off topic; so I'll mention the ICU tools/APIs once again (WRT this domain) and then shuttup ... - Kris Andrew Fedoniouk wrote:Hi, Kris, Ideally these Enum strings should come in different languages. Right? So reflection will not help you here. Reflection might help in other places but not too much. I can see only couple areas where it may help: persistent storages/OODB, and SOAP alike use cases. Does anybody know other areas where reflection is desirable? Andrew. "Kris" <Kris_member pathlink.com> wrote in message news:d0op0e$1bnh$1 digitaldaemon.com...Why not push to get the enum-names exposed via reflection instead? I wouldn't wish to have to re-type them all over again, in a different manner. Doesn't make sense. - Kris In article <d0onfb$1afp$1 digitaldaemon.com>, Andrew Fedoniouk says...Thanks a lot, What about this: enum E { ZERO, ONE, TWO } char[] toString(E e) { static char[][] map = [ E.ZERO :"primordial", E.ONE :"first", E.TWO :"second" ]; return map[e]; } for simple continuous enums? Anyway enums which are sets of bits (0x01,0x02, 0x04...) in fact need different toString implementation (string composition) Andrew. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0omiq$19o7$1 digitaldaemon.com...No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 10 2005
In article <d0qish$7hl$1 digitaldaemon.com>, Matthew says...It's that, in Open-RJ, two of the three enums are error codes. In the C library there's a static array of structs mapping the value to a string. This is a really common idiom, but painfully verbose and also very fragile - it's all too easy to get the Doxygen doc strings out of step with the string literals used in the translation - so I figured that D might address this. I still feel that that's worthwhile. (Note: in C, one can keep it all in the DRY SPOT by using macros, which we, er, cannot do in D. <g>)If it is so common, then it should be exposed by the compiler via reflection. That way it would not be fragile, and would stay in that DRY SPOT.Of course, this does not address localisation, and I don't suggest it does. It's just a safer shortcut for what we do now anyway. I've been thinking that rather than strings we might also associate string identifiers, which would be hooked into the i18n framework that, as yet, does not exist. ;)That i18n framework *does* exist. It's called ICU, and it has a slew of tools for producing, configuring, editing, and managing such resources. The best part about ICU is the level of maturity, and the vast sums of money poured into it by IBM et. al. It may not be ideal, but it's a long way down a reasonable path."kris" <fu bar.org> wrote in message news:d0ps0h$2fbt$1 digitaldaemon.com...Hey Andrew; I figured Matthew was using these enum-names for a non-i18n application only ~ once you start getting into locale-specifics, there's a whole lot more to consider (as I'm sure you know) and the strings themselves would very likely be externalized in one manner or another: making this topic somewhat moot? Of course, this is probably now way-off topic; so I'll mention the ICU tools/APIs once again (WRT this domain) and then shuttup ... - Kris
Mar 10 2005
Cool.It's that, in Open-RJ, two of the three enums are error codes. In the C library there's a static array of structs mapping the value to a string. This is a really common idiom, but painfully verbose and also very fragile - it's all too easy to get the Doxygen doc strings out of step with the string literals used in the translation - so I figured that D might address this. I still feel that that's worthwhile. (Note: in C, one can keep it all in the DRY SPOT by using macros, which we, er, cannot do in D. <g>)If it is so common, then it should be exposed by the compiler via reflection. That way it would not be fragile, and would stay in that DRY SPOT.Sorry. I meant like not something in D yet.Of course, this does not address localisation, and I don't suggest it does. It's just a safer shortcut for what we do now anyway. I've been thinking that rather than strings we might also associate string identifiers, which would be hooked into the i18n framework that, as yet, does not exist. ;)That i18n framework *does* exist. It's called ICU, and it has a slew of tools for producing, configuring, editing, and managing such resources. The best part about ICU is the level of maturity, and the vast sums of money poured into it by IBM et. al. It may not be ideal, but it's a long way down a reasonable path."kris" <fu bar.org> wrote in message news:d0ps0h$2fbt$1 digitaldaemon.com...Hey Andrew; I figured Matthew was using these enum-names for a non-i18n application only ~ once you start getting into locale-specifics, there's a whole lot more to consider (as I'm sure you know) and the strings themselves would very likely be externalized in one manner or another: making this topic somewhat moot? Of course, this is probably now way-off topic; so I'll mention the ICU tools/APIs once again (WRT this domain) and then shuttup ... - Kris
Mar 10 2005
In article <d0qrj5$g81$1 digitaldaemon.com>, Matthew says...So how about it? What do folks think about a compiler-option to retain & expose reflection material such as enum-names? It would presumeably be a step along the path of reflection, and probably won't even be seriously considered until after 1.0 ... ? That would appear to be a neat way of providing tags for externalized content, including i18n considerations.If it is so common, then it should be exposed by the compiler via reflection. That way it would not be fragile, and would stay in that DRY SPOT.Cool.Not to be argumentative, but it kinda' is available in D; we've got wrappers for almost all of the ICU APIs :-) Perhaps that's not what you meant ...That i18n framework *does* exist. It's called ICU, and it has a slew of tools for producing, configuring, editing, and managing such resources. The best part about ICU is the level of maturity, and the vast sums of money poured into it by IBM et. al. It may not be ideal, but it's a long way down a reasonable path.Sorry. I meant like not something in D yet.
Mar 10 2005
"Kris" <Kris_member pathlink.com> wrote in message news:d0qvv9$k3q$1 digitaldaemon.com...In article <d0qrj5$g81$1 digitaldaemon.com>, Matthew says...I'm certainly keen to here: - from the group whether this is desirable - from the group whether there might be slight differences from the way I've expressed it that would be preferable - from Walter as to whether this is something that can be readily incorporated into the language.So how about it? What do folks think about a compiler-option to retain & expose reflection material such as enum-names? It would presumeably be a step along the path of reflection, and probably won't even be seriously considered until after 1.0 ... ? That would appear to be a neat way of providing tags for externalized content, including i18n considerations.If it is so common, then it should be exposed by the compiler via reflection. That way it would not be fragile, and would stay in that DRY SPOT.Cool.Kris, I'm largely ignorant of the subject, and, apparently, was purely pontifulating. :-)Not to be argumentative, but it kinda' is available in D; we've got wrappers for almost all of the ICU APIs :-) Perhaps that's not what you meant ...That i18n framework *does* exist. It's called ICU, and it has a slew of tools for producing, configuring, editing, and managing such resources. The best part about ICU is the level of maturity, and the vast sums of money poured into it by IBM et. al. It may not be ideal, but it's a long way down a reasonable path.Sorry. I meant like not something in D yet.
Mar 10 2005
In article <d0r2a1$me8$1 digitaldaemon.com>, Matthew says..."Kris" <Kris_member pathlink.com> wrote in messageI'll bite. :) I think that a full-on reflection system is desireable, but realizing that goal should probably be done as a wholesale design, rather than as a piecemeal set of improvements. I'd like to see us back something really close to the right design the first time round, rather than have to refactor needlessly as we go. As for enums, something transparent likeSo how about it? What do folks think about a compiler-option to retain & expose reflection material such as enum-names? It would presumeably be a step along the path of reflection, and probably won't even be seriously considered until after 1.0 ... ? That would appear to be a neat way of providing tags for externalized content, including i18n considerations.I'm certainly keen to here: - from the group whether this is desirable - from the group whether there might be slight differences from the way I've expressed it that would be preferableenum Test{ FOO,BAR,GORF }; Test t = FOO; char[] name = typeid(Test).getValueName(t); char[] name2 = t.typeinfo.getValueName(t); // equivalentI would like to void *against* any idea for the following c++ boost-ism:char[] name = lexical_cast!(char[])(t);.. we can do better than that. As for a compiler option, I think that's a moot point. If someone is going to write code that's "lean and mean", why wouldn't they just write procedural code and leave it at that? After all, if you don't use any user-defined types, then the only typeinfo instances added to the app are for your scalar and array types. Classes already present overhead in the form of type information and v-tables already, so the needed metadata to fully support a complete reflection system probably won't bloat things too much. - EricAnderton at yahoo
Mar 10 2005
In article <d0r2a1$me8$1 digitaldaemon.com>, Matthew says..."Kris" <Kris_member pathlink.com> wrote in message news:d0qvv9$k3q$1 digitaldaemon.com...Some reflection is better than no reflection IMO. And were I to use such a feature, it would have to be built into the compiler or at least supplied with a standard compiler package.So how about it? What do folks think about a compiler-option to retain & expose reflection material such as enum-names? It would presumeably be a step along the path of reflection, and probably won't even be seriously considered until after 1.0 ... ? That would appear to be a neat way of providing tags for externalized content, including i18n considerations.I'm certainly keen to here: - from the group whether this is desirable - from the group whether there might be slight differences from the way I've expressed it that would be preferable - from Walter as to whether this is something that can be readily incorporated into the language.Kris picked up the ball when Jill disappeared and did much of the work himself. It's over at dsource :) SeanNot to be argumentative, but it kinda' is available in D; we've got wrappers for almost all of the ICU APIs :-) Perhaps that's not what you meant ...Kris, I'm largely ignorant of the subject, and, apparently, was purely pontifulating. :-)
Mar 11 2005
That's what I wanted, and proposed some days ago. The code I've manually provided is what I hope would be built in to the compiler. It's efficient - I bet more efficient than any based on AAs, esp. given the value==index optimisation - and does not do any runtime allocation. If the compiler simply did that for us - with expanded syntax for the strings (or string ids!!) - I think it'd be great. "Kris" <Kris_member pathlink.com> wrote in message news:d0op0e$1bnh$1 digitaldaemon.com...Why not push to get the enum-names exposed via reflection instead? I wouldn't wish to have to re-type them all over again, in a different manner. Doesn't make sense. - Kris In article <d0onfb$1afp$1 digitaldaemon.com>, Andrew Fedoniouk says...Thanks a lot, What about this: enum E { ZERO, ONE, TWO } char[] toString(E e) { static char[][] map = [ E.ZERO :"primordial", E.ONE :"first", E.TWO :"second" ]; return map[e]; } for simple continuous enums? Anyway enums which are sets of bits (0x01,0x02, 0x04...) in fact need different toString implementation (string composition) Andrew. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0omiq$19o7$1 digitaldaemon.com...No worries "Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0ollq$17ud$1 digitaldaemon.com...Matthew, could you attach this as d source file? Beg my pardon, but it is hardly readable. Thanks in advance, Andrew Fedoniouk. "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0oiuc$13r3$1 digitaldaemon.com...Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.) Let me know what you think. private struct EnumString { int value; char[] str; }; private template enum_to_string(T) { char[] enum_to_string(EnumString[] strings, T t) { // 'Optimised' search. // // Since many enums start at 0 and are contiguously ordered, it's quite // likely that the value will equal the index. If it does, we can just // return the string from that index. int index = cast(int)(t); if( index >= 0 && index < strings.length && strings[index].value == index) { return strings[index].str; } // Otherwise, just do a linear search foreach(EnumString s; strings) { if(cast(int)(t) == s.value) { return s.str; } } return "<unknown>"; } } /* ///////////////////////////////////////////////////////////////////////////// * Enumerations */ /** Flags that moderate the creation of Databases */ public enum ORJ_FLAG { ORDER_FIELDS = 0x0001 /*!< Arranges the fields in alphabetical order */ , ELIDE_BLANK_RECORDS = 0x0002 /*!< Causes blank records to be ignored */ } public char[] toString(ORJ_FLAG f) { const EnumString strings[] = [ { ORJ_FLAG.ORDER_FIELDS, "Arranges the fields in alphabetical order" } , { ORJ_FLAG.ELIDE_BLANK_RECORDS, "Causes blank records to be ignored" } ]; return enum_to_string!(ORJ_FLAG)(strings, f); } /** General error codes */ public enum ORJRC { SUCCESS = 0 /*!< Operation was successful */ , CANNOT_OPEN_JAR_FILE /*!< The given file does not exist, or cannot be accessed */ , NO_RECORDS /*!< The database file contained no records */ , OUT_OF_MEMORY /*!< The API suffered memory exhaustion */ , BAD_FILE_READ /*!< A read operation failed */ , PARSE_ERROR /*!< Parsing of the database file failed due to a syntax error */ , INVALID_INDEX /*!< An invalid index was specified */ , UNEXPECTED /*!< An unexpected condition was encountered */ , INVALID_CONTENT /*!< The database file contained invalid content */ } public char[] toString(ORJRC f) { const EnumString strings[] = [ { ORJRC.SUCCESS, "Operation was } , { ORJRC.CANNOT_OPEN_JAR_FILE, "The given file does not exist, or cannot be accessed" } , { ORJRC.NO_RECORDS, "The database file contained no records" } , { ORJRC.OUT_OF_MEMORY, "The API suffered memory exhaustion" } , { ORJRC.BAD_FILE_READ, "A read operation } , { ORJRC.PARSE_ERROR, "Parsing of the database file failed due to a syntax error" } , { ORJRC.INVALID_INDEX, "An invalid index was specified" } , { ORJRC.UNEXPECTED, "An unexpected condition was encountered" } , { ORJRC.INVALID_CONTENT, "The database file contained invalid content" } ]; return enum_to_string!(ORJRC)(strings, f); } /** Parsing error codes */ public enum ORJ_PARSE_ERROR { SUCCESS = 0 /*!< Parsing was successful */ , RECORD_SEPARATOR_IN_CONTINUATION /*!< A record separator was encountered during a content line continuation */ , UNFINISHED_LINE /*!< The last line in the database was not terminated by a line-feed */ , UNFINISHED_FIELD /*!< The last field in the database file was not terminated by a record separator */ , UNFINISHED_RECORD /*!< The last record in the database file was not terminated by a record separator */ } public char[] toString(ORJ_PARSE_ERROR f) { const EnumString strings[] = [ { ORJ_PARSE_ERROR.SUCCESS, "Parsing was } , { ORJ_PARSE_ERROR.RECORD_SEPARATOR_IN_CONTINUATION, "A record separator was encountered during a content line } , { ORJ_PARSE_ERROR.UNFINISHED_LINE, "The last line in the database was not terminated by a } , { ORJ_PARSE_ERROR.UNFINISHED_FIELD, "The last field in the database file was not terminated by a record separator" } , { ORJ_PARSE_ERROR.UNFINISHED_RECORD, "The last record in the database file was not terminated by a record separator" } ]; return enum_to_string!(ORJ_PARSE_ERROR)(strings, f); }
Mar 10 2005
enum E { FIRST = 0x01, SECOND = 0x02 , THIRD = 0x04 } alias char[] string8; string8 toString(E e) { static string8[int] map; if(!map.length) { map[E.FIRST] = "first"; map[E.SECOND] = "second"; map[E.THIRD] = "third one"; } return map[e]; } Huh? Andrew.
Mar 09 2005
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0oodt$1ba0$1 digitaldaemon.com...enum E { FIRST = 0x01, SECOND = 0x02 , THIRD = 0x04 } alias char[] string8; string8 toString(E e) { static string8[int] map; if(!map.length) { map[E.FIRST] = "first"; map[E.SECOND] = "second"; map[E.THIRD] = "third one"; } return map[e]; } Huh?It's going to use more memory, though it's only a bit. It allocates memory at runtime, with the consequent, though unlikely, possibility of being out of memory It's going to run slower, though it's only a bit. Linear searches are generally more efficient for small data sets, which most enums are. It doesn't optimise for the common case where an enum value is equal to its index. It doesn't handle the case where the value is unrecognised, though that could be added by using some horrible 'in' construction. All these are small matters, to be sure, but are persuasive, at least to me. Please note: the solution I gave is what I would hope would become built-in. In that case it's only drawback, its verbosity, would be moot.
Mar 10 2005
"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message news:d0p18e$1l2q$1 digitaldaemon.com..."Andrew Fedoniouk" <news terrainformatica.com> wrote in message news:d0oodt$1ba0$1 digitaldaemon.com...Yes, it is. See below.enum E { FIRST = 0x01, SECOND = 0x02 , THIRD = 0x04 } alias char[] string8; string8 toString(E e) { static string8[int] map; if(!map.length) { map[E.FIRST] = "first"; map[E.SECOND] = "second"; map[E.THIRD] = "third one"; } return map[e]; } Huh?It's going to use more memory, though it's only a bit. It allocates memory at runtime, with the consequent, though unlikely, possibility of being out of memoryIt's going to run slower, though it's only a bit. Linear searches are generally more efficient for small data sets, which most enums are.Well, it depends on implementation of assoc. map in D. It could be an adaptive hash map which is either simple list if number of items is less than threshold and a real hasmap otherwise. But in D as far as I can see assosiative arrays made as lookup binary trees. So they are not so much expensive for small sets - but not so effective on big sets - reasonable compromise for built-ins. For small sets D's AA is close to linear search,It doesn't optimise for the common case where an enum value is equal to its index.Yes, but I've provided another implementation for "consequent" enums.It doesn't handle the case where the value is unrecognised, though that could be added by using some horrible 'in' construction.Life is life.All these are small matters, to be sure, but are persuasive, at least to me. Please note: the solution I gave is what I would hope would become built-in. In that case it's only drawback, its verbosity, would be moot.Built-in.... Do you mean they will be implemented inside D compiler/runtime by default? If yes this is absolutely another case. 1) I don't want *all* enums to be "stringizeable" this way. 2) I would like to be able to define different string sets for different locales for the same enum. For me personally it would be enough to have hash map static initializers - static hash maps. They can be implenmented using (Minimal) Perfect Hash similar to what gnu::gperf.exe does - this is not the must but desirable. int[char[]] m = { "one":1, "two":2 } char[][int] m = { 1:"one", 2: "two" }
Mar 10 2005
Built-in.... Do you mean they will be implemented inside D compiler/runtime by default? If yes this is absolutely another case.That's what I'd like, as a default1) I don't want *all* enums to be "stringizeable" this way.That'd be easy. Just don't provide any strings! :-)2) I would like to be able to define different string sets for different locales for the same enum.Agreed. The only way it'd be 'default' would be if one provided strings within the definition, as in: enum E1 { val1 : "This represents something" , val2 : "This represents something else" } enum E2 { val3 , val4 } enum E3 { val5 , val6 } char[] toString(E3 e); // Your localisation-aware implementation E1 e1 = E1.val1; E2 e2 = E2.val4; E3 e3 = E3.val5; char[] s1 = toString(e1); // This would use the compiler generated version, with the same impl as I've provided explicitly char[] s2 = toString(e2); // This would be a compilation error, since E2 does not have one provided char[] s3 = toString(e3); // Calls the explicitly provided functionFor me personally it would be enough to have hash map static initializers - static hash maps. They can be implenmented using (Minimal) Perfect Hash similar to what gnu::gperf.exe does - this is not the must but desirable. int[char[]] m = { "one":1, "two":2 } char[][int] m = { 1:"one", 2: "two" }I think that's a separate issue, but I agree we should be able to have them
Mar 10 2005
Maybe D should have enums that are Java-like. See http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.html Jason Matthew wrote:Just thought I'd share what I came up with for the enum => string stuff, which is currently resident in std/openrj.d. If it receives a +ve reaction we can move it into somewhere common, and use it for all enums. (That's assuming, of course, we don't get something in the language to do it for us.)
Mar 10 2005
Jason Mills wrote:Maybe D should have enums that are Java-like. See http://java.sun.com/j2se/1.5.0/docs/guide/language/enums.htmlYou mean classes ? But if strings and arrays are not classes in D, then why should enumerations be ? Heck, sometimes not even classes are classes in D (!) - but just structs, for performance reasons ? I think this could be solved with better TypeInfo and some props... Like http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/12594 (from the http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList) --anders
Mar 10 2005