iOS hexadecimal equivalent in objective c

asmkhn

macrumors newbie
Original poster
Jun 10, 2013
3
0
how do we write this vb.net code in objective c

Code:
dim b = New Byte() {&HAA, &HFF, &HAA}
 

balamw

Moderator
Staff member
Aug 16, 2005
19,360
963
New England
how do we write this vb.net code in objective c

Code:
dim b = New Byte() {&HAA, &HFF, &HAA}
Code:
typedef unsigned char BYTE;
BYTE b[3] =     {0xAA,0xFF,0xAA};
would be one way. Given no other context...

Since this looks like an RGB triplet. Something else is probably better...

B
 

asmkhn

macrumors newbie
Original poster
Jun 10, 2013
3
0
Code:
typedef unsigned char BYTE;
BYTE b[3] =     {0xAA,0xFF,0xAA};
would be one way. Given no other context...

Since this looks like an RGB triplet. Something else is probably better...

B

i think i am not able to get syntax correctly for objective c

the vb.net code is as follow

Code:
Sckclnt.Delimiter = New Byte() {&HAA, &HFF, &HAA}
in objective c
Code:
#define Delimiter @"1234"
Code:
NSMutableData* pl = [[NSMutableData alloc] init];
    [pl appendData:data];
    
    NSData *delimiter = [Delimiter dataUsingEncoding:NSUTF8StringEncoding];
    [pl appendData:delimiter];

i need the Delimiter to be the bytes as in vb code
 

balamw

Moderator
Staff member
Aug 16, 2005
19,360
963
New England
i have updated my last answer please read
You need to provide a lot more context for anyone to be able to help you.

  • What are you trying to do?
  • What have you tried?
  • How is it failing/not working?

Post as much of the VB and ObjC code as you can. Not just single lines.

If you can, please post compilable test code.

B
 

lastcall

macrumors member
Jan 10, 2013
51
5
how do we write this vb.net code in objective c

Code:
dim b = New Byte() {&HAA, &HFF, &HAA}
If you want to convert a byte array to NSData, then you can mix plain C with Objective-C:

Code:
const unsigned char bytes[] = {0xFF, 0xAA, 0xFF};
NSData *data = [NSData dataWithBytes:bytes length:sizeof(bytes)];
NSLog(@"%@", data);
Just rename your source file from .m to .mm
 

chown33

Moderator
Staff member
Aug 9, 2009
8,493
4,499
Restivus
Just rename your source file from .m to .mm
Not necessary. A .m file contains Objective-C source. Since Objective-C is a pure superset of C, any .m file can contain pure C and be perfectly valid.

A .mm file is Objective-C++. Since C++ is not a pure superset of C, then pure C will actually be compiled as Objective-C++ in a .mm file.
 

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
Not necessary. A .m file contains Objective-C source. Since Objective-C is a pure superset of C, any .m file can contain pure C and be perfectly valid.

A .mm file is Objective-C++. Since C++ is not a pure superset of C, then pure C will actually be compiled as Objective-C++ in a .mm file.
C++ is a pure superset of C.
So is Objective C.

Consider a Venn diagram. The intersection between C++ and Objective C is C.
 

chown33

Moderator
Staff member
Aug 9, 2009
8,493
4,499
Restivus
C++ is a pure superset of C.
Almost, but not quite:
http://en.wikipedia.org/wiki/C++#With_C
C++ is often considered to be a superset of C, but this is not strictly true.[39] Most C code can easily be made to compile correctly in C++, but there are a few differences that cause some valid C code to be invalid or behave differently in C++.
One commonly encountered difference is that C allows implicit conversion from void* to other pointer types, but C++ does not (for type safety reasons). Another common portability issue is that C++ defines many new keywords, such as new and class, that may be used as identifiers (e.g. variable names) in a C program.
http://en.wikipedia.org/wiki/Objective-C#Syntax
Objective-C is a thin layer on top of C, and moreover is a strict superset of C; it is possible to compile any C program with an Objective-C compiler, and to freely include C code within an Objective-C class.
Note that Objective-C avoids the keyword collision problem by prefixing new keywords with @, as in @interface, @protocol, etc.

There are valid C programs that won't compile as C++ until certain changes are made, such as implicit conversion of void* being changed to explicit conversion (i.e. explicit type-cast).


Forgive my earlier use of "pure superset"; I meant to write "strict superset". I don't think this changes anything, since a "pure superset" still implies (I think) that every valid C program is also a valid C++ program, and as noted already, this isn't strictly true.
 

Duncan C

macrumors 6502a
Jan 21, 2008
853
0
Northern Virginia
Almost, but not quite:
http://en.wikipedia.org/wiki/C++#With_C
C++ is often considered to be a superset of C, but this is not strictly true.[39] Most C code can easily be made to compile correctly in C++, but there are a few differences that cause some valid C code to be invalid or behave differently in C++.
One commonly encountered difference is that C allows implicit conversion from void* to other pointer types, but C++ does not (for type safety reasons). Another common portability issue is that C++ defines many new keywords, such as new and class, that may be used as identifiers (e.g. variable names) in a C program.
http://en.wikipedia.org/wiki/Objective-C#Syntax
Objective-C is a thin layer on top of C, and moreover is a strict superset of C; it is possible to compile any C program with an Objective-C compiler, and to freely include C code within an Objective-C class.
Note that Objective-C avoids the keyword collision problem by prefixing new keywords with @, as in @interface, @protocol, etc.

There are valid C programs that won't compile as C++ until certain changes are made, such as implicit conversion of void* being changed to explicit conversion (i.e. explicit type-cast).


Forgive my earlier use of "pure superset"; I meant to write "strict superset". I don't think this changes anything, since a "pure superset" still implies (I think) that every valid C program is also a valid C++ program, and as noted already, this isn't strictly true.
Fair enough.

Isn't the typing a compiler setting?
 

chown33

Moderator
Staff member
Aug 9, 2009
8,493
4,499
Restivus
Isn't the typing a compiler setting?
If it is, I'd have to default to whatever the standard's language spec defines. AFAICT without having a C++ spec in front of me, implicit conversions are forbidden. (I assume you're referring to the void* implicit conversions.)

And of course, whenever "language spec" or "standard" comes up, it must be further qualified by date, e.g. C89 vs. C99, and C++98 vs. C++11, and so on.