Undolog.com

o CGPoint , ad esempio. The syntax NSLog(@"%@", ... ); works and is used to obtain information about objects, but does not work on C data types such as struct CGRect or CGPoint , for example. o NSStringFromCGPoint : To take advantage of NSLog(@"%@", ... ); also C-style structs we can lean on conversion functions like NSStringFromCGRect() or NSStringFromCGPoint :

Specifically, it is possible to refine the procedures Corresponding small useful macros like:

Or:

That will give as output:

More ...

<a target="_blank" href="http://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Functions/Reference/reference.html#//apple_ref/c/func/NSLog">NSLog()</a> a useful function during the early stages of a project for testing and debugging an application for Apple iPhone or, more generally, in XCode environment. Being just a function, just like the other, his presence will be felt even when releasing (release) our executable. potrebbero influire sulle performance della nostra applicazione, soprattutto se abbiamo inserito NSLog() all'interno di loop. It therefore becomes necessary to remove, in some way, all the lines of NSLog() from our code, because it is not necessary, either because the calls to NSLog() could affect the performance of our application, especially if we put NSLog() to 'inner loop.

Immediately rule out the solution to the "look" and "cancel" because one day there could be used again. We exclude also the solution of the "look" and "comments", uncomfortable for the same reason as before. Fortunately a clean, simple and are using the correct compiler conditionals. What we do in practice, and tell the compiler to exclude - if there is a specific condition - when compiling our source lines that contain NSLog() .

The compilations of directives and instructions of the conditional compiler, are a very powerful and widespread. Those coming from the development of the ANSI-C certainly know very well and will utilizzte in many situations. The peculiarity of these "instructions" resides in the fact, mentioned above, to be seen by the compiler and not executable. This feature makes them useful in many cases and can solve problems otherwise very annoying.

Let's see an example of code that, as predicted, you can "delete" by compiling pieces of code, in our case NSLog() :

). Conditional statements are part of the compiler of the same family as #define , also, in fact, are preceded by a "pound" ( # ). solo se ACTIVE_NSLOG è definito. In the example shown we have defined a constant ACTIVE_NSLOG ; subsequent lines of code tells the compiler to "include" line NSLog() only if ACTIVE_NSLOG is defined. If we took care, during the writing of our code, inserting calls to NSLog() within the block #ifdef ... #endif per far sparire, alla prossima compilazione, tutti i nostri NSLog() . #ifdef ... #endif , just delete the definition of the constant ACTIVE_NSLOG to fade away, the next compilation, all our NSLog() .

A best and final

Let us now see how to set the XCode environment to improve even more what we have done here! First we choose a constant name that we use in our projects to exclude from the compilation NSLog() . o quello che preferite. You can choose the name that you like, from DEBUG to MIO_DEBUG or whatever you prefer. Open your project, new or old. Enter all the NSLog() within the block (or of a block):

Select the main file of your project, right click and choose the Get Info.

This opens a window with information about the project:

Select the Build tab, verify that you are in Debug configuration (this is the gem), go to the User-Defined section and add, via the button at the bottom left, a new field called OTHER_CFLAGS . At this assegnamoli the value -DMIO_DEBUG=1 . The syntax is -D{mia define}=1 .

This procedure has two advantages:

1. We must not put in the code #define MIO_DEBUG 1 , but we do it through the project information. So, when we go to fill out the release version (the one without the NSLog() ) we must remember to delete the line #define MIO_DEBUG 1
2. The constant is defined in relation to the configuration, in our case Debug. Then, passing to the Release configuration (release) will be absent and the constant rows with NSLog() will not be compiled

Conclusions

The above procedure may be useful in a moltidutine other cases, with NSLog() , have nothing to do. Conditional statements can help the compiler in a wide range of contexts. They are often used by programmers to determine the type of operating system version, the target, the presence of mathematical processors, while maintaining the same "identical" source.

To understand this, as an example, we can utilizzre our constant MIO_DEBUG also to intervene in other areas of the code:

To finish, here are some examples and variants:

More ...

, usata per il debug delle applicazioni. Taking up the post from Actionscript to Objective-C (where you put the code and comparing the syntax Actionscript and Objective-C) in Actionscript we have the convenient function trace ( ) , used for debugging applications. This function outputs an output to the console Adobe Flash development environment. It is mainly used during development and testing of "movie" / application. In XCode / Objective-C we have: NSLog ( ) . di Actionscript: The syntax of this function is very similar to the trace ( ) in Actionscript:

In Actionscript we have:

Apart from the use of sign (@), as you can see, are identical. The differences (and similarities) start when you want to display values ​​of variables, for example in Actionscript we have:

In Objective-C we have:

che opera sull'Apple System Log. Note: NSLog() actually calls the more generic function NSLogv ( ) that works on Apple System Log. The functions are in fact identical, changing only the input parameters.

o sprintf ( ) . C developers will find very familiar with the formatting of strings, as with printf ( ) or sprintf ( ) . For details, see String Format Specifiers .

More ...