>This is exactly what I want to happen - evaluation at run-time, not at compile-time. I also hope other functions are not evaluated until run-time. Thinking about this further, this does make sense. The compiler will literally substitute SYS(5) + SYS(2003) for every occurrence of DEFAULT_PATH. Because this is a direct substitution, it will not replace the constant with the compile-time evaluation of the 2 functions.
>
>The concept is that we can remember the name of a constant but not its value or how its value is derived. Same goes for MB_ICONSTOP. I know this will use the Stop sign icon in the messagebox, but no way could I tell you its value without looking it up.

Hiya Mark,

I've got really mixed feelings about this one. I understand, however, that this is what you want. I'm not terribly sure, though, that it's a very good idea. Let me explain.

For anyone new to what compile time constants are and why we use them, let's first go over that. By creating them you reduce memory consumption, increase performance and, make your programs easier to read, and thus, maintain. The most important thing to remember here is that this is supposed to be a constant.

While on the one hand it does make it easier to read CURRENT_DEFAULT_PATH, than SYS(5) + SYS(2003), it is exactly what it says, because it is re-evaluated whenever it's referenced. It's more like a system variable rather than compile time constant. That bothers me, and perhaps it should bother you too. Consider...

What if MS decides that this behavior, strictly because it's inconsistent with the intended, is a bug and fix it later? Whoops! All of a sudden you've got a very difficult to track down bug. All those references to CURRENT_DEFAULT_PATH, are actually references to COMPILE_TIME_DEFAULT_PATH.

Anyway, that's my take.