This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Dynamically creating functions in c
Here is an example of what I'd like to do:
void attribute((constructor)) someFunction() {
// Would be nice to define C function "someFunction2" somehow here.
}
I know class_addMethod allows adding C functions to Objective-C classes during runtime.
Is it possible to add C function to C main space?
Please, don't tell me I'm wrong if I'm thinking about this way of doing things - I am interested in it rather for educational purposes.
No. A C function consists of a name and a body. The compiler transforms the body to a binary piece of executable code that will be mapped to some address when a process is created from the executable. The name is used by the static and dynamic linkers as an alias to this address.
At runtime both concepts aren't really of much interest. The executable is loaded and names are resolved, so there's little use in creating them dynamically.
On iOS it would even be impossible to create new function implementations as the kernel disallows to make memory executable.
Related
This question already has an answer here:
Keep the delegate argument names when compiling C++/CLI for .Net
(1 answer)
Closed 8 years ago.
I'm working on a multi-project program in C++/CLI and parameter names for functions, constructors etc. are not showing up properly in the Intellisense window. When I start typing a function call within the project, all goes well, but as soon as I use said project in another project (still within the same solution), VS shows funky parameter names (e.g. myobj.move(int A_0,int A_1)) instead of the names I gave them in the code. I've tried using the ///<param> thing, but that works only within the same project, not in other projects (again, in the same solution). I've enabled the /doc option in the project properties, but that didn't do it. Is there a way to feed the generated XML file (or .xdc I guess?) into Intellisense? Thanks in advance!
This happens when you declare the function prototype in a header file without the argument names:
#file.h
ref class A
{
void move(int ,int );
}
You should just add the names you want:
file.h
ref class A
{
void move(int MyArgument1,int MyOtherArgument);
}
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Is there something like Matlab's eval statement in Objective-C 2.0?
Is there an eval function (as in lisp, javascript, python, ruby...) in Objective-C?
What I mean by eval is a function that can take in arbitrary Objective-C code (possibly having class definitions, side effects, instrospection, etc) as a string (not a block or an NSInvocation or IMP or something like that), and evaluate each expression, respecting the current runtime environment state, side effects, class definitions, etc.
If not, is it possible to implement within the confines of the existing runtime?
Neither the language nor Apple's frameworks directly support such a thing. However, one of the goals of LLVM is to be an embeddable compiler suite. I'm pretty sure it can generate executable code right into memory. The hard part would be providing that code with access to the pre-existing environment of the calling code. For example, compiling code which references a local variable or something like that.
(Mind you, this approach is forbidden for the iOS App Store, but it could maybe be workable on Mac OS X.)
Absolutely not. Objective-C is a fully compiled language. Only interpreted languages can do that sort of thing.
No. Code eval is the feature for dynamic language. Although objective-C has dynamic feature , and even Cocoa runtime , it is still considered as a static language (generally).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
What is the best way to solve an Objective-C namespace collision?
I was using 2 open source projects in an application with different use --- the issue was that both project had same class name with different implementations.
As per my understanding objective C don't have namespace option to handle scope --- as of now I am renaming the one of the class and its usage to make it work in my project.
Is there any alternative solution then renaming? I feel like objective C is missing namespace.
Renaming is the correct way. There is a reason why Apple recommends to prefix your classes with some uppercase letters. This should prevent exactly this situation. Same for method names in class extension, or "private" methods.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
The common sense tells that the Doxygen comment blocks have to be put in the header files where the classes, structs, enums, functions, declarations are. I agree that this is a sound argument for a libraries that are mean to be distributed without its source (only headers and libs with object code).
BUT...I've been thinking of the exact opposite approach when I'm developing an internal to the company (or as a side project for myself) library that will be used with its full source code. What I propose is to put the large comment blocks in the implementations files (HPP, INL, CPP, etc) in order NOT to clutter the inteface of the classes and functions declared in the header.
Pros:
Less clutter in the header files, only categorizing of the functions can be added.
The comment blocks that are previewed when Intellisense for example is used doesn't clash - this is a defect that I have observed when I have a comment block for a function in the .H file and have its inline definition in the same .H file but included from .INL file.
Cons:
(The obvious one) The comment blocks are not in the header files where the declarations are.
So, what do you think and possibly suggest?
I like to make use of the fact that names can be documented in multiple places.
In the header file, I write a brief description of the method, and document all its parameters - these are less likely to change than the implementation of the method itself, and if they do, then the function prototype needs to be changed in any case.
I put long-format documentation in the source files next to the actual implementation, so the details can be changed as the method evolves.
For example:
mymodule.h
/// #brief This method adds two integers.
/// #param a First integer to add.
/// #param b Second integer to add.
/// #return The sum of both parameters.
int add(int a, int b);
mymodule.cpp
/// This method uses a little-known variant of integer addition known as
/// Sophocles' Scissors. It optimises the function's performance on many
/// platforms that we may or may not choose to target in the future.
/// #TODO make sure I implemented the algorithm correctly with some unit tests.
int add(int a, int b) {
return b + a;
}
Put the documentation where people will read and write it as they are using and working on the code.
Class comments go in front of classes, method comments in front of methods.
That is the best way to make sure things are maintained. It also keeps your header files relatively lean and avoids the touching issue of people updating method docs causing headers to be dirty and triggering rebuilds. I have actually known people use that as an excuse for writing documentation later!
Having comments in the header means that all users of a class must be recompiled if a comment is changed. For a large projects, coders will be less inclined to update comments in headers if they risk spending the next 20min rebuilding everything.
And.. since you're supposed to read the html doc and not browse through the code for documentation, it's not a large problem that the comment blocks are more difficult to locate in the source files.
Headers:
Easier to read the comments since there is less other "noise" when looking at the files.
Source:
Then you have the actual functions available for reading while looking at the comments.
We just use all global functions commented in headers and local functions commented in source. If you want you can also include the copydoc command to insert the documentation in multiple places without having to write it several times ( better for maintenance )
You could however also get the results copied over to different file documentation with a simple command. E.g. :-
My file1.h
/**
* \brief Short about function
*
* More about function
*/
WORD my_fync1(BYTE*);
MY file1.c
/** \copydoc my_func1 */
WORD my_fync1(BYTE* data){/*code*/}
Now you get the same documentation on both functions.
This gives you less noise in the code files at the same time you get the documentation written in one place presented in several places in the final output.
I'm using QtCreator for programming. A very useful trick consists in Ctrl-Clicking on a function or method to get the declaration in the header file.
When the method is commented in the header file, you can quickly find the information you are looking for. So for me, comments should be located in the header file!
Usually I put documentation for interface (\param, \return) in .h file and documentation for implementation (\details) in .c/.cpp/.m file. Doxygen groups everything in the function/method documentation.
I put everything in the header file.
I document everything, but only generally extract the public interface.
In c++ sometimes implementation can be split between header and .cpp modules. Here it seems cleaner to put it documentation into the header file as that is the only place that all public functions and methods are guaranteed.
What is the standard way of incorporating helper/utility functions in Obj-C classes?
I.e. General purpose functions which are used throughout the application and called by more than 1 class.
Can an Obj-C method exist outside of a class, or does it need to be a C function for it to have this kind of behaviour?
I would group similar functions as static methods in a helper class. These can then be called using the classname rather the instance name. Static methods are defined with a + instead of the usual -.
like so:
#interface HelperClass: superclassname {
// instance variables - none if all methods are static.
}
+ (void) helperMethod: (int) parameter_varName;
#end
This would be called like so.
[HelperClass helperMethod: 10 ];
As this is static you do not init/alloc the class. This has the advantage of clearly grouping like Helper functions. You could use standalone C functions but as your Application gets larger it can become a right mess! Hope this helps.
Tony
I don't see why people are avoiding creating functions. Objective-C is a superset of C, which means that C is part of it. Moreover, it's completely integrated—there's no wall between them.
Create functions! It's fine! Foundation does it. Application Kit does it. Core Animation does it. Core Media does it.
I see no reason not to.
There are a number of options for this in Objective-C. First, since Obj-C is a strict superset of C, you can define all your library functions in a separate module (source file) and happily call them from any Obj-C object/code you already have. If you create an obj-c source file (.m file) you can then call back into/use objects.
If your generic functions are logically manipulating other, established objects (for instances, operates on an NSString), you can use categories to graph your functions on already existing classes (where that makes sense).
Finally, as Tony points out, you can create classes with static methods (although I like this option the least, personally). I tend to use a mix of one an two... adding categories where appropriate and using standard functions for others. I generally only make a new class where it makes sense to design a class.