Re: C functions
On 18 Oct 2013, at 20:38, Kyle Sluder k...@ksluder.com wrote: CFBundleGetFunctionPointerForName just calls dlsym. Sure. NSLog also eventually calls syslog. I still wouldn’t drop down to syslog for most Cocoa logging needs. CFBundleGetFunctionPointerForName takes a CFStringRef and if you’re e.g. looking at a .framework or other bundled library, it’ll pick out the right executable for you. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On 19 Oct 2013, at 01:17, Shane Stanley sstan...@myriad-com.com.au wrote: On 19 Oct 2013, at 3:15 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: this is what you'd do if you wanted to make e.g. CoreFoundation APIs accessible to a scripting language That's along the lines of what I had in mind, although in this case for basic things like the trig functions in Math.h. So, is this supposed to just directly hand off some standard functions you decide to map into your library, like PHP exposes most of the standard C library? In that case I’d probably just write a little script that generates wrappers that translate between your language’s calling convention and the one of the C library, and enter them in a global variable with a struct that maps the plain-text name to the function pointer. Whether you actually want to regex-parse the headers (like I did here for my Hammer programming language: https://github.com/uliwitness/Forge/blob/master/headerimport.php) or whether you want to just hand-write a short, easily parsed list of the functions and their argument types is up to you. The latter requires less maintenance if you plan to only selectively import a few native calls, as regex-parsing of C/ObjC headers is rather optimistic and tends to break every couple of system releases. If you, on the other hand, want to support creation of actual headers by users of your language and adding of new functions w/o recompiling, you’re prolly best off with a foreign function interface like libffi. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://stacksmith.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
Le 19 oct. 2013 à 15:01, Uli Kusterer witness.of.teacht...@gmx.net a écrit : On 19 Oct 2013, at 01:17, Shane Stanley sstan...@myriad-com.com.au wrote: On 19 Oct 2013, at 3:15 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: this is what you'd do if you wanted to make e.g. CoreFoundation APIs accessible to a scripting language That's along the lines of what I had in mind, although in this case for basic things like the trig functions in Math.h. So, is this supposed to just directly hand off some standard functions you decide to map into your library, like PHP exposes most of the standard C library? In that case I’d probably just write a little script that generates wrappers that translate between your language’s calling convention and the one of the C library, and enter them in a global variable with a struct that maps the plain-text name to the function pointer. Whether you actually want to regex-parse the headers (like I did here for my Hammer programming language: https://github.com/uliwitness/Forge/blob/master/headerimport.php) or whether you want to just hand-write a short, easily parsed list of the functions and their argument types is up to you. The latter requires less maintenance if you plan to only selectively import a few native calls, as regex-parsing of C/ObjC headers is rather optimistic and tends to break every couple of system releases. To parse C/Obj-C/C++ headers, you can also use libclang which is design to do that. I used it to parse C header and generate boilerplate code some times ago, and it worked quite well with very few code to write on my side. If you, on the other hand, want to support creation of actual headers by users of your language and adding of new functions w/o recompiling, you’re prolly best off with a foreign function interface like libffi. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://stacksmith.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
libclang is more than that. Xcode code highlighting and code indexing is based on lib clang, as well as delta compilation. (and I have a remote plan of cloning Xcode for GNUstep) Also, there was a friend of mine that created a translator that converts code from a new language to C, and I modified it to plug libclang at its output and that made it a full compiler that emits object files (and links) On Oct 19, 2013, at 23:43, Jean-Daniel Dupas devli...@shadowlab.org wrote: Le 19 oct. 2013 à 15:01, Uli Kusterer witness.of.teacht...@gmx.net a écrit : On 19 Oct 2013, at 01:17, Shane Stanley sstan...@myriad-com.com.au wrote: On 19 Oct 2013, at 3:15 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: this is what you'd do if you wanted to make e.g. CoreFoundation APIs accessible to a scripting language That's along the lines of what I had in mind, although in this case for basic things like the trig functions in Math.h. So, is this supposed to just directly hand off some standard functions you decide to map into your library, like PHP exposes most of the standard C library? In that case I’d probably just write a little script that generates wrappers that translate between your language’s calling convention and the one of the C library, and enter them in a global variable with a struct that maps the plain-text name to the function pointer. Whether you actually want to regex-parse the headers (like I did here for my Hammer programming language: https://github.com/uliwitness/Forge/blob/master/headerimport.php) or whether you want to just hand-write a short, easily parsed list of the functions and their argument types is up to you. The latter requires less maintenance if you plan to only selectively import a few native calls, as regex-parsing of C/ObjC headers is rather optimistic and tends to break every couple of system releases. To parse C/Obj-C/C++ headers, you can also use libclang which is design to do that. I used it to parse C header and generate boilerplate code some times ago, and it worked quite well with very few code to write on my side. If you, on the other hand, want to support creation of actual headers by users of your language and adding of new functions w/o recompiling, you’re prolly best off with a foreign function interface like libffi. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://stacksmith.org ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org This email sent to devli...@shadowlab.org -- Jean-Daniel ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com This email sent to xcvi...@me.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Oct 17, 2013, at 8:49 PM, Charles Srstka cocoa...@charlessoft.com wrote: You shouldn't rely on dlsym() working in production code. If the binary is stripped (as it is by default for release builds, I believe), it won't work. You could work around that by exporting the symbol, e.g. by adding it to a “.exp” file. And if the function comes from a library’s API, it’ll by definition be available. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Oct 18, 2013, at 4:48 AM, Shane Stanley sstan...@myriad-com.com.au wrote: is there any way to build a call to a C function on the fly? I mean something like pass a string to a method, and have it call the function of that name? Short: No. Long: Maybe. 1) You can put a function in a dynamic library and export it, and load that library. If you know its signature, you can then call it. 2) You can build a look-up table of name - function pointer mappings inside your application, then look up the function pointer by name and call it. You'd need to know its signature then, too. 3) You can build a dynamic library that has this function as its main entry point and call that. Essentially a variant of #1. You'll still need to know its signature beforehand then 4) You can use a library like libffi to call a function pointer (using the methods in #1 through #3 to get one from a name) even without knowing its calling conventions beforehand. As long as you know the signature the moment you're calling it and have the proper values, that'll work (this is what you'd do if you wanted to make e.g. CoreFoundation APIs accessible to a scripting language) Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On 2013 Oct 18,, at 04:48, Shane Stanley sstan...@myriad-com.com.au wrote: is there any way to build a call to a C function on the fly? I mean something like pass a string to a method, and have it call the function of that name? This at least used to be shown in the Objective-C 2.0 Runtime Programming Guide. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Oct 18, 2013, at 6:15 AM, Dmitry Markman dmark...@me.com wrote:
I don't thinks strip remove info used by dynamic linker
Thus dlsym should work
As long as symbol is external (not with hidden visibility) dlsym is able to
find the symbol
(stripped or not)
Not in my testing:
#import Foundation/Foundation.h
#include dlfcn.h
void foo() {
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSLog(@The correct address is %p, foo);
NSLog(@dlsym returns %p, dlsym(RTLD_SELF, foo));
}
return 0;
}
In debug mode:
2013-10-18 12:16:37.027 dlsymtest[95106:303] The correct address is 0x10e40
2013-10-18 12:16:37.031 dlsymtest[95106:303] dlsym returns 0x10e40
Program ended with exit code: 0
Doing an Archive in Xcode and running the resulting binary in the Terminal:
2013-10-18 12:17:17.891 dlsymtest[95151:707] The correct address is 0x10574fe6a
2013-10-18 12:17:17.902 dlsymtest[95151:707] dlsym returns 0x0
It won't work with the default build settings. Other commenters are correct,
however, that it can work if you move the symbols you want to look up into a
library.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: C functions
On Oct 18, 2013, at 6:15 AM, Dmitry Markman dmark...@me.com wrote:
I don't thinks strip remove info used by dynamic linker
Thus dlsym should work
As long as symbol is external (not with hidden visibility) dlsym is able to
find the symbol
(stripped or not)
Trying to set the symbol to external doesn't seem to change things:
#import Foundation/Foundation.h
#include dlfcn.h
extern __attribute__((visibility(default))) void foo() {
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSLog(@The correct address is %p, foo);
NSLog(@dlsym returns %p, dlsym(RTLD_SELF, foo));
}
return 0;
}
Debug mode:
2013-10-18 12:28:41.565 dlsymtest[95471:303] The correct address is 0x10e40
2013-10-18 12:28:41.576 dlsymtest[95471:303] dlsym returns 0x10e40
Archived:
2013-10-18 12:30:42.232 dlsymtest[95518:707] The correct address is 0x10cd74e6a
2013-10-18 12:30:42.236 dlsymtest[95518:707] dlsym returns 0x0
Looking at the Mach-O binary, _foo is listed as an external symbol in the
binary built in Debug mode, but not for the archived binary. It may be that the
strip program removes external symbols that it sees as unnecessary.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: C functions
On Oct 18, 2013, at 6:15 PM, Uli Kusterer witness.of.teacht...@gmx.net wrote: On Oct 18, 2013, at 4:48 AM, Shane Stanley sstan...@myriad-com.com.au wrote: is there any way to build a call to a C function on the fly? I mean something like pass a string to a method, and have it call the function of that name? Short: No. Long: Maybe. 1) You can put a function in a dynamic library and export it, and load that library. If you know its signature, you can then call it. 2) You can build a look-up table of name - function pointer mappings inside your application, then look up the function pointer by name and call it. You'd need to know its signature then, too. 3) You can build a dynamic library that has this function as its main entry point and call that. Essentially a variant of #1. You'll still need to know its signature beforehand then 4) You can use a library like libffi to call a function pointer (using the methods in #1 through #3 to get one from a name) even without knowing its calling conventions beforehand. As long as you know the signature the moment you're calling it and have the proper values, that'll work (this is what you'd do if you wanted to make e.g. CoreFoundation APIs accessible to a scripting language) Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de Oh, one more thing: Instead of dlsym(), you can also use CFBundleGetFunctionPointerForName() and its cohorts might also be useful for this if you want to go a bit more high-level. But even then, it needs to be an exported symbol in a dylib, can't be just any internal function. Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... http://www.zathras.de ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Fri, Oct 18, 2013, at 10:39 AM, Uli Kusterer wrote: Oh, one more thing: Instead of dlsym(), you can also use CFBundleGetFunctionPointerForName() and its cohorts might also be useful for this if you want to go a bit more high-level. But even then, it needs to be an exported symbol in a dylib, can't be just any internal function. CFBundleGetFunctionPointerForName just calls dlsym. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On 19 Oct 2013, at 3:15 AM, Uli Kusterer witness.of.teacht...@gmx.net wrote: this is what you'd do if you wanted to make e.g. CoreFoundation APIs accessible to a scripting language That's along the lines of what I had in mind, although in this case for basic things like the trig functions in Math.h. -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
Try add this line:
extern void foo(void);
Sent from my iPhone
On 2013年10月19日, at 1:21, Charles Srstka cocoa...@charlessoft.com wrote:
On Oct 18, 2013, at 6:15 AM, Dmitry Markman dmark...@me.com wrote:
I don't thinks strip remove info used by dynamic linker
Thus dlsym should work
As long as symbol is external (not with hidden visibility) dlsym is able to
find the symbol
(stripped or not)
Not in my testing:
#import Foundation/Foundation.h
#include dlfcn.h
void foo() {
}
int main(int argc, const char * argv[]) {
@autoreleasepool {
NSLog(@The correct address is %p, foo);
NSLog(@dlsym returns %p, dlsym(RTLD_SELF, foo));
}
return 0;
}
In debug mode:
2013-10-18 12:16:37.027 dlsymtest[95106:303] The correct address is
0x10e40
2013-10-18 12:16:37.031 dlsymtest[95106:303] dlsym returns 0x10e40
Program ended with exit code: 0
Doing an Archive in Xcode and running the resulting binary in the Terminal:
2013-10-18 12:17:17.891 dlsymtest[95151:707] The correct address is
0x10574fe6a
2013-10-18 12:17:17.902 dlsymtest[95151:707] dlsym returns 0x0
It won't work with the default build settings. Other commenters are correct,
however, that it can work if you move the symbols you want to look up into a
library.
Charles
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: C functions
On Oct 18, 2013, at 6:42 PM, ChanMaxthon xcvi...@me.com wrote: Try add this line: extern void foo(void); Already did; it doesn't work. See my follow-up post. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
I think I know why it did not work: strip command can remove debug symbols, or unused functions as well. Sent from my iPhone On 2013年10月19日, at 7:53, Charles Srstka cocoa...@charlessoft.com wrote: On Oct 18, 2013, at 6:42 PM, ChanMaxthon xcvi...@me.com wrote: Try add this line: extern void foo(void); Already did; it doesn't work. See my follow-up post. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Oct 18, 2013, at 7:30 PM, ChanMaxthon xcvi...@me.com wrote: I think I know why it did not work: strip command can remove debug symbols, or unused functions as well. Yep. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
C functions
is there any way to build a call to a C function on the fly? I mean something like pass a string to a method, and have it call the function of that name? -- Shane Stanley sstan...@myriad-com.com.au 'AppleScriptObjC Explored' www.macosxautomation.com/applescript/apps/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Oct 17, 2013, at 9:48 PM, Shane Stanley sstan...@myriad-com.com.au wrote: is there any way to build a call to a C function on the fly? I mean something like pass a string to a method, and have it call the function of that name? No. That's an Objective-C feature that's not present in standard C. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
You actually can, by using dlsym(3) to resolve the symbol, cast it to the appropriate function pointer and call it. For example: int (*myfunc)(int, int) = dlsym(RTLD_DEFAULT, myfunc_name); if (myfunc) printf(“%d”, myfunc(2, 3)); else fprintf(stderr, “error: cannot resolve symbol: %s”, myfunc_name); This works on all POSIX operating systems. On Oct 18, 2013, at 11:34, Charles Srstka cocoa...@charlessoft.com wrote: On Oct 17, 2013, at 9:48 PM, Shane Stanley sstan...@myriad-com.com.au wrote: is there any way to build a call to a C function on the fly? I mean something like pass a string to a method, and have it call the function of that name? No. That's an Objective-C feature that's not present in standard C. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/xcvista%40me.com This email sent to xcvi...@me.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
On Oct 17, 2013, at 10:40 PM, Maxthon Chan xcvi...@me.com wrote: You actually can, by using dlsym(3) to resolve the symbol, cast it to the appropriate function pointer and call it. For example: int (*myfunc)(int, int) = dlsym(RTLD_DEFAULT, myfunc_name); if (myfunc) printf(“%d”, myfunc(2, 3)); else fprintf(stderr, “error: cannot resolve symbol: %s”, myfunc_name); This works on all POSIX operating systems. You shouldn't rely on dlsym() working in production code. If the binary is stripped (as it is by default for release builds, I believe), it won't work. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: C functions
You can certainly move everything into a library, also you can prevent executables from being stripped in Xcode. Sent from my iPhone On 2013年10月18日, at 11:54, Charles Srstka cocoa...@charlessoft.com wrote: Loadable bundles and libraries don't get stripped. Executables, since they don't need to be loaded by another process, usually are. Charles On Oct 17, 2013, at 10:51 PM, ChanMaxthon xcvi...@me.com wrote: Then, problem, how did Core Foundation bundle loading work? Sent from my iPhone On 2013年10月18日, at 11:49, Charles Srstka cocoa...@charlessoft.com wrote: On Oct 17, 2013, at 10:40 PM, Maxthon Chan xcvi...@me.com wrote: You actually can, by using dlsym(3) to resolve the symbol, cast it to the appropriate function pointer and call it. For example: int (*myfunc)(int, int) = dlsym(RTLD_DEFAULT, myfunc_name); if (myfunc) printf(“%d”, myfunc(2, 3)); else fprintf(stderr, “error: cannot resolve symbol: %s”, myfunc_name); This works on all POSIX operating systems. You shouldn't rely on dlsym() working in production code. If the binary is stripped (as it is by default for release builds, I believe), it won't work. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Working with C-functions in separate NSThreads: via Stack or Heap?
My original reply was too long for Cocoa Dev; then I lost it.
So this is another (small draft)...
It appears I'll be working with blocks, keeping the data/functioning local
to the stack copying data out to the GUI:
typedef sat_t (^MyBlock)();
// C - function:
int addFoot(int k) {
return (++k);
}
// Block declaration:
MyBlock MakeSat() {
__block sat_t sat;
__block tle_t tle;
__block int k = 0;
return Block_copy( ^ {
sat.satName = George;
sat.tsince += 1.0;
k = addFoot(k);
sat.footprint = k;
predict_calc1(2); // ok.
predict_calc2(sat, 2); //...passing struct{} ptr.
return sat;
});
} // end MyBlock().
//
int main(void) {
MyBlock myBlock = MakeSat();
printf(\nMyBlock value: %s, since= %g, addFoot= %g TLE name= %s\n,
myBlock().satName, myBlock().tsince, myBlock().footprint,
myBlock().tle.name);
Block_release(myBlock);
return 0;
}
---
Output:
MyBlock value: Henry, since= 3, addFoot= 2 TLE name= Frederick C. Lee
... So I'll work with your (B) paradigm: keep the data 'regional' w/in a block.
That way, I can pass the data amongst functions w/in a block and copy
the result to the 'outside' calling ObjC object.
Ric.
On Nov 6, 2010, at 11:24 AM, lwj wrote:
There it too much missing here to really understand whats going on. There is
no context for 'sat_t workingSat'. This can mean very different things
depending on where it is. When initSatWorkArea(workingSat) is called you
are passing a pointer to workingSat and not the structure itself.
Based on what you have above I think there are 2 possibilities for where
workingSat 'lives'.
A.)
sat_t workingSat;
void someFunc(void) {
initSatWorkArea(workingSat);
...
}
In this case workingSat exists in the data section (neither heap nor stack)
of your program. There is *only* 1 of them. You can share it between threads
but every thread will see the same thing. Unless you want every thread
working on the same thing this is *not* what you want.
B.)
void someFunc(void) {
sat_t workingSat;
initSatWorkArea(workingSat);
...
}
In this case workingSat exists on the stack. A new one is created every time
someFunc is called. *However*, when someFunc() returns workingSat *NO LONGER
EXISTS*. From your description it sounds like initSatWorkArea might pass a
pointer to workingSat to a thread but workingSat goes away once someFunc
returns.
There is a good chance that neither one of these is what you want.
Wayne
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Working with C-functions in separate NSThreads: via Stack or Heap?
Environment: iOS SDK 4.2+
Xcode 3.2.5
Desired design:
1) Multiple NSThreads (via NSOperation?) running NSObjects in parallel:
processing the same C-functions (with different data) in real time till
conclusion (or cancelled).
2) These C-functions are located in a common *.c file (or two); could (
probably shall) be in *.m files instead.
3) C-based data results are displayed updated (e.g.,a counter) with IB per
each iteration (with option to wait till conclusion, then displayed).
Greetings:
I need to interface between an instantiated NSObject with ANSI-C (shall be
C99+ in Xcode) functions (within member *.c files).
I'll probably change these *.c files to *.m files.
On the surface, all is okay.
I can pass a typedef struct thusly (malloc isn't used, straight call
receive):
typedef struct {
char *satName;
char *satCategory;
char *website;
...
...
} sat_t;
--
sat_t workingSat;
...
initSatWorkArea(workingSat); --- a NSObject's method (in head) is accessing
a C-function (on stack)?
However, I'm concerned about memory usage stability.
Am I correct that these C functions are within the Stack vs Heap...
...and thus these C-functions (in the stack) are accessed from the heap (from
within an instantiated NSObject). Correct?
1) Does that mean the data generated from these C-functions will be
popped/released, once exit from the calling Objective-C method?
2) I assume it doesn't matter where these C-functions are located, from within
an instantiated NSObject or from a member *.c file (via #import); behavior is
the same.
3) Do I need to hassle with malloc() for C-structures that are passed between
the calling instantiated NSObject?
Note: I need to keep these C-based calculations continuous (with option to
display the changing results in the foreground (IB GUI)); within their
respective threads (could be only 1 thread).
4) Would using blocks be the ideal (Apple-recommended) way of doing this?
Regards,
Ric.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Testing C functions using OCUnit
In my projects, I tend to define methods which need access to member
variables as class methods, and related functions, which do not need
direct access to any internal object data, as C functions, like the
simple example below.
@implementation FunctionTestAppController
+ (id) sharedController
{
return [NSApp delegate];
}
- (BOOL) someMethod
{
// would normally access some ivar.
return YES;
}
@end
BOOL SomeFunction()
{
return YES;
}
I've recently been implementing unit testing, following
http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html
- i.e. the main app binary is specified as the bundle loader, and
testing is done via injection of the unit test bundle, with a clear
separation between application and test code.
Everything works fine for objective-C methods, but I get linker errors
when I try and reference any of the C functions defined in my
application code. nm reveals that the symbols are present in the app
binary, but the linker doesn't seem to be able to see them.
Is there a recommended, or even a good way, to get the test code to
link correctly to the applications C functions?
--
http://www.mildmanneredindustries.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Testing C functions using OCUnit
On Feb 15, 2009, at 10:32 AM, Martin Redington wrote:
In my projects, I tend to define methods which need access to member
variables as class methods, and related functions, which do not need
direct access to any internal object data, as C functions, like the
simple example below.
@implementation FunctionTestAppController
+ (id) sharedController
{
return [NSApp delegate];
}
- (BOOL) someMethod
{
// would normally access some ivar.
return YES;
}
@end
BOOL SomeFunction()
{
return YES;
}
I've recently been implementing unit testing, following
http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html
- i.e. the main app binary is specified as the bundle loader, and
testing is done via injection of the unit test bundle, with a clear
separation between application and test code.
Everything works fine for objective-C methods, but I get linker errors
when I try and reference any of the C functions defined in my
application code. nm reveals that the symbols are present in the app
binary, but the linker doesn't seem to be able to see them.
Is there a recommended, or even a good way, to get the test code to
link correctly to the applications C functions?
What does `nm -m` say? It's likely that your C function's symbol is
present but marked non-external, which means it's available for
debuggers but not for linking. (`nm` alone provides a single-letter
description of the symbol, and `nm -m` prints the description in human-
readable form.)
If that's the case, you can change your executable's symbol management
in Xcode. I think the options are to provided an exported-symbol list
that names the C functions explicitly, or change the stripping level
to none so they're all available. You should do this only for testing
purposes and not for your final release configuration; keeping symbols
hidde makes your app launch a little faster.
(The Objective-C code probably works because the C linker is mostly
not used for 32-bit Objective-C linking. But it's likely that a 64-bit
version of your app would run into the same problem for Objective-C
code.)
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Testing C functions using OCUnit
Thanks very much for the quick reply. It looks like the code
generation option symbols hidden by default is the one that needs to
be turned off. I was looking under stripping before.
After turning that setting off, 'nm -m' reports
1f9c (__TEXT,__text) external _SomeFunction
instead of
1f9c (__TEXT,__text) non-external (was a private external) _SomeFunction
and linking succeeds ...
On Sun, Feb 15, 2009 at 6:50 PM, Greg Parker gpar...@apple.com wrote:
On Feb 15, 2009, at 10:32 AM, Martin Redington wrote:
In my projects, I tend to define methods which need access to member
variables as class methods, and related functions, which do not need
direct access to any internal object data, as C functions, like the
simple example below.
@implementation FunctionTestAppController
+ (id) sharedController
{
return [NSApp delegate];
}
- (BOOL) someMethod
{
// would normally access some ivar.
return YES;
}
@end
BOOL SomeFunction()
{
return YES;
}
I've recently been implementing unit testing, following
http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html
- i.e. the main app binary is specified as the bundle loader, and
testing is done via injection of the unit test bundle, with a clear
separation between application and test code.
Everything works fine for objective-C methods, but I get linker errors
when I try and reference any of the C functions defined in my
application code. nm reveals that the symbols are present in the app
binary, but the linker doesn't seem to be able to see them.
Is there a recommended, or even a good way, to get the test code to
link correctly to the applications C functions?
What does `nm -m` say? It's likely that your C function's symbol is present
but marked non-external, which means it's available for debuggers but not
for linking. (`nm` alone provides a single-letter description of the symbol,
and `nm -m` prints the description in human-readable form.)
If that's the case, you can change your executable's symbol management in
Xcode. I think the options are to provided an exported-symbol list that
names the C functions explicitly, or change the stripping level to none so
they're all available. You should do this only for testing purposes and not
for your final release configuration; keeping symbols hidde makes your app
launch a little faster.
(The Objective-C code probably works because the C linker is mostly not used
for 32-bit Objective-C linking. But it's likely that a 64-bit version of
your app would run into the same problem for Objective-C code.)
--
Greg Parker gpar...@apple.com Runtime Wrangler
--
http://www.mildmanneredindustries.com/
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Testing C functions using OCUnit
On Feb 15, 2009, at 1:32 PM, Martin Redington wrote:
In my projects, I tend to define methods which need access to member
variables as class methods, and related functions, which do not need
direct access to any internal object data, as C functions, like the
simple example below.
@implementation FunctionTestAppController
+ (id) sharedController
{
return [NSApp delegate];
}
- (BOOL) someMethod
{
// would normally access some ivar.
return YES;
}
@end
BOOL SomeFunction()
{
return YES;
}
I've recently been implementing unit testing, following
http://developer.apple.com/mac/articles/tools/unittestingwithxcode3.html
- i.e. the main app binary is specified as the bundle loader, and
testing is done via injection of the unit test bundle, with a clear
separation between application and test code.
Everything works fine for objective-C methods, but I get linker errors
when I try and reference any of the C functions defined in my
application code. nm reveals that the symbols are present in the app
binary, but the linker doesn't seem to be able to see them.
Is there a recommended, or even a good way, to get the test code to
link correctly to the applications C functions?
That's really bad OO design. One of the reasons is the one you face
now. Testing it. Rewrite them correctly as instance methods, then
test.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Wrapping C functions in Objective C proxy objects: naming convention?
Austin,
I’d go for #1.
If you have an error in status, throw an exception.
What is the reason to put those functions in a class anyway if you
just mimic the c-function? Are you adding anything?
atze
Am 20.11.2008 um 06:27 schrieb Austin Ziegler:
For a project that I'm working on, I have a need to write a code
generator that will wrap certain kinds of C functions as Objective C
messages on an Objective C proxy. Because I don't ultimately control
the input, the parameters on the C functions may be poorly named. I'm
looking for advice on how one might make useful object message names
from C functions.
The format of the functions in question is essentially like this[1]:
int ns__add(double a, double b, double *result);
int ns__sub(double a, double b, double *result);
int ns__mul(double a, double b, double *result);
int ns__div(double a, double b, double *result);
int ns__pow(double a, double b, double *result);
The int return is a status code; the result of the operation is in
double* result. If there's an error in the operation. (The status code
may be ignorable, in which case part of my following question is
answered; I'm still researching this part. I suspect that it is best
not ignored.)
Anyway, the problem is how I should convert this function with poorly
named parameters into a proxy object and messages?
The options that I've come up with (expressed in terms of use) follow.
They're all expressed in terms of an object ns__CalcProxy:
ns__CalcProxy calc = [[ns__CalcProxy alloc] init];
double a, b, result;
int status;
result = [calc addDoubleA:a withDoubleB:b]; // #1
result = [calc addDoubleA:a withDoubleB:b status:status]; // #2
status = [calc addDoubleA:a withDoubleB:b returning:result]; // #3
The examples given here are simple; the items being returned may in
fact be pretty complex (and I'm planning on making it so that
structured parameters and return values may be passed in Objective C
proxies themselves).
I really don't like the addDoubleA:withDoubleB: name, to be honest,
but what am I supposed to do with:
struct ns1__ludcmpResponse {matrix *a; ivector *i; xsd__double d;};
int ns1__ludcmp(matrix *a, struct ns1__ludcmpResponse** result);
Like I said; I don't really have any control over the names of the
parameters, more's the pity.
-austin
[1] Actually, they're more like this:
int soap_call_ns__add(struct soap *soap, const char *soap_endpoint,
const char *soap_action, double a, double b, double *result);
But there's enough information in there for me to extract the former
to use as a proxy function.
--
Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/
* [EMAIL PROTECTED] * http://www.halostatue.ca/feed/
* [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de
This email sent to [EMAIL PROTECTED]
---
Alexander Spohr
Freeport Soliversum
Fax: +49 40 303 757 99
Web: http://www.freeport.de/
Box: http://dropbox.letsfile.com/02145299-4347-4671-aab9-1d3004eac51d
---
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Thu, Nov 20, 2008 at 4:54 AM, Alexander Spohr [EMAIL PROTECTED] wrote:
I'd go for #1.
If you have an error in status, throw an exception.
What is the reason to put those functions in a class anyway if you just
mimic the c-function? Are you adding anything?
Yes, I am. The C function definition that I showed was actually just a
SOAP service definition. What my proxy object will be calling are
about three or four different C functions to make the SOAP call,
hiding that complexity from the programmer. (I could just use C++ and
have this code generated for me automatically, but this is also an
intellectual challenge to generate these Objective C wrappers that
mimic what the C++ code does.)
-austin
Am 20.11.2008 um 06:27 schrieb Austin Ziegler:
For a project that I'm working on, I have a need to write a code
generator that will wrap certain kinds of C functions as Objective C
messages on an Objective C proxy. Because I don't ultimately control
the input, the parameters on the C functions may be poorly named. I'm
looking for advice on how one might make useful object message names
from C functions.
The format of the functions in question is essentially like this[1]:
int ns__add(double a, double b, double *result);
int ns__sub(double a, double b, double *result);
int ns__mul(double a, double b, double *result);
int ns__div(double a, double b, double *result);
int ns__pow(double a, double b, double *result);
The int return is a status code; the result of the operation is in
double* result. If there's an error in the operation. (The status code
may be ignorable, in which case part of my following question is
answered; I'm still researching this part. I suspect that it is best
not ignored.)
Anyway, the problem is how I should convert this function with poorly
named parameters into a proxy object and messages?
The options that I've come up with (expressed in terms of use) follow.
They're all expressed in terms of an object ns__CalcProxy:
ns__CalcProxy calc = [[ns__CalcProxy alloc] init];
double a, b, result;
int status;
result = [calc addDoubleA:a withDoubleB:b]; // #1
result = [calc addDoubleA:a withDoubleB:b status:status]; // #2
status = [calc addDoubleA:a withDoubleB:b returning:result]; // #3
The examples given here are simple; the items being returned may in
fact be pretty complex (and I'm planning on making it so that
structured parameters and return values may be passed in Objective C
proxies themselves).
I really don't like the addDoubleA:withDoubleB: name, to be honest,
but what am I supposed to do with:
struct ns1__ludcmpResponse {matrix *a; ivector *i; xsd__double d;};
int ns1__ludcmp(matrix *a, struct ns1__ludcmpResponse** result);
Like I said; I don't really have any control over the names of the
parameters, more's the pity.
-austin
[1] Actually, they're more like this:
int soap_call_ns__add(struct soap *soap, const char *soap_endpoint,
const char *soap_action, double a, double b, double *result);
But there's enough information in there for me to extract the former
to use as a proxy function.
--
Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/
* [EMAIL PROTECTED] * http://www.halostatue.ca/feed/
* [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/atze%40freeport.de
This email sent to [EMAIL PROTECTED]
---
Alexander Spohr
Freeport Soliversum
Fax: +49 40 303 757 99
Web: http://www.freeport.de/
Box: http://dropbox.letsfile.com/02145299-4347-4671-aab9-1d3004eac51d
---
--
Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/
* [EMAIL PROTECTED] * http://www.halostatue.ca/feed/
* [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 6:58 AM, Austin Ziegler wrote: result = [calc addDoubleA:a withDoubleB:b]; // #1 Why not -addDouble:withDouble: ? That is, why are you promoting the argument names into the method signature? Especially since you're aware that the names are (most often) useless. result = [calc addDoubleA:a withDoubleB:b status:status]; // #2 status = [calc addDoubleA:a withDoubleB:b returning:result]; // #3 These forms might also make sense, but I'd still leave out the 'A' and 'B'. I believe that Apple's naming conventions suggest that, when a method outputs multiple values, they should all be output parameters and none should be via return value. Also, Apple has been migrating towards using NSError objects output via parameter to handle status. So, you might want to do the same. http://developer.apple.com/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html Cheers, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 10:54 AM, Alexander Spohr wrote: I’d go for #1. If you have an error in status, throw an exception. In this case, an exception might actually be OK, given that the library is in isolation. However, it goes against the design patterns of Cocoa and if the code is ever refactored such that there are Foundation or AppKit frames on the stack over which the exception is thrown, the code may break. Exceptions for non-programmer error are to be avoided. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Thu, Nov 20, 2008 at 12:27 AM, Austin Ziegler [EMAIL PROTECTED] wrote: For a project that I'm working on, I have a need to write a code generator that will wrap certain kinds of C functions as Objective C messages on an Objective C proxy. Because I don't ultimately control the input, the parameters on the C functions may be poorly named. I'm looking for advice on how one might make useful object message names from C functions. The format of the functions in question is essentially like this[1]: int ns__add(double a, double b, double *result); int ns__sub(double a, double b, double *result); int ns__mul(double a, double b, double *result); int ns__div(double a, double b, double *result); int ns__pow(double a, double b, double *result); The int return is a status code; the result of the operation is in double* result. If there's an error in the operation. (The status code may be ignorable, in which case part of my following question is answered; I'm still researching this part. I suspect that it is best not ignored.) Anyway, the problem is how I should convert this function with poorly named parameters into a proxy object and messages? The options that I've come up with (expressed in terms of use) follow. They're all expressed in terms of an object ns__CalcProxy: ns__CalcProxy calc = [[ns__CalcProxy alloc] init]; double a, b, result; int status; result = [calc addDoubleA:a withDoubleB:b]; // #1 result = [calc addDoubleA:a withDoubleB:b status:status]; // #2 status = [calc addDoubleA:a withDoubleB:b returning:result]; // #3 Please excuse a foolish question, but Why wrap this in Objective-C at all? Looks like the resulting ObjC code is essentially the same, except uglier, slower, and harder to use. Why not just keep the C and use it directly? Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Thu, Nov 20, 2008 at 12:15 PM, Michael Ash [EMAIL PROTECTED] wrote:
Please excuse a foolish question, but Why wrap this in Objective-C
at all? Looks like the resulting ObjC code is essentially the same,
except uglier, slower, and harder to use. Why not just keep the C and
use it directly?
This isn't a foolish question. The function declaration that I've shown
you is something of a fiction; it's a definition in an input file to a
code generator (gSOAP). It doesn't actually exist in the resulting C
code. This definition:
int ns__add(double a, double b, double *result);
will actually become:
int soap_call_ns__add(struct soap *soap, const char *endpoint,
const char *action, double a, double b,
double result*);
gSOAP knows how to generate C and C++ and with C++ will generate a proxy
for this C function and the SOAP object, so that it looks more like:
class calcProxy
{
public:
int add(double a, double b, double *result)
{
return soap_call_ns__add(soap, endpoint, , a, b, result);
}
struct soap *soap;
char *endpoint;
}
What I want to do is to create an ObjC proxy similar to the C++ proxy.
Yes, I know I could use ObjC++, but there are reasons I want to use ObjC
instead of ObjC++ including not having to deal with two different object
models in my ObjC programs.
Generating the proxy isn't going to be that hard; I'm just trying to
figure out what the best naming conventions for these generated methods
and classes will be.
-austin
--
Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/
* [EMAIL PROTECTED] * http://www.halostatue.ca/feed/
* [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 19, 2008, at 9:27 PM, Austin Ziegler wrote: For a project that I'm working on, I have a need to write a code generator that will wrap certain kinds of C functions as Objective C messages on an Objective C proxy. Because I don't ultimately control the input, the parameters on the C functions may be poorly named. I'm looking for advice on how one might make useful object message names from C functions. Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Thu, Nov 20, 2008 at 1:23 PM, Jonathon Kuo [EMAIL PROTECTED] wrote: Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. It is common, if not appropriate, to have utility classes (often ones with just class methods) that provide functions for others to use. At a minimum it allows you to namespace sets of utility methods. -Shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
Just out of curiosity, why do you need to send such common math
operations to a soap request? Wouldn't it be easier to do simple stuff
like calculations in your Soap class and only make requests for the
unique services the endpoint provides?
On Nov 20, 2008, at 12:27 AM, Austin Ziegler wrote:
For a project that I'm working on, I have a need to write a code
generator that will wrap certain kinds of C functions as Objective C
messages on an Objective C proxy. Because I don't ultimately control
the input, the parameters on the C functions may be poorly named. I'm
looking for advice on how one might make useful object message names
from C functions.
The format of the functions in question is essentially like this[1]:
int ns__add(double a, double b, double *result);
int ns__sub(double a, double b, double *result);
int ns__mul(double a, double b, double *result);
int ns__div(double a, double b, double *result);
int ns__pow(double a, double b, double *result);
The int return is a status code; the result of the operation is in
double* result. If there's an error in the operation. (The status code
may be ignorable, in which case part of my following question is
answered; I'm still researching this part. I suspect that it is best
not ignored.)
Anyway, the problem is how I should convert this function with poorly
named parameters into a proxy object and messages?
The options that I've come up with (expressed in terms of use) follow.
They're all expressed in terms of an object ns__CalcProxy:
ns__CalcProxy calc = [[ns__CalcProxy alloc] init];
double a, b, result;
int status;
result = [calc addDoubleA:a withDoubleB:b]; // #1
result = [calc addDoubleA:a withDoubleB:b status:status]; // #2
status = [calc addDoubleA:a withDoubleB:b returning:result]; // #3
The examples given here are simple; the items being returned may in
fact be pretty complex (and I'm planning on making it so that
structured parameters and return values may be passed in Objective C
proxies themselves).
I really don't like the addDoubleA:withDoubleB: name, to be honest,
but what am I supposed to do with:
struct ns1__ludcmpResponse {matrix *a; ivector *i; xsd__double d;};
int ns1__ludcmp(matrix *a, struct ns1__ludcmpResponse** result);
Like I said; I don't really have any control over the names of the
parameters, more's the pity.
-austin
[1] Actually, they're more like this:
int soap_call_ns__add(struct soap *soap, const char *soap_endpoint,
const char *soap_action, double a, double b, double *result);
But there's enough information in there for me to extract the former
to use as a proxy function.
--
Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/
* [EMAIL PROTECTED] * http://www.halostatue.ca/feed/
* [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/kentozier%40comcast.net
This email sent to [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 2:07 PM, Shawn Erickson wrote: On Thu, Nov 20, 2008 at 1:23 PM, Jonathon Kuo [EMAIL PROTECTED] wrote: Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. It is common, if not appropriate, to have utility classes (often ones with just class methods) that provide functions for others to use. At a minimum it allows you to namespace sets of utility methods. Exactly, as classes aren't objects. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 5:58 PM, Jonathon Kuo wrote: On Nov 20, 2008, at 2:07 PM, Shawn Erickson wrote: On Thu, Nov 20, 2008 at 1:23 PM, Jonathon Kuo [EMAIL PROTECTED] wrote: Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. It is common, if not appropriate, to have utility classes (often ones with just class methods) that provide functions for others to use. At a minimum it allows you to namespace sets of utility methods. Exactly, as classes aren't objects. Yes they are - in Objective-C, anyway. Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 5:06 PM, Charles Srstka wrote: On Nov 20, 2008, at 5:58 PM, Jonathon Kuo wrote: On Nov 20, 2008, at 2:07 PM, Shawn Erickson wrote: On Thu, Nov 20, 2008 at 1:23 PM, Jonathon Kuo [EMAIL PROTECTED] wrote: Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. It is common, if not appropriate, to have utility classes (often ones with just class methods) that provide functions for others to use. At a minimum it allows you to namespace sets of utility methods. Exactly, as classes aren't objects. Yes they are - in Objective-C, anyway. Oops, my bad. Meant to say classes aren't instantiated objects (and thus they have no context or state, and so are appropriate for library- type functions, etc.) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 7:40 PM, Jonathon Kuo wrote: On Nov 20, 2008, at 5:06 PM, Charles Srstka wrote: On Nov 20, 2008, at 5:58 PM, Jonathon Kuo wrote: On Nov 20, 2008, at 2:07 PM, Shawn Erickson wrote: On Thu, Nov 20, 2008 at 1:23 PM, Jonathon Kuo [EMAIL PROTECTED] wrote: Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. It is common, if not appropriate, to have utility classes (often ones with just class methods) that provide functions for others to use. At a minimum it allows you to namespace sets of utility methods. Exactly, as classes aren't objects. Yes they are - in Objective-C, anyway. Oops, my bad. Meant to say classes aren't instantiated objects (and thus they have no context or state, and so are appropriate for library-type functions, etc.) Yep. Good thing the built-in Cocoa frameworks don't have any instantiated objects that contain library-type functions. Otherwise, we'd have all sorts of singleton objects with names like NSFileManager, NSWorkspace, NSUserDefaults, NSFontManager... Charles ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Nov 20, 2008, at 5:53 PM, Charles Srstka wrote: On Nov 20, 2008, at 7:40 PM, Jonathon Kuo wrote: On Nov 20, 2008, at 5:06 PM, Charles Srstka wrote: On Nov 20, 2008, at 5:58 PM, Jonathon Kuo wrote: On Nov 20, 2008, at 2:07 PM, Shawn Erickson wrote: On Thu, Nov 20, 2008 at 1:23 PM, Jonathon Kuo [EMAIL PROTECTED] wrote: Just my 2 cents, but it seems an abuse to turn functions into objects. Functions don't retain state; objects do. Objective C very gracefully allows objects to call C functions. If you're doing something like [calc addDoubleA:a withDoubleB:b], you've got a function masquerading as an object, which I think misses the entire point of OOP. It is common, if not appropriate, to have utility classes (often ones with just class methods) that provide functions for others to use. At a minimum it allows you to namespace sets of utility methods. Exactly, as classes aren't objects. Yes they are - in Objective-C, anyway. Oops, my bad. Meant to say classes aren't instantiated objects (and thus they have no context or state, and so are appropriate for library-type functions, etc.) Yep. Good thing the built-in Cocoa frameworks don't have any instantiated objects that contain library-type functions. Otherwise, we'd have all sorts of singleton objects with names like NSFileManager, NSWorkspace, NSUserDefaults, NSFontManager... Well, to be fair, in each class you mention, you're accessing a special object: the default NSFileManager object for the file system, the shared NSWorkspace instance, etc. Those aren't examples of simple libraries in class clothing, which is all I was getting at. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Re: Wrapping C functions in Objective C proxy objects: naming convention?
On Thu, Nov 20, 2008 at 6:09 PM, Ken Tozier [EMAIL PROTECTED] wrote: Just out of curiosity, why do you need to send such common math operations to a soap request? Wouldn't it be easier to do simple stuff like calculations in your Soap class and only make requests for the unique services the endpoint provides? What I presented here was sample code that's fed to the gSOAP generator (soapcpp2). What I'm writing is a further generator that will generate an Objective C proxy on top of the gSOAP service. I personally don't ever need to do add, sub, mul, div, or pow. However, looking at how SOAP clients and servers are implemented using these simple examples is instructive. Trust me; the stuff I am *really* doing is a few orders harder than simple math operations. But as you're doing something new, it's always smart to take baby steps. -austin -- Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/ * [EMAIL PROTECTED] * http://www.halostatue.ca/feed/ * [EMAIL PROTECTED] ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
Wrapping C functions in Objective C proxy objects: naming convention?
For a project that I'm working on, I have a need to write a code
generator that will wrap certain kinds of C functions as Objective C
messages on an Objective C proxy. Because I don't ultimately control
the input, the parameters on the C functions may be poorly named. I'm
looking for advice on how one might make useful object message names
from C functions.
The format of the functions in question is essentially like this[1]:
int ns__add(double a, double b, double *result);
int ns__sub(double a, double b, double *result);
int ns__mul(double a, double b, double *result);
int ns__div(double a, double b, double *result);
int ns__pow(double a, double b, double *result);
The int return is a status code; the result of the operation is in
double* result. If there's an error in the operation. (The status code
may be ignorable, in which case part of my following question is
answered; I'm still researching this part. I suspect that it is best
not ignored.)
Anyway, the problem is how I should convert this function with poorly
named parameters into a proxy object and messages?
The options that I've come up with (expressed in terms of use) follow.
They're all expressed in terms of an object ns__CalcProxy:
ns__CalcProxy calc = [[ns__CalcProxy alloc] init];
double a, b, result;
int status;
result = [calc addDoubleA:a withDoubleB:b]; // #1
result = [calc addDoubleA:a withDoubleB:b status:status]; // #2
status = [calc addDoubleA:a withDoubleB:b returning:result]; // #3
The examples given here are simple; the items being returned may in
fact be pretty complex (and I'm planning on making it so that
structured parameters and return values may be passed in Objective C
proxies themselves).
I really don't like the addDoubleA:withDoubleB: name, to be honest,
but what am I supposed to do with:
struct ns1__ludcmpResponse {matrix *a; ivector *i; xsd__double d;};
int ns1__ludcmp(matrix *a, struct ns1__ludcmpResponse** result);
Like I said; I don't really have any control over the names of the
parameters, more's the pity.
-austin
[1] Actually, they're more like this:
int soap_call_ns__add(struct soap *soap, const char *soap_endpoint,
const char *soap_action, double a, double b, double *result);
But there's enough information in there for me to extract the former
to use as a proxy function.
--
Austin Ziegler * [EMAIL PROTECTED] * http://www.halostatue.ca/
* [EMAIL PROTECTED] * http://www.halostatue.ca/feed/
* [EMAIL PROTECTED]
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
Re: C functions and instance variables
On Fri, Mar 28, 2008 at 9:14 AM, Trygve Inda [EMAIL PROTECTED] wrote: I have a Cocoa object with .m and .h files and need to include in this a series of about 30 C functions which all all in their own .c file. Is it possible to give functions in the .c file access to the .m files instance variables? No, but you can rename the file.c as file.m, pass a pointer to self from your Obj-C method to your C function, and use the ivars' Obj-C getters/setters within your C function. How can I do this without rewriting the .c functions as Obj-C? You don't need to rewrite anything, as you can mix C and Obj-C freely in a .m file. Also, is there a way to use two .m files for one object so that all my code doesn't have to be in one file? Can I just #import one .m file into the other? You can use categories: http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_1.html Hamish ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
