CFSocketCreate and declarations

[Adam Lang]

I am just starting Objective-C, but have other programming experience
(predominantly Java and Visual Basic). I am trying to get socket
programming to work but am having some problems with type
declarations. I am guessing there are some header files I am not
properly importing?

For example I have this:

TCPServer = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_STREAM,
IPPROTO_TCP, kCFSocketAcceptCallBack, (CFSocketCallBack)
&AcceptCallback, &CTX);

And I am getting PF_INET, SOCK_STREAM, IPPROTO_TCP listed as
undeclared.

I imported this:
#import <Foundation/Foundation.h>
#import <CoreFoundation/CoreFoundation.h>

Seeing if I was just missing a header file, but to no avail. Nor can
I find any leads on why it is happening. Any ideas?

[Stefan Arentz]

Adam Lang <raide...@gmail.com> writes:

> I am just starting Objective-C, but have other programming experience
> (predominantly Java and Visual Basic). I am trying to get socket
> programming to work but am having some problems with type
> declarations. I am guessing there are some header files I am not
> properly importing?
>
> For example I have this:
>
> TCPServer = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_STREAM,
> IPPROTO_TCP, kCFSocketAcceptCallBack, (CFSocketCallBack)
> &AcceptCallback, &CTX);
>
> And I am getting PF_INET, SOCK_STREAM, IPPROTO_TCP listed as
> undeclared.

#include <sys/socket.h>
#include <netinet/in.h>

S.

[h...@computer.org]

For completeness: CFSocketCreate() is plain C and not Objective-C and
is part of Apple's CoreFoundation framework. You can regard it as some
"internal" implementation library that you should not use (unless you
have a good reason to do so). Unfortunately you can already find a
horrible (and in 99% unnecessary) mixture of Obj-C and CF on the
Web...

If you want to stay within Objective-C, please use the classes
NSStream and friends which wrap most TCP/IP (incl. ssh access).

-- hns

[Stefan Arentz]

"h...@computer.org" <h...@computer.org> writes:

> On 8 Aug., 06:13, Adam Lang <raider.a...@gmail.com> wrote:
>> I am just starting Objective-C, but have other programming experience
>> (predominantly Java and Visual Basic). �I am trying to get socket
>> programming to work but am having some problems with type
>> declarations. �I am guessing there are some header files I am not
>> properly importing?
>>
>> For example I have this:
>>
>> TCPServer = CFSocketCreate(kCFAllocatorDefault, PF_INET, SOCK_STREAM,
>> IPPROTO_TCP, kCFSocketAcceptCallBack, (CFSocketCallBack)
>> &AcceptCallback, &CTX);
>>
>> And I am getting PF_INET, SOCK_STREAM, IPPROTO_TCP listed as
>> undeclared.
>>
>> I imported this:
>> #import <Foundation/Foundation.h>
>> #import <CoreFoundation/CoreFoundation.h>
>>
>> Seeing if I was just missing a header file, but to no avail. �Nor can
>> I find any leads on why it is happening. �Any ideas?
>
> For completeness: CFSocketCreate() is plain C and not Objective-C and
> is part of Apple's CoreFoundation framework. You can regard it as some
> "internal" implementation library that you should not use (unless you
> have a good reason to do so).

This is very misleading. All the CoreFoundation frameworks, including
the network APIs, are public and certainly not "internal". They are
well documented and part of the 'toolbox' that you can use in your
Cocoa applications.

Some parts of CoreFoundation have nice Cocoa wrappers. Others
don't. But that is in no way an indication that they are internal and
not be used.

S.

[h...@computer.org]

Sure, you can use everything. Even down to Assembler.

But in my experience, by looking too much on CoreFoundation you may
not find that there is a higher level of abstraction available in the
Objective-C Runtime Libraries (Cocoa, GNUstep etc.). Therefore, you
are solving your problem on a low level library (better wording than
"internal") by using CoreFoundation just because it is there (and well
documented), instead of using e.g. NSStream. It is the same as you
would not start to program standard C by using read(), write() etc.
No, you better start with FILE* and fprintf().

>
> Some parts of CoreFoundation have nice Cocoa wrappers. Others
> don't. But that is in no way an indication that they are internal and
> not be used.
>
>  S.

Maybe, I did not put it precisely enough: they are not at all part of
Objective-C. They are Apple specific. And Objective-C is not only
Apple and this mailing list is more general about Objective-C.

And finally, the original thread-starter did say he is starting to
learn Objective-C. My recommendation for learning Objective-C is
simply that you should avoid CoreFoundation (BTW: it leads people to
think CFRelease(self) is Objective-C instead of [self release]).

-- hns

[Tom Harrington]

In article
<dd30ea27-372b-4870...@r42g2000yqj.googlegroups.com>,
"h...@computer.org" <h...@computer.org> wrote:

> On 22 Aug., 15:10, Stefan Arentz <ste...@keizer.soze.com> wrote:
> > "h...@computer.org" <h...@computer.org> writes:
> > > For completeness: CFSocketCreate() is plain C and not Objective-C and
> > > is part of Apple's CoreFoundation framework. You can regard it as some
> > > "internal" implementation library that you should not use (unless you
> > > have a good reason to do so).
> >
> > This is very misleading. All the CoreFoundation frameworks, including
> > the network APIs, are public and certainly not "internal". They are
> > well documented and part of the 'toolbox' that you can use in your
> > Cocoa applications.
>
> Sure, you can use everything. Even down to Assembler.
>
> But in my experience, by looking too much on CoreFoundation you may
> not find that there is a higher level of abstraction available in the
> Objective-C Runtime Libraries (Cocoa, GNUstep etc.). Therefore, you
> are solving your problem on a low level library (better wording than
> "internal") by using CoreFoundation just because it is there (and well
> documented), instead of using e.g. NSStream. It is the same as you
> would not start to program standard C by using read(), write() etc.
> No, you better start with FILE* and fprintf().

This is a matter of style and choosing an API that meets requirements--
it's a very, very different thing your previous suggestion that Core
Foundation is for Apple's internal use only. Anyway, Core Foundation is
already pretty well abstracted as compared to lower-level APIs like
(e.g.) send() and recv().

> > Some parts of CoreFoundation have nice Cocoa wrappers. Others
> > don't. But that is in no way an indication that they are internal and
> > not be used.
>

> Maybe, I did not put it precisely enough: they are not at all part of
> Objective-C. They are Apple specific. And Objective-C is not only
> Apple and this mailing list is more general about Objective-C.

I guess that's true but better advice would be to focus on finding the
best solution to one's problem rather than aiming for Objective-C
purity. Keep in mind that NSStream is not Objective-C, it's part of
Foundation. Foundation also includes lots of stuff that's only
available on Mac OS X. It's true that Objective-C exists on other
platforms but the frameworks are nothing like cross platform.

> And finally, the original thread-starter did say he is starting to
> learn Objective-C. My recommendation for learning Objective-C is
> simply that you should avoid CoreFoundation (BTW: it leads people to
> think CFRelease(self) is Objective-C instead of [self release]).

I've known a lot of people learning to program on Macs and I've never
heard anyone indicate any hint that they believed the CF* APIs were
Objective-C. Make whatever recommendations you want, I'll stick with
"use the tool that solves your problem effectively".

--
Tom "Tom" Harrington
Independent Mac OS X developer since 2002
http://www.atomicbird.com/