[DLLCC] Broken #define's (again)

Lets take these three defines and see what they actually return when
parsed and executed,

#define ACE_UNDEFINED                   900
#define ACE_UNDEFINED_USERNAME          ACE_UNDEFINED+1
#define ACE_UNDEFINED_PASSCODE          ACE_UNDEFINED+2

These are the results,

ACE_UNDEFINED
        <C: #define ACE_UNDEFINED 900>
ACE_UNDEFINED_USERNAME
        <C: #define ACE_UNDEFINED_USERNAME ACE_UNDEFINED+1>
ACE_UNDEFINED_PASSCODE
        <C: #define ACE_UNDEFINED_PASSCODE ACE_UNDEFINED+2>

These are the returns,

interface ACE_UNDEFINED 900
interface ACE_UNDEFINED_USERNAME 1
interface ACE_UNDEFINED_PASSCODE 2

Now the curious thing is that if you go and recompile them all in the
right order (!), guess what they return,

interface ACE_UNDEFINED 900
interface ACE_UNDEFINED_USERNAME 901
interface ACE_UNDEFINED_PASSCODE 902

Sigh...

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

---

DISCLAIMER: This email is bound by the terms and conditions described at http://www.key.net/disclaimer.htm

Travis Griggs <[hidden email]> wrote:

| On Sep 15, 2006, at 12:11, Boris Popov wrote:

| > Lets take these three defines and see what they actually return when
| > parsed and executed,
| >
| > #define ACE_UNDEFINED                   900
| > #define ACE_UNDEFINED_USERNAME          ACE_UNDEFINED+1
| > #define ACE_UNDEFINED_PASSCODE          ACE_UNDEFINED+2
| >
| > These are the results,
| >
| > ACE_UNDEFINED
| > <C: #define ACE_UNDEFINED 900>
| > ACE_UNDEFINED_USERNAME
| > <C: #define ACE_UNDEFINED_USERNAME ACE_UNDEFINED+1>
| > ACE_UNDEFINED_PASSCODE
| > <C: #define ACE_UNDEFINED_PASSCODE ACE_UNDEFINED+2>
| >
| > These are the returns,
| >
| > interface ACE_UNDEFINED 900
| > interface ACE_UNDEFINED_USERNAME 1
| > interface ACE_UNDEFINED_PASSCODE 2
| >
| > Now the curious thing is that if you go and recompile them all in the
| > right order (!), guess what they return,
| >
| > interface ACE_UNDEFINED 900
| > interface ACE_UNDEFINED_USERNAME 901
| > interface ACE_UNDEFINED_PASSCODE 902

| What if... defines were done as shares. And those shares were lazy
| initializing? I know we harrowed the lazy share thing pretty good
| about 9 months ago, but I think my intent got list on the mix. I'd
| like to be able to provide lazy shares _in addition_ to the existing
| ones. They'd be perfect for this scenario. Personally, I like

| InterfaceClass.ACE_UNDEFINED better anyway.

And if typedefs were shares.  In fact all C type/define info should live in a namespace.  This models C better than the bous use of methods which guve the mis-impression that one can use inheritance to redefine subparts of a C type definition (example below).

This has been on the cards since Jigsaw, the VW/VSE merge started after the ParcPlace-Digitalk merger.  It was one of my most important design goals when as part of Jigsaw someone who shall remain nameless was given the task of merging the VW and VSE C connects.  But no progress was made in a looong time (2 years).  Morale was very bad then.

Right now the problem is finding the person and the time and you, Travis are committed elsewhere ;)


| -----
Eliot Miranda                 ,,,^..^,,,                mailto:[hidden email]
VisualWorks Engineering, Cincom  Smalltalk: scene not herd  Tel +1 408 216 4581
3350 Scott Blvd, Bldg 36 Suite B, Santa Clara, CA 95054 USA Fax +1 408 216 4500