🚀 go-pugleaf

In article <-T4%8D_@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes:
->...that Objective-C barfs on the following code:
->
->typedef struct {
->        long flags;     /* marks which fields in this structure are defined */
->        int x, y;               /* obsolete for new window mgrs, but clients */
->        int width, height;      /* should set so old wm's don't mess up */
->        int min_width, min_height;
->        int max_width, max_height;
->        int width_inc, height_inc;
->        struct {
->                int x;  /* numerator */
->                int y;  /* denominator */
->        } min_aspect, max_aspect;
->        int base_width, base_height;            /* added by ICCCM version 1 */
->        int win_gravity;                        /* added by ICCCM version 1 */
->} XSizeHints;
->
->The Objective-C processor tries to name the x-y struct the same thing twice,
->causing serious problems.  Those used to programming in X will remember the
->above code from /mit/lib/X/Xutil.h, in the X11R3/4 distribution.
->
->This causes pains for people trying to use X with Objective-C.

This is a known bug involving the generation of code for anonymous
structures which has been fixed for the next release.

->
->Another problem arises from Object and String, two words defined and used
->by both X and Objective-C.  My solution?  I redefined those two words for
->the X stuff, thusly:
->
->		#define String XString
->		#define Object XObject
->
->		(include all x files here)
->
->		#undef XObject
->		#undfe XString
->
->		(include all objective-c stuff here)
->
->And then use the words XString and XObject when dealing with X.  

Unfortunately, there is no standard naming authority for external
names for C programs.  It is small consolation for Stepstone that we
used those names before X.  The problem becomes more severe when you
are using libraries with conflicting names and you don't have the
source.  That is not a problem with either X or Stepstone's
Objective-C Libraries.

The approach you've mentioned is roughly what we recommend.

->
->I reported the first bug to Stepstone a very long time ago (maybe over a
->year) but never received either a confirmation, denial or bug fix.  Sigh.

You should have received a confirmation.

->
->				-Dave
->
->Dave "mr question" McIntyre     |      "....say you're thinking about a plate
->mcintyre@turing.cs.rpi.edu      |       of shrimp.....and someone says to
->office : 518-276-8633		|	you 'plate,' or 'shrimp'......"

I speak the truth, but without the official blessing of Stepstone in
this matter.

Ken

In article <-T4%8D_@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes:
>I reported the first bug to Stepstone a very long time ago (maybe over a
>year) but never received either a confirmation, denial or bug fix.  Sigh.

I hate it when...(1) when a company spokesman makes excuses and (2) when
Stepstone, the company I'm a spokesman for, fumbles and situations like
this arise.

I have passed your note to the group responsible for customer support, who
will investigate why we failed in this case. Perhaps this will insure that 
the failure does not recur in the future. Our policy is that all calls are
to be followed up.

I didn't respond to the specific complaint in your note (i.e. that typedef
struct { ...; struct { } a,b; ...} ... doesn't work properly, because I
wasn't even aware of it myself.

Are you using our compiler, or NeXT's?

The #define String XString; ... #undef String trick is handy, and something
I've has to resort to myself occasionally. In fact, as I recall, at one
time or another either X or SunWindows had a variable named 'id' that
I 'cured' with the same trick.

Thanks for posting it. I'll try to get it added to future releases of
the reference manual.
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482

cox@stpstn.UUCP (Brad Cox) writes:
>In article <-T4%8D_@rpi.edu> mcintyre@turing.cs.rpi.edu (David McIntyre) writes:
>>I reported the first bug to Stepstone a very long time ago (maybe over a
>>year) but never received either a confirmation, denial or bug fix.  Sigh.
>I hate it when...(1) when a company spokesman makes excuses and (2) when
>Stepstone, the company I'm a spokesman for, fumbles and situations like
>this arise.

It's ok, I'm just glad it's going to get fixed.  That's all.

>
>I didn't respond to the specific complaint in your note (i.e. that typedef
>struct { ...; struct { } a,b; ...} ... doesn't work properly, because I
>wasn't even aware of it myself.
>
>Are you using our compiler, or NeXT's?

Yours, on a Sparcstation and a Sun 3.

			-Dave

Dave "mr question" McIntyre     |      "....say you're thinking about a plate
mcintyre@turing.cs.rpi.edu      |       of shrimp.....and someone says to
office : 518-276-8633		|	you 'plate,' or 'shrimp'......"

Hi,

We are programming with Objective-C and X-Window already for a while now
and we hit the same problems. Here our solutions:

In article <-T4%8D_@rpi.edu>, mcintyre@turing.cs.rpi.edu (David McIntyre) writes:
|>
|>	... stuff deleted ...
|>
|>         struct {
|>                 int x;  /* numerator */
|>                 int y;  /* denominator */
|>         } min_aspect, max_aspect;
|>         int base_width, base_height;

The only thing that helps here is to double the definition as follows
	
	   struct _Aspect {
		   int x;  /* numerator */
		   int y;  /* denominator */
           } min_aspect;
	   struct _Aspect max_aspect;
 
|> 
|> Another problem arises from Object and String, two words defined and
|> used by both X and Objective-C.

Basically, I believe that Objective-C and everybody(thing) else should
name its root node more specific, since "Object" is to easy to be used by
somebody else.


Thomas Oeser


*********** DISCLAIMER: All opinions stated here are strictly my own *****
--------------------------------------------------------------------------
Internet:	thomas%apgraph%ap542@ztivax.siemens.com
Europe:		thomas%apgraph%ap542@ztivax.UUCP
UUCP:		...!uunet!mcsun!unido!ztivax!ap542!apgraph!thomas
Phone:		+ 49 89 636 47537
Fax:		+ 49 89 636 45522
Postal Mail:	Siemens Nixdorf Information Systems AG, AP 153,
                Carl-Wery-Str. 22, D-8000 Munich 83, West Germany
--------------------------------------------------------------------------