When you are not working alone for most all developers comes time to find guidance in the writing of the code. Protocols and standards to allow "read" easily and intervene (more easily) in the code of others.
When we work on a project more programmers, often of different languages, you must find a common form of writing, in the standard internal and external documentation to the code. In my work I am normally interact with:
- Objetive-C, C / C + +
I thought it might be helpful to those who have recently approached the development of applications for Apple iPhone, Adobe Actionscript compare - the language used in Adobe Flash and Adobe Flex is more widespread among new programmers - and Objective-C, the language used by Apple to develop its applications. Objective-C is in effect an object-oriented language in the pure sense, not that Actionscript is not, but Objective-C is definitely a plus as it is an extension of ANSI C and its syntax is a mix between C / C + + and Smalltalk, is a true OO (Object-oriented language).
From today inaugurated a new section (category to be corrected), dedicated to developing applications on the Apple iPhone! I state from the outset that many of the items that will publish a "cut" in line with the spirit of this blog, that will be mostly for advanced users. However, as I have done for other topics, I will try to be as clear as possible and, where necessary, insert some "basic concept" useful to a wider audience.
Who develops knows that one of the characteristics of functions (
function () ) is to have whether or not the input arguments. It may happen at times, having to write a function that, based on the input parameters, behaves in a different way (in OO programming this behavior are referred to as polymorphism). The variable parameters (varargs), already introduced at the time of C and present by default in the classic statement of the
int main (int argc, char * argv );
Ho "exhumed" this my article written a bit 'of years ago. I've slightly revised, updating a little bit here and there, but I think it is still relevant and interesting.
What is a development language? A computer, alias PC (Personal Computer), has its own personal language. This language is called machine code, to mean that every machine, so any computer (PC compatible, Apple, Unix, etc ...), it has one exclusive owner. The programs that we see "turn" on our PC are mainly carried out by the mysterious object called a microprocessor. This is the heart, the intelligent unit, of each electronic processor. In reality a application does not is executed only by the microprocessor but leans, so to say, to what is called operating system: a layer software provided from producer of the machine (see, for example, i Macintosh of the Apple).
It seems obvious, but some escapes the subtle difference between constants and variables in a programming language. The constants, from the name itself, do not change their value during the cycle of a program, while variables can do it! Often, however, happen to use variables instead of constants without realizing it, also because this does not impact the logic of an application. Despite this, the difference between constants and variables in there and it shows all compile-time, where the constant plays a role you certainly more efficient.
Coming from the Assembly programming or C knows the difference between constants and variables, especially because, both in Assembly and C, constants play a role by MACRO. For MACRO indendo a "piece of code" that is labeled and replaced within the code at compile time. The compiler, long story short, performs a sort of find .. replace (finds and sostituitsci) in the code every time it encounters a constant.
Imagine you write in C the following simple piece of code:
5 ; int a = 5;
3 ; int b = 3;
b ; c = a + b;
sono indicate come variabili in questo caso. Both
b are indicated as variables in this case. In C, in fact, constants are defined with the keyword
#define . sono state definite come
int . We note immediately that it is
b were defined as
int . Already here you can operate a first optimization. If we know that our variable is
a will never exceed a certain value, it is good to declare it in appropriate way and not use types data at random. Some developers do not bother to declare the correct types, thinking that this does not affect performace! Wrong! In alternative is acceptable that the first drafting of the Code never leads to this level of detail. However, it is a good rule, during the development process, review the code and verify the data types.
However, in an assembly of the Motorola family, for example, as the mythical 68000, our code would seize compiled (no optimizations) in a kind of:
, d0 ; int a move. l # 5, d0; int
, d1 ; int b move. l # 3, d1, int b
d2 ; int c - foo move. l d1, d2, int c - foo
l d0 , d2 ; risultato in d2 ovvero c add. l d0, d2, d2 or result in c
, d0 ; int a move. l # 5, d0; int
, d1 ; int b move. l # 3, d1; int b
d1 ; risultato in d1... move. l d0, d1, d1 result in ...
The compiler, however clever, fatigue in optimizations, then write the code with the right keywords can only help to improve the compiled output. In our case, if the value is a constant 5 is not convenient to use an integer variable, since the compiler, appropriately, whereas the variable variable, precisely, predisponde a whole to contain the simple value of 5, which in binary is 101, ie takes 3 simple bit (if anything int is a 32bit or a 53bit worse double-precision floating-point!). If we had written the code like this:
# Define MIA_COSTANTE 5
3 ; int b = 3;
b ; c = MIA_COSTANTE + b;
The compiler would have known from the beginning that
MIA_COSTANTE , being constant, the value will not change so I can reserve less space to treat it. In practice the Assembly code diverebbe:
d0 ; la "q" indica una istruzione "quick", cioè che tratta valori compresi tra -128 e +127 moveq # 3, d0, the "q" indicates an instruction "quick", that is values between -128 and +127
, An instruction "quick" takes less CPU time (4 clock cycles in this case)
d0 ; anche qui uso una istruzione "quick" addq # 5, d0; here also use an instruction "quick"
This code is extremely faster and takes up less bytes. What you have to keep in mind is that when you declare a variable environment is ready to treat it as such, even though today's compilers are able to do miracles, performing a series of steps in the code before compiling (some compilers even perform a sort of program simulation to optimize the compilation into machine code).
A good rule, therefore, is to declare the right kind for our variables, whether these are. Alternatively use the constants, especially if the programming language that we are using the expected (as in the case of the new Flash CS3).