Re: private method in interface
On 2011-06-03 21:52, Michael Shulman wrote: > On Fri, Jun 3, 2011 at 8:54 PM, Jonathan M Davis wrote: > > Try to compile with -w. My guess is that you will get a compiler error. > > Nope. Then file a bug report on it. As I understand it, overriding a non-virtual function in D should be illegal. Certainly, it goes against how D deals with virtuality in general. - Jonathan M Davis
Re: private method in interface
On Fri, Jun 3, 2011 at 8:54 PM, Jonathan M Davis wrote: > Try to compile with -w. My guess is that you will get a compiler error. Nope.
Re: private method in interface
On 2011-06-03 19:44, Michael Shulman wrote: > On Fri, Jun 3, 2011 at 3:07 PM, Jonathan M Davis wrote: > > I'd suggest opening a bug report. > > Okay, will do. > > > Regardless, I would have hoped that you'd get an error at compile > > time about overriding a non-virtual function if package is > > non-virtual > > It appears that overriding a non-virtual, non-abstract method (private > or package) just hides the base-class version when the reference is of > derived type, exactly as happens in C++ for non-virtual methods. E.g. > > class A { > private void dostuff() { writeln ("In A.dostuff"); } > } > > class B : A { > private void dostuff() { writeln ("In B.dostuff"); } > } > > void main () { > B y = new B(); > A x = y; > y.dostuff(); > x.dostuff(); > } > > prints > > In B.dostuff > In A.dostuff > > I would have kind of hoped for a compiler error too, given that C++ > programmers generally seem to feel that overriding non-virtual methods > in this way is a bad idea. Try to compile with -w. My guess is that you will get a compiler error. But yes, it really should give an error regardless. - Jonathan M Davis
Re: private method in interface
The bug report appears to already exist: http://d.puremagic.com/issues/show_bug.cgi?id=3258 On Fri, Jun 3, 2011 at 3:07 PM, Jonathan M Davis wrote: > On 2011-06-03 14:55, Michael Shulman wrote: >> On Fri, Jun 3, 2011 at 1:02 PM, Jonathan M Davis > wrote: >> > And if you don't know about NVI, having a >> > virtual private function is just plain weird. >> >> Well, it makes perfect sense to me, once given that in D, 'private' >> allows access from anywhere in the same module, rather than only in >> the defining class. I agree that it's weird and surprising in C++. >> >> Are 'package' qualified functions also non-virtual? The documentation >> http://d-programming-language.org/function.html#virtual-functions >> says that "all non-static non-private non-template member functions >> are virtual", but I get the same sort of linker errors with 'package' >> functions that I do with 'private' ones, even with code that's all in one >> module. > > I would expect package to be virtual, but Walter could have implemented it as > non-virtual on the theory that if you wanted it to be overridden, it would be > protected (which would be the normal thing to do when you intend to have a > derived class override a member function). I'd suggest opening a bug report. > It wouldn't hurt my feelings any if private and package were both always non- > virtual, but TDPL says that they're both virtual, and the online docs says > that package is virtual, so either the compiler needs to be fixed or TDPL and > the docs need to be changed. Regardless, I would have hoped that you'd get an > error at compile time about overriding a non-virtual function if package is > non-virtual, so at minimum, the error message needs to be improved. So, open a > bug report on it, and Walter can make whatever changes are appropriate. > > - Jonathan M Davis >
Re: private method in interface
On Fri, Jun 3, 2011 at 3:07 PM, Jonathan M Davis wrote: > I'd suggest opening a bug report. Okay, will do. > Regardless, I would have hoped that you'd get an error at compile > time about overriding a non-virtual function if package is > non-virtual It appears that overriding a non-virtual, non-abstract method (private or package) just hides the base-class version when the reference is of derived type, exactly as happens in C++ for non-virtual methods. E.g. class A { private void dostuff() { writeln ("In A.dostuff"); } } class B : A { private void dostuff() { writeln ("In B.dostuff"); } } void main () { B y = new B(); A x = y; y.dostuff(); x.dostuff(); } prints In B.dostuff In A.dostuff I would have kind of hoped for a compiler error too, given that C++ programmers generally seem to feel that overriding non-virtual methods in this way is a bad idea. Mike
Re: .lib problem
Sweet, thanks you very much! :) "Andrej Mitrovic" wrote in message news:mailman.573.1307123755.14074.digitalmars-d-le...@puremagic.com... http://ftp.digitalmars.com/bup.zip Docs here: http://www.digitalmars.com/ctg/implib.html
Re: private method in interface
On 2011-06-03 14:55, Michael Shulman wrote: > On Fri, Jun 3, 2011 at 1:02 PM, Jonathan M Davis wrote: > > And if you don't know about NVI, having a > > virtual private function is just plain weird. > > Well, it makes perfect sense to me, once given that in D, 'private' > allows access from anywhere in the same module, rather than only in > the defining class. I agree that it's weird and surprising in C++. > > Are 'package' qualified functions also non-virtual? The documentation > http://d-programming-language.org/function.html#virtual-functions > says that "all non-static non-private non-template member functions > are virtual", but I get the same sort of linker errors with 'package' > functions that I do with 'private' ones, even with code that's all in one > module. I would expect package to be virtual, but Walter could have implemented it as non-virtual on the theory that if you wanted it to be overridden, it would be protected (which would be the normal thing to do when you intend to have a derived class override a member function). I'd suggest opening a bug report. It wouldn't hurt my feelings any if private and package were both always non- virtual, but TDPL says that they're both virtual, and the online docs says that package is virtual, so either the compiler needs to be fixed or TDPL and the docs need to be changed. Regardless, I would have hoped that you'd get an error at compile time about overriding a non-virtual function if package is non-virtual, so at minimum, the error message needs to be improved. So, open a bug report on it, and Walter can make whatever changes are appropriate. - Jonathan M Davis
Re: Is this a good way of setting up a timer?
I didn't even think about issue #1. Thanks again!
Re: Is this a good way of setting up a timer?
On 2011-06-03 14:37, Andrej Mitrovic wrote: > On 6/3/11, Jonathan M Davis wrote: > > Generally, you'd just put it to sleep for the period of time that you > > want to > > wait for. The only reason that I see to keep waking it up is if it could > > be interrupted and effectively told to wake up - in which case you would > > be sleeping and waking up over and over again, checking to see if enough > > time had > > passed or if you had been signaled to stop waiting. > > Yeah, I should have made a better example. Basically I have a loop > that ends either after a specific time period, or it could end by > receiving a signal. I just use a shared book for that, this would be > it: > > while (engineActive) // shared bool > { > if (Clock.currTime > finalTime) > break; > > Thread.sleep(dur!("seconds")(1)); > } Yeah. That looks fine, though currTime isn't a property (it takes an optional TimeZone object), so technically it should have parens. That's obviously not enforced at the moment though. In any case, it's essentially fine, but has 2 potential issues, depending on how accurate you want the timing to be or how responsive you want the loop to be in exiting. First off, you pay no attention whatsoever to how close the current time is to the final time such that there could be a few microseconds of difference between them and you'd still sleep for a whole second before exiting. If you want it to be more accurate, then it should be something more like while(engineActive) { auto curr = Clock.currTime(); if(curr > finalTime) break; Thread.sleep(dur!"seconds(min(1, (finalTime - currTime).total!"seconds"(; } Incidentally, this use case shows that I should probably add overloads for some of the basic math functions for Duration... In any case, such an implementation would make it so that it doesn't sleep for longer than it needs to. The other potential issue is responsiveness. If you want the loop to exit quickly after engineActive has been set to true, then you should probably be setting sleep to something more like 100ms (though if you set the value too low, then the loop wakes up more often than might be desirable, so it's a bit of a balancing act). Regardless, the only potential issues lie with how quickly you want the loop to exit after the exit condition has been reached. - Jonathan M Davis
Re: private method in interface
On Fri, Jun 3, 2011 at 1:02 PM, Jonathan M Davis wrote: > And if you don't know about NVI, having a > virtual private function is just plain weird. Well, it makes perfect sense to me, once given that in D, 'private' allows access from anywhere in the same module, rather than only in the defining class. I agree that it's weird and surprising in C++. Are 'package' qualified functions also non-virtual? The documentation http://d-programming-language.org/function.html#virtual-functions says that "all non-static non-private non-template member functions are virtual", but I get the same sort of linker errors with 'package' functions that I do with 'private' ones, even with code that's all in one module. Mike
Re: Is this a good way of setting up a timer?
On 6/3/11, Jonathan M Davis wrote: > > Generally, you'd just put it to sleep for the period of time that you want > to > wait for. The only reason that I see to keep waking it up is if it could be > interrupted and effectively told to wake up - in which case you would be > sleeping and waking up over and over again, checking to see if enough time > had > passed or if you had been signaled to stop waiting. Yeah, I should have made a better example. Basically I have a loop that ends either after a specific time period, or it could end by receiving a signal. I just use a shared book for that, this would be it: while (engineActive) // shared bool { if (Clock.currTime > finalTime) break; Thread.sleep(dur!("seconds")(1)); } > Oh, > and > by the way, std.datetime publicly imports core.time, so if you import > std.datetime, you don't need to import core.time. > > - Jonathan M Davis > Ok thanks!
Re: Is this a good way of setting up a timer?
On 2011-06-03 14:22, Andrej Mitrovic wrote: > I can't find any timers in phobos, basically I want some loop to run for a > predetermined amount of time. Currently I use this: > > import core.time; > import std.datetime; > import core.thread; > > void main() > { > auto finalTime = Clock.currTime + dur!"seconds"(4); > > while (true) > { > Thread.sleep(dur!("seconds")(1)); > if (Clock.currTime > finalTime) > break; > } > } > > Is that check doing any conversions in the background, or am I safe > (performance-wise)? Well I'm probably wasting performance on waking up the > thread every second.. hmm. Generally, you'd just put it to sleep for the period of time that you want to wait for. The only reason that I see to keep waking it up is if it could be interrupted and effectively told to wake up - in which case you would be sleeping and waking up over and over again, checking to see if enough time had passed or if you had been signaled to stop waiting. Now, if what you're trying to do is run the code in the loop for a predetermined length of time, then you'd just check the time every X iterations of the loop. If the loop is short, then X would be larger (to avoid asking for the time needlessly often and wasting cycles), whereas if the loop is long enough, then X might even be 1. As your code stands though, I'm not sure what you're really trying to. Oh, and by the way, std.datetime publicly imports core.time, so if you import std.datetime, you don't need to import core.time. - Jonathan M Davis
Is this a good way of setting up a timer?
I can't find any timers in phobos, basically I want some loop to run for a predetermined amount of time. Currently I use this: import core.time; import std.datetime; import core.thread; void main() { auto finalTime = Clock.currTime + dur!"seconds"(4); while (true) { Thread.sleep(dur!("seconds")(1)); if (Clock.currTime > finalTime) break; } } Is that check doing any conversions in the background, or am I safe (performance-wise)? Well I'm probably wasting performance on waking up the thread every second.. hmm.
Re: 16 byte alignment
I made the Following change to backend/elfobj.c I have no idea what I just did but it has solved my problem Could anyone explain? -- align16.patch -- diff --u a/src/backend/elfobj.c b/src/backend/elfobj.c --- a/src/backend/elfobj.c +++ b/src/backend/elfobj.c @@ -683,7 +683,7 @@ void obj_init(Outbuffer *objbuf, const char *filename, const char *csegname) elf_newsection2(0, SHT_NULL, 0, 0,0,0,0,0, 0,0); elf_newsection2(NAMIDX_TEXT,SHT_PROGDEF,SHF_ALLOC|SHF_EXECINSTR,0,0,0,0,0, 4,0); elf_newsection2(NAMIDX_RELTEXT,SHT_RELA, 0,0,0,0,SHI_SYMTAB, SHI_TEXT, 8,0x18); -elf_newsection2(NAMIDX_DATA,SHT_PROGDEF,SHF_ALLOC|SHF_WRITE, 0,0,0,0,0, 8,0); +elf_newsection2(NAMIDX_DATA,SHT_PROGDEF,SHF_ALLOC|SHF_WRITE, 0,0,0,0,0, 16,0); elf_newsection2(NAMIDX_RELDATA64,SHT_RELA, 0,0,0,0,SHI_SYMTAB, SHI_DATA, 8,0x18); elf_newsection2(NAMIDX_BSS, SHT_NOBITS,SHF_ALLOC|SHF_WRITE, 0,0,0,0,0, 16,0); elf_newsection2(NAMIDX_RODATA,SHT_PROGDEF,SHF_ALLOC, 0,0,0,0,0, 16,0);
Re: private method in interface
On 2011-06-03 11:59, Michael Shulman wrote: > On Fri, Jun 3, 2011 at 11:22 AM, Jonathan M Davis wrote: > >> However, given that in D, 'private' only means restricted to a > >> *module*, it's less clear to me why private functions should be > >> singled out as non-virtual. I might want certain methods to be > >> accessible only within a given module, but still allow them to be > >> overridden within a class hierarchy that exists entirely inside that > >> module. Unless the point of view is that each class should always > >> exist in its own module? > > > > No, there would be nothing wrong with overriding private member functions > > within a module with derived classes (assuming that private were > > overridable). > > Okay. Then I don't quite understand the rationale for all private > functions being non-virtual. Efficiency. Virtual calls cost more than non-virtual calls. And if you're never going to override a function, why have it be virtual and incur that extra cost? C++ defaults to non-virtual and has the virtual modifier for making functions virtual, which gives you the efficiency by default with the flexibility to make them virtual if you want to. The problem is that it's still possible to override non-virtual functions, which is almost always a bug. Java took the route of making all functions virtual except where the compiler optimizes them to be non-virtual. D did the same except for private functions, likely on the theory that you basically never override private functions, so why incur the cost? And if you don't know about NVI, having a virtual private function is just plain weird. Lots of people are surprised to find out that it's legal to override private functions like that in C++. So, in most cases, you don't want virtual private functions. The overridability is generally useless and it costs more to call them. Worse, they can't be inlined, because the call is polymorphic and you don't know whether the version of the function in the current class or one in a derived class will be called. The one exception as far as usefulness goes is the NVI idiom, and TDPL said that you could do it (I think because Andrei didn't realize that you couldn't rather than because it was intended to be changed in the language). However, you can still effectively do NVI with protected functions, so arguably, the costs to making private functions virtual far outweigh the benefits. But the fact that TDPL says that private is overridable for NVI may make it so that the language is changed to allow it. We'll have to see. In any case, the reason that you don't normally want private functions to be virtual is because virtual functions cannot generally be inlined and are less efficient than non-virtual functions. - Jonathan M Davis
Re: private method in interface
On Fri, Jun 3, 2011 at 11:22 AM, Jonathan M Davis wrote: >> However, given that in D, 'private' only means restricted to a >> *module*, it's less clear to me why private functions should be >> singled out as non-virtual. I might want certain methods to be >> accessible only within a given module, but still allow them to be >> overridden within a class hierarchy that exists entirely inside that >> module. Unless the point of view is that each class should always >> exist in its own module? > > No, there would be nothing wrong with overriding private member functions > within a module with derived classes (assuming that private were overridable). Okay. Then I don't quite understand the rationale for all private functions being non-virtual. Mike
Re: private method in interface
On 2011-06-03 11:13, Michael Shulman wrote: > On Thu, Jun 2, 2011 at 11:55 PM, Jonathan M Davis wrote: > > I don't really like the idea of private functions being virtual > > by default though, so maybe your suggestion would be a good one. > > Speaking as a newbie with very little D experience, the idea of > private functions being non-virtual would make perfect sense to me if > 'private' meant restricted to a single class, as it does in C++. The > situation of a derived class being able to override a private function > from an interface or base class, but not *call* the overridden > function, seems a bit weird and pointless; using 'protected' does make > more sense to me for that use case. Actually, C++ has exactly this behavior. You can overload private functions in C++. That's where the whole Non-Virtual Interface paradigm came from, I believe. However, in C++, functions are only virtual if you make them virtual (which you don't normally do with private functions unless you're doing NVI), unlike D. > However, given that in D, 'private' only means restricted to a > *module*, it's less clear to me why private functions should be > singled out as non-virtual. I might want certain methods to be > accessible only within a given module, but still allow them to be > overridden within a class hierarchy that exists entirely inside that > module. Unless the point of view is that each class should always > exist in its own module? No, there would be nothing wrong with overriding private member functions within a module with derived classes (assuming that private were overridable). That would be a bit weird, generally-speaking, but it would be perfectly legitimate. There are no restrictions on how many classes or structs you put in a module, and the core D community does not seem to think that code should necessarily be divided that way. For instance, both std.container and std.datetime in Phobos have multiple types defined within them. So, you could define as many classes or structs in a module as you want to. The main issue would be if the module got too large (which some have accussed std.datetime of doing). - Jonathan M Davis
Re: private method in interface
On Thu, Jun 2, 2011 at 11:55 PM, Jonathan M Davis wrote: > I don't really like the idea of private functions being virtual > by default though, so maybe your suggestion would be a good one. Speaking as a newbie with very little D experience, the idea of private functions being non-virtual would make perfect sense to me if 'private' meant restricted to a single class, as it does in C++. The situation of a derived class being able to override a private function from an interface or base class, but not *call* the overridden function, seems a bit weird and pointless; using 'protected' does make more sense to me for that use case. However, given that in D, 'private' only means restricted to a *module*, it's less clear to me why private functions should be singled out as non-virtual. I might want certain methods to be accessible only within a given module, but still allow them to be overridden within a class hierarchy that exists entirely inside that module. Unless the point of view is that each class should always exist in its own module? Mike
Re: .lib problem
http://ftp.digitalmars.com/bup.zip Docs here: http://www.digitalmars.com/ctg/implib.html
Re: .lib problem
Where can I find this "implib" tool you mentioned? I have the latest Windows SDK and Visual Studio 2010. Yet when I perform a search in program files I can't find it!! :( "Andrej Mitrovic" wrote in message news:mailman.565.1307117174.14074.digitalmars-d-le...@puremagic.com... If you have coffimplib (which isn't free), then you could just convert the windows sdk import lib to OMF format. Otherwise, you can create an import library from a DLL. Find the DLL (e.g. kernel32.dll), and run: implib /s kernel32.lib kernel32.dll Then link with the new import lib. I think that should work.
Re: very newbie question (sring confusion)
std.algorithm! will have a look, thanks! "bearophile" wrote in message news:isb5ql$1i23$1...@digitalmars.com... Lloyd Dupont: I did the following, what do you think of my implementation? Those for loops seem better as foreach ones, or even reverse foreach ones. Probably in std.algorithm there is stuff to shorten your code. Bye, bearophile
Re: very newbie question (sring confusion)
On 2011-06-03 09:55, Lloyd Dupont wrote: > I did the following, what do you think of my implementation? > (checking if my string and array usage could be improved / powered > up!!!) > > string[] _locales = ["en-AU", "fr-FR"]; > string getCurrentLocal() { return "fr-BE"; } > string[] getCandidates() > { > auto local = getCurrentLocal(); > > string match = null; > for (int i = _locales.length; i-->0;) > { > if(_locales[i] == local) > { > match = _locales[i]; > break; > } > } > > string partial = null; > if(local.length >= 2 && match == null) > { > for (int i = _locales.length; i-->0;) > { > auto tmpl = _locales[i]; > if (tmpl.length > 2 && tmpl[0] == local[0] && tmpl[1] == > local[1]) > { > partial = tmpl; > break; > } > } > } > > string[] result; > if(match) > { > result.length = result.length + 1; > result[result.length-1] = match; > } > if(partial && partial != match) > { > result.length = result.length + 1; > result[result.length-1] = partial; > } > if(match != _locales[0] && partial != _locales[0]) > { > result.length = result.length + 1; > result[result.length-1] = _locales[0]; > } > return result; > } You should probably take a look at std.algorithm.find. - Jonathan M Davis
Re: Can't use float array in map
On 06/03/2011 10:15 AM, Andrej Mitrovic wrote: > Offending line in map: > alias typeof(_fun(.ElementType!R.init)) ElementType; The fact that the error points at that line should be a bug. That's just an alias, nothing is evaluated at that line. Ali
Re: very newbie question (sring confusion)
Lloyd Dupont: > I did the following, what do you think of my implementation? Those for loops seem better as foreach ones, or even reverse foreach ones. Probably in std.algorithm there is stuff to shorten your code. Bye, bearophile
Re: Can't use float array in map
Andrej Mitrovic: > A quick workaround would be: > static if (isFloatingPoint!(ElementType!R)) > { > .ElementType!R x; > alias typeof(_fun(x)) ElementType; > } > else > { > alias typeof(_fun(.ElementType!R.init)) ElementType; > } If you have improvements for Phobos code, then I suggest to write it in Bugzilla (or even create a pull request in git). Bye, bearophile
Re: Can't use float array in map
Ugh don't I love making silly posts like these. ref won't work for any types, not just floats, since it uses the .init property. My real problem was that I was using assignment in my first example instead of returning a value. Using map with ref doesn't make much sense. So my complaints are void. On 6/3/11, Andrej Mitrovic wrote: > Offending line in map: > alias typeof(_fun(.ElementType!R.init)) ElementType; > > So it tires to pass .init which will be nan for floats. > > A quick workaround would be: > static if (isFloatingPoint!(ElementType!R)) > { > .ElementType!R x; > alias typeof(_fun(x)) ElementType; > } > else > { > alias typeof(_fun(.ElementType!R.init)) ElementType; > } > > Also, my example was just a little flawed (semantically speaking), > since I was missing a return statement: > > double[10] arr; > arr[] = 1.0; > auto result = map!((ref double sample){ return 1.0; })(arr[]); > > This will then work with that change. >
Re: Can't use float array in map
Offending line in map: alias typeof(_fun(.ElementType!R.init)) ElementType; So it tires to pass .init which will be nan for floats. A quick workaround would be: static if (isFloatingPoint!(ElementType!R)) { .ElementType!R x; alias typeof(_fun(x)) ElementType; } else { alias typeof(_fun(.ElementType!R.init)) ElementType; } Also, my example was just a little flawed (semantically speaking), since I was missing a return statement: double[10] arr; arr[] = 1.0; auto result = map!((ref double sample){ return 1.0; })(arr[]); This will then work with that change.
Re: .lib problem
Thanks I'll try tomorrow! :) (now I should really go to bed...) "Andrej Mitrovic" wrote in message news:mailman.565.1307117174.14074.digitalmars-d-le...@puremagic.com... If you have coffimplib (which isn't free), then you could just convert the windows sdk import lib to OMF format. Otherwise, you can create an import library from a DLL. Find the DLL (e.g. kernel32.dll), and run: implib /s kernel32.lib kernel32.dll Then link with the new import lib. I think that should work.
Re: very newbie question (sring confusion)
I did the following, what do you think of my implementation? (checking if my string and array usage could be improved / powered up!!!) string[] _locales = ["en-AU", "fr-FR"]; string getCurrentLocal() { return "fr-BE"; } string[] getCandidates() { auto local = getCurrentLocal(); string match = null; for (int i = _locales.length; i-->0;) { if(_locales[i] == local) { match = _locales[i]; break; } } string partial = null; if(local.length >= 2 && match == null) { for (int i = _locales.length; i-->0;) { auto tmpl = _locales[i]; if (tmpl.length > 2 && tmpl[0] == local[0] && tmpl[1] == local[1]) { partial = tmpl; break; } } } string[] result; if(match) { result.length = result.length + 1; result[result.length-1] = match; } if(partial && partial != match) { result.length = result.length + 1; result[result.length-1] = partial; } if(match != _locales[0] && partial != _locales[0]) { result.length = result.length + 1; result[result.length-1] = _locales[0]; } return result; }
Can't use float array in map
test case: import std.algorithm; void main() { float[10] arr; arr[] = 0.0; map!((ref float sample){ sample = 1.0; })(arr[]); } D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(382): Error: nan is not an lvalue This looks like a bug to me?
very newbie question (sring confusion)
maybe it's late, or I have a hard time reading the string and array class methods.. (which I have! :~) anyway, I have a very simple problem and it seems hard to fix! let say I have a list of resource named preferential order (favored first) and I'd like to do return a list of match in preferential order (with always the default last) for example: my resources (default first): "en-AU", "fr-FR", "fr-BE" my matches: for i'd like to return a variable list / array xxx "en-US" => "en-AU" "fr-CA" => "fr-FR", "en-AU" "fr-BE" => "fr-BE", "en-AU" "es-EP" => "en-AU" how could I do that?
Re: .lib problem
If you have coffimplib (which isn't free), then you could just convert the windows sdk import lib to OMF format. Otherwise, you can create an import library from a DLL. Find the DLL (e.g. kernel32.dll), and run: implib /s kernel32.lib kernel32.dll Then link with the new import lib. I think that should work.
.lib problem
what if the Win32 function I'm interested in don't seem to be in .lib provide by dmd... (for example vista & up windows function) Can I just use the .lib which come from the windows SDK?
Re: array of constants?
thanks! "Etherous" wrote in message news:is8dbh$n22$1...@digitalmars.com... You need to set it in a static constructor immutable string[int] MyDict; static this () { MyDict = cast(string[int]) [ 1: "monday", 2: "tuesday" ]; }