Carbon.d(321): semicolon expected, not 'CFRangeMake'


static __inline__ CFRange CFRangeMake(CFIndex loc, CFIndex len) {
   CFRange range;
   range.location = loc;
   range.length = len;
   return range;
}



Is it safe just to delete __inline__?

LOL

Another Cocoa programmer out there, eh?

Yes, I believe you can safely remove the __inline__.

Owen

In article <c6h38i$2s3q$1@digitaldaemon.com>, Lws says...
>
>Carbon.d(321): semicolon expected, not 'CFRangeMake'
>
>
>static __inline__ CFRange CFRangeMake(CFIndex loc, CFIndex len) {
>    CFRange range;
>    range.location = loc;
>    range.length = len;
>    return range;
>}
>
>
>
>Is it safe just to delete __inline__?
>

On 2004-04-25 16:35:20 -0700, resistor@mac.com said:

> LOL
> 
> Another Cocoa programmer out there, eh?
> 
> Yes, I believe you can safely remove the __inline__.
> 
> Owen

Actually i'm trying to make a Carbon -> D interface.  Any interest?

Me, I don't do Carbon.  Cocoa forever!

Actually, I've been working on bridging Cocoa/D as well.

Owen

In article <c6j5e7$3l1$1@digitaldaemon.com>, Lws says...
>
>On 2004-04-25 16:35:20 -0700, resistor@mac.com said:
>
>> LOL
>> 
>> Another Cocoa programmer out there, eh?
>> 
>> Yes, I believe you can safely remove the __inline__.
>> 
>> Owen
>
>Actually i'm trying to make a Carbon -> D interface.  Any interest?
>

Awe, why not?   It's a great API.


On 2004-04-26 10:30:21 -0700, resistor@mac.com said:

> Me, I don't do Carbon.  Cocoa forever!
> 
> Actually, I've been working on bridging Cocoa/D as well.
> 
> Owen
> 
> In article <c6j5e7$3l1$1@digitaldaemon.com>, Lws says...
>> 
>> On 2004-04-25 16:35:20 -0700, resistor@mac.com said:
>> 
>>> LOL
>>> 
>>> Another Cocoa programmer out there, eh?
>>> 
>>> Yes, I believe you can safely remove the __inline__.
>>> 
>>> Owen
>> 
>> Actually i'm trying to make a Carbon -> D interface.  Any interest?

On 2004-04-26 19:30:21 +0200, resistor@mac.com said:

> Me, I don't do Carbon.  Cocoa forever!
> 
> Actually, I've been working on bridging Cocoa/D as well.
> 
> Owen
I'm with you Owen.

How is the bridge going? I guess you have to generate wrapper code, given that D uses static binding, rather than Objective-C's dynamic (run time) one.

I know binding dynamic languages like python and Objective-C is pretty easy because of the introspective features, and ability to create new classes at run-time. Static binding has a performance advantage, which is why I am interested in D for my scientific programming.

Drew

Unfortunately, I've been too busy recently too work on it much.  There are some
technical difficulties
involved.  If you're interested, I'd welcome the help!

1)  ObjC uses different functions to call member function depending on whether
the return value will fit
in a register or not.  This means I'm going to have to do some funky
introspection to determine the
return-value type ahead of time.

2)  Memory management.  ObjC uses reference counting while D is garbage
collected.  So I need to
determine a way to make sure the ObjC runtime and the D garbage collector don't
start fighting over
who needs to delete the objects.

Owen

In article <c72848$90e$1@digitaldaemon.com>, Drew McCormack says...
>
>On 2004-04-26 19:30:21 +0200, resistor@mac.com said:
>
>> Me, I don't do Carbon.  Cocoa forever!
>> 
>> Actually, I've been working on bridging Cocoa/D as well.
>> 
>> Owen
>I'm with you Owen.
>
>How is the bridge going? I guess you have to generate wrapper code, given that D uses static binding, rather than Objective-C's dynamic (run time) one.
>
>I know binding dynamic languages like python and Objective-C is pretty easy because of the introspective features, and ability to create new classes at run-time. Static binding has a performance advantage, which is why I am interested in D for my scientific programming.
>
>Drew
>