Types in Objective-C on Ios

Types in Objective-C on iOS

This is a good overview:

http://reference.jumpingmonkey.org/programming_languages/objective-c/types.html

or run this code:

32 bit process:

  NSLog(@"Primitive sizes:");
  NSLog(@"The size of a char is: %d.", sizeof(char));
  NSLog(@"The size of short is: %d.", sizeof(short));
  NSLog(@"The size of int is: %d.", sizeof(int));
  NSLog(@"The size of long is: %d.", sizeof(long));
  NSLog(@"The size of long long is: %d.", sizeof(long long));
  NSLog(@"The size of a unsigned char is: %d.", sizeof(unsigned char));
  NSLog(@"The size of unsigned short is: %d.", sizeof(unsigned short));
  NSLog(@"The size of unsigned int is: %d.", sizeof(unsigned int));
  NSLog(@"The size of unsigned long is: %d.", sizeof(unsigned long));
  NSLog(@"The size of unsigned long long is: %d.", sizeof(unsigned long long));
  NSLog(@"The size of a float is: %d.", sizeof(float));
  NSLog(@"The size of a double is %d.", sizeof(double));

  NSLog(@"Ranges:");
  NSLog(@"CHAR_MIN:   %c",   CHAR_MIN);
  NSLog(@"CHAR_MAX:   %c",   CHAR_MAX);
  NSLog(@"SHRT_MIN:   %hi",  SHRT_MIN);    // signed short int
  NSLog(@"SHRT_MAX:   %hi",  SHRT_MAX);
  NSLog(@"INT_MIN:    %i",   INT_MIN);
  NSLog(@"INT_MAX:    %i",   INT_MAX);
  NSLog(@"LONG_MIN:   %li",  LONG_MIN);    // signed long int
  NSLog(@"LONG_MAX:   %li",  LONG_MAX);
  NSLog(@"ULONG_MAX:  %lu",  ULONG_MAX);   // unsigned long int
  NSLog(@"LLONG_MIN:  %lli", LLONG_MIN);   // signed long long int
  NSLog(@"LLONG_MAX:  %lli", LLONG_MAX);
  NSLog(@"ULLONG_MAX: %llu", ULLONG_MAX);  // unsigned long long int

When run on an iPhone 3GS (iPod Touch and older iPhones should yield the same result) you get:

Primitive sizes:
The size of a char is: 1.                
The size of short is: 2.                 
The size of int is: 4.                   
The size of long is: 4.                  
The size of long long is: 8.             
The size of a unsigned char is: 1.       
The size of unsigned short is: 2.        
The size of unsigned int is: 4.          
The size of unsigned long is: 4.         
The size of unsigned long long is: 8.    
The size of a float is: 4.               
The size of a double is 8.               
Ranges:                                  
CHAR_MIN:   -128                         
CHAR_MAX:   127                          
SHRT_MIN:   -32768                       
SHRT_MAX:   32767                        
INT_MIN:    -2147483648                  
INT_MAX:    2147483647                   
LONG_MIN:   -2147483648                  
LONG_MAX:   2147483647                   
ULONG_MAX:  4294967295                   
LLONG_MIN:  -9223372036854775808         
LLONG_MAX:  9223372036854775807          
ULLONG_MAX: 18446744073709551615 

64 bit process:

The size of a char is: 1.
The size of short is: 2.
The size of int is: 4.
The size of long is: 8.
The size of long long is: 8.
The size of a unsigned char is: 1.
The size of unsigned short is: 2.
The size of unsigned int is: 4.
The size of unsigned long is: 8.
The size of unsigned long long is: 8.
The size of a float is: 4.
The size of a double is 8.
Ranges:
CHAR_MIN:   -128
CHAR_MAX:   127
SHRT_MIN:   -32768
SHRT_MAX:   32767
INT_MIN:    -2147483648
INT_MAX:    2147483647
LONG_MIN:   -9223372036854775808
LONG_MAX:   9223372036854775807
ULONG_MAX:  18446744073709551615
LLONG_MIN:  -9223372036854775808
LLONG_MAX:  9223372036854775807
ULLONG_MAX: 18446744073709551615

Is it possible to use Metal data types in Objective-C?

Those types are in for C and C++ (and by extension, for Objective-C and Objective-C++).

They're actually the same types, with the same data layout, and the same associated functions, as those that you use from a Metal shader. So using them in CPU-side code where you expect to interface with Metal is a great idea. For example, you can define your own struct for vertex shader input in a C++ header file, then import that header and use the same struct definition in both your CPU code and the shader.

Note that the names differ a bit: e.g. uint2 is vector_uint2 in C, but simd::uint2 in C++.

What is the typeof() equivalent in Objective-C?

Yes, you can use the [object class] method:

NSArray *a = @[@"a", @"b"];
NSLog(@"NSArray = %@", [a class]);
// NSArray = __NSArrayI

NSMutableArray *b = [[NSMutableArray alloc] initWithArray:a];
NSLog(@"NSMutableArray = %@", [b class]);
// NSMutableArray = __NSArrayM

NSString *c = @"imastring";
NSLog(@"NSString = %@", [c class]);
// NSString = __NSCFConstantString

NSNumber *d = [[NSNumber alloc] initWithInteger:5];
NSLog(@"NSNumber = %@", [d class]);
// NSNumber = __NSCFNumber

Keep in mind that is is common to see the __NSCF or the __NS prefix on most of the objects you inspect in this manner. For example, when logging the class type of an NSString, you are likely to see __NSCFString or __NSCFConstantString (which are both NSString types) as the result. I only ever use this approach when I am curious to see how things look behind the scenes, but I don't tend to use this type of check in production.

You can look into using the isKindOfClass method to test if the object is a certain type.

How to match data types in Objective-c to Swift protocol?

As you've discovered, a plain NSDictionary * is bridged to [NSObject: AnyObject]!.

To get Dictionary, you would have to declare it in Objective-C as

- (void)doSomeStuff:(nonnull NSDictionary *)stuff;

How can I find out the Objective-C generics type?

The lightweight generics introduced in Xcode 7 are just compile time hints to help the compiler raise warnings, but at run time you get the same old behavior with your variable being just NSArrays of ids.

Source: WWDC '15 "Swift and Objective-C Interoperability" session

See the transcript of the talk:

So the entire lightweight generics feature is based on a type erasure model. Which means that the compiler has all of this rich static type information but it erases that information when generating code.

Can't use objective C statements/data types in swift

NSColor is a on Mac OS X, not on iOS.
Its "equivalent" is UIColor.

That's why the compiler says that it doesn't know NSColor.

Objective-C properties' types

Here's the short answer:

atomic vs nonatomic primarily ensures that complete values are returned from synthesized getters and that complete values are written by synthesized setters.

readwrite vs readonly determines whether a synthesized property has a synthesized accessor or not (readwrite has a setter and is the default, readonly does not).

assign vs weak vs retain vs copy determines how the synthesized accessors interact with the Objective-C memory management scheme.

And now for the long answer:

Atomic v Nonatomic

Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory.

With atomic, the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.

In nonatomic, no such guarantees are made. Thus, nonatomic is considerably faster than atomic.

What atomic does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.

Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.

Assign, weak, retain, copy

In a nutshell, assign vs weak vs retain vs copy determines how the synthesized accessors interact with the Objective-C memory management scheme:

• assign is the default and simply performs a variable assignment. It does not assert ownership, so the object pointed to by the property's pointer may disappear at any time if no others have asserted ownership themselves through retain or other means. In an ARC environment, assign does not ensure that pointers will not dangle, which means a pointer may end up pointing to junk if the object on the other side has been deallocated.
• weak is identical to assign, except that it will zero out pointers that lead to deallocated objects to stop them from dangling. Weak is only available in an ARC environment.
• retain specifies the new value should be sent -retain on assignment and the old value sent release. Retain is also know as strong.
• copy specifies the new value should be sent -copy on assignment and the old value sent release. Copy is often used for properties in which the type of the property has a mutable cousin (NSArray/NSMutableArray) to prevent others from sending in mutable versions and altering them/having them altered behind their backs, and more.

Remember that retain/strong is done on the created object (it increases the reference count) whereas copy creates a new object. The difference, then, is whether you want to add another retain to the object or create an entirely new object.

How to know the type of a variable in Objective C on Iphone?

[a isKindOfClass:[NSArray class]]

Springs to mind.

I do want to point out though that in your case it makes more sense to simply type the method argument, rather than taking id and checking it's type, i.e.

+ (void)sort:(NSArray *)a

---

Related Topics