Re: Windows Header consts
On Tuesday, 8 September 2015 at 17:22:44 UTC, NX wrote: I have figure out typo: ...I had to figure out...
Re: Windows Header consts
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote: It's called encapsulation. Do you have any idea how much I struggled when I try to use enums in OpenTK library because they were "encapsulated" ? Whenever I read OpenGL tutorials I have figure out which enum-name they used as container...
Re: Windows Header consts
On that note, is there also any generic translation software for
code that you can program a set of simple "rules"(matching and
arranging) to translate source code?
e.g., match("const WM_", ";")->WM.add(%1 + ",")).
The above should be obvious but essentially it matches the first
string until the second is found, adds it to the WM
container(which, we can specify it it's type). %1 is just what
was found inbetween the two bookends in the match. We add a comma
for the next enum.
(such a line would put all the const WM's into the enum, it
doesn't handle the outer static versioning, so would break
headers... hence a more robust solution is needed)
Re: Windows Header consts
On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote: const WM_* -> add to enum WM; else WM_* -> WM.* I'm against that. The documentation all says WM_* and we shouldn't muck with it. const -> enum is a good idea though. These headers were all written way back when when const and enum had different meanings. I guessing one would need a D or C parser to deal with all this? hackerpilot's dfix would be the starting point.
Windows Header consts
Windows headers contain a ton of global const's for the various
messages. Seems like a very bad way to go about this.
Could one not simply put all these in an enum? e.g., enum WM {
WM_CREATE = 1, etc... }?
If so, because there are so many and so many references to them,
this can't be done easily by hand. Surely there is a way to
automate this? But because the headers are not consistently
written, a simple search and replace won't work well?
e.g.,
const WM_* -> add to enum WM;
else WM_* -> WM.*
because there is code like
static if (_WIN32_WINNT >= 0x500) {
enum {
WM_CHANGEUISTATE= 0x0127,
WM_UPDATEUISTATE= 0x0128,
WM_QUERYUISTATE = 0x0129
}
// LOWORD(wParam) values in WM_*UISTATE*
enum {
UIS_SET = 1,
UIS_CLEAR = 2,
UIS_INITIALIZE = 3
}
// HIWORD(wParam) values in WM_*UISTATE*
enum {
UISF_HIDEFOCUS = 0x1,
UISF_HIDEACCEL = 0x2
}
}
static if (_WIN32_WINNT >= 0x501) {
// HIWORD(wParam) values in WM_*UISTATE*
enum {
UISF_ACTIVE = 0x4
}
}
(unless one can define partial enums or use static if in the
enums directly(probably the case but parsing is more difficult))
I guessing one would need a D or C parser to deal with all this?
Re: Windows Header consts
On Monday, 7 September 2015 at 20:55:25 UTC, Adam D. Ruppe wrote: On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote: It's called encapsulation. It prevents namespace pollution and identifier collision. This is already provided by the D module system. Even if you were to define a WM_CREATE in your code, it would not cause a major problem with the Win32 name because you can disambiguate via the imports. (That's also a minor hassle, but it is more rare for these long names than a short name like WM anyway!) My editor already autocompletes WM_* names anyway, but again, the D module system can help with that too if you didn't want the keyword based completion I use for that. I just don't see any advantage here to counterbalance the pain of changing it. Again, it's called progress. Why keep using the same defunct system for endless years simply because that's the way it was done? It's like saying we should never upgrade the space shuttle(not that it matters any more) simply because the previous one was working? Do you seriously think that your logic is the best? If you could prove that Bill Gates designed the best OS ever possible, that is one thing... But changes are they shit all over themselves while doing it because they didn't learn from there mistakes(how could they, they go in to the future to see what kinda crap came out). Do you think computers in 100 years are still going to be using windows? Do you think the designers will still use the same programming techniques? Do you think they will worship Bill Gates because think they the messaging model of Windows was the ultimate gift to humanity? It's one thing to say: "I'm just too lazy to want to waste all that time changing stuff to make it work". That's a valid argument! But it's quite different to say "We don't need to change because this model works best and any modification of it will only produce a poorer result". If you are going to use the second argument, you need to prove it. If you are going to use the first, don't expect to get anywhere. I just wish when people say stuff like you have done, you would be honest and say what you really mean so we don't have to waste time beating around the bush. A simple "I'm don't care what others want, I think we should keep it the same because I'm happy with it". I'm OK with such a statement. At least it's honest and direct. I might not like the selfishness that it implies, but to each his own, I suppose. Oh, and who says you couldn't keep both systems? But I'll never understand why people think keeping a junker around and NOT allow something better is a good idea. You can keep your rusted ol' ElCamino that's missing a tire and has no hood if you want. But why stop me from having a Ferrari? Is it jealousy? Selfishness? There's enough gas to go around you know? And if we both arrive at the gas station we can take turns, if your willing?
Re: Windows Header consts
On Monday, 7 September 2015 at 22:21:28 UTC, Adam D. Ruppe wrote: On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote: Oh, and who says you couldn't keep both systems? Nobody. There's absolutely nothing stopping you from defining your one constants and bindings. I think you should actually do it and see for yourself the pros and cons in practice. Which is why I asked is there is an easy way to do it, and you replied that essentially that it shouldn't be changed because it would change things.
Re: Windows Header consts
On Monday, 7 September 2015 at 23:11:36 UTC, Prudence wrote: I asked is there is an easy way to do it, and you replied that essentially that it shouldn't be changed because it would change things. I also said: I guessing one would need a D or C parser to deal with all this? hackerpilot's dfix would be the starting point. https://github.com/Hackerpilot/dfix
Re: Windows Header consts
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote: Again, it's called progress. Why keep using the same defunct system for endless years simply because that's the way it was done? Any C library binding should maintain the same interface as the C library as much as possible. That way any existing C code can be directly ported to D with minimal modification. If you then want to build a wrapper on top of that to make it more D-like, that's perfectly fine, but the binding itself shouldn't be D-ified.
Re: Windows Header consts
On Monday, 7 September 2015 at 22:02:47 UTC, Prudence wrote: Oh, and who says you couldn't keep both systems? Nobody. There's absolutely nothing stopping you from defining your one constants and bindings. I think you should actually do it and see for yourself the pros and cons in practice.
Re: Windows Header consts
On Monday, 7 September 2015 at 19:06:48 UTC, Prudence wrote: It's called encapsulation. It prevents namespace pollution and identifier collision. This is already provided by the D module system. Even if you were to define a WM_CREATE in your code, it would not cause a major problem with the Win32 name because you can disambiguate via the imports. (That's also a minor hassle, but it is more rare for these long names than a short name like WM anyway!) My editor already autocompletes WM_* names anyway, but again, the D module system can help with that too if you didn't want the keyword based completion I use for that. I just don't see any advantage here to counterbalance the pain of changing it.
Re: Windows Header consts
On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote: because it is confusing and hard for you to understand over Nope, I'm saying it is a pointless change. If you do that, EVERY time you want to look something up, you need to rewrite WM.* into WM_* since that's what the docs say. And then EVERY time you copy/paste code from C or, again, the docs, you need to change it the other way. (and moreover, it won't even work, since like you pointed out, some enums have static if in part) That's a big hassle... and what's the benefit? What do you actually gain by doing this? Did you do a lot of win32 programming back in the day? Yup, and I still do. The documented names have worked for twenty years, why change them now?
Re: Windows Header consts
On Monday 07 September 2015 21:06, Prudence wrote: > If you think mentally changing a . to a _ is a hassle then your > in trouble! An apple a day simply won't help! [...] > Oh well, some people > just don't like progress! Do you want to go back to using wooden > wheels too? [...] > Get out of the dark ages! This is uncalled for. Please stay friendly.
Re: Windows Header consts
On Monday, 7 September 2015 at 17:59:43 UTC, Adam D. Ruppe wrote: On Monday, 7 September 2015 at 17:44:54 UTC, Prudence wrote: const WM_* -> add to enum WM; else WM_* -> WM.* I'm against that. The documentation all says WM_* and we shouldn't muck with it. huh? Are you saying you don't like to use WM.Create because it is confusing and hard for you to understand over WM_Create? Did you do a lot of win32 programming back in the day?
Re: Windows Header consts
On Monday, 7 September 2015 at 18:58:08 UTC, Adam D. Ruppe wrote: On Monday, 7 September 2015 at 18:42:59 UTC, Prudence wrote: because it is confusing and hard for you to understand over Nope, I'm saying it is a pointless change. If you do that, EVERY time you want to look something up, you need to rewrite WM.* into WM_* since that's what the docs say. And then EVERY time you copy/paste code from C or, again, the docs, you need to change it the other way. (and moreover, it won't even work, since like you pointed out, some enums have static if in part) That's a big hassle... and what's the benefit? What do you actually gain by doing this? It's called encapsulation. It prevents namespace pollution and identifier collision. It also makes intelligent easier, not to mention looks nicer, keeps everything tidy, and everything else that makes coding easier. If you think mentally changing a . to a _ is a hassle then your in trouble! An apple a day simply won't help! I understand porting code won't be as easy but a simple WM_ to WM replacement would fix 99% of the problems. Oh well, some people just don't like progress! Do you want to go back to using wooden wheels too? Is that better because it's easier to understand than the complexity of vulcanized rubber and carbon steel? Did you do a lot of win32 programming back in the day? Yup, and I still do. The documented names have worked for twenty years, why change them now? That's what I figured! Get out of the dark ages!
