By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,224 Members | 1,120 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,224 IT Pros & Developers. It's quick & easy.

New C++ sockets library

P: n/a
I've created a new C++ sockets library - small, cross-platform, IPv4
and IPv6. If anyone would like to critique it, I'd appreciate it.
Doesn't support the more exotic protocols - only TCP and UDP. It also
lacks get/setsockopt and ioctl, but those may be added in the future.

There is no webpage for it yet, I plan on making one once I'm 100% sure
of everything. For now the source is available here:
http://dev.int64.org/netx.zip

PS. Look at the socket::select code. It's the only part I don't like,
but I couldn't come up with a better solution.

Jul 22 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
>small, cross-platform, IPv4 and IPv6

Thinly wrapped socket classes like these are the first steps toward a
cross platform sockets library. Code like

sock.send("hello", 6);

means you still have a way to go to make working with sockets easy and
safe.
If anyone would like to critique it, I'd appreciate it.
Small things I don't like are

1. c style casts instead of static_cast
2. "using namespace std" instead of "using std::string"
3. putting underscore in front of member variables
Look at the socket::select code

I would not try and use select for multiple clients. For servers think
about an interface to make it easy to use asynchronous I/O. (On windows
look at overlapped I/O, I/O completion ports and thread pooling)
Everyone wants networking in C++, so keep going.

Jul 22 '05 #2

P: n/a
> Thinly wrapped socket classes like these are the first steps toward a
cross platform sockets library. Code like

sock.send("hello", 6);

means you still have a way to go to make working with sockets easy and safe.
Yea, I've been wanting to make a steam-based interface for it - but I
don't know how :) I also fear I wouldn't use it that much.
If anyone would like to critique it, I'd appreciate it.
Small things I don't like are

1. c style casts instead of static_cast
2. "using namespace std" instead of "using std::string"
3. putting underscore in front of member variables


Agreed. I come from a C background, not used to the long cast
operators. The using can easily be fixed, but the underscores are
there for a reason - Intellisense in VS.NET can get cluttered with
private methods/variables, so I use it to seperate them.
Look at the socket::select code I would not try and use select for multiple clients. For servers

think about an interface to make it easy to use asynchronous I/O. (On windows look at overlapped I/O, I/O completion ports and thread pooling)
Everyone wants networking in C++, so keep going.


Yup, but it is good in some instances. I've already been working on a
nice wrapper for I/O Completion ports.

Jul 22 '05 #3

P: n/a
"Yea, I've been wanting to make a steam-based interface for it - but I
don't know how :) I also fear I wouldn't use it that much."

*stream

Jul 22 '05 #4

P: n/a

<ph*****@gmail.com> wrote in message news:11**********************@z14g2000cwz.googlegr oups.com...
Thinly wrapped socket classes like these are the first steps toward a
cross platform sockets library. Code like

sock.send("hello", 6);

means you still have a way to go to make working with sockets easy

and
safe.


Yea, I've been wanting to make a steam-based interface for it - but I
don't know how :) I also fear I wouldn't use it that much.

[snip]

Look at C++ stream-compatible TCP/IP sockets at
* http://sourceforge.net/projects/cpp-sockets/
* http://alexvn.freeservers.com/s1/sock.html
--
Alex Vinokur
email: alex DOT vinokur AT gmail DOT com
http://mathforum.org/library/view/10978.html
http://sourceforge.net/users/alexvn

Jul 22 '05 #5

P: n/a
Sorry if this is a double post.
3. putting underscore in front of member variables
the underscores are
there for a reason - Intellisense in VS.NET can get cluttered with
private methods/variables, so I use it to seperate them


It's just that identifiers starting with underscore are reserved for
compiler use.
How about using "m_" instead? Intellisense stops working anyway as soon
as you start using lots of angle brackets.

A few other comments:

1. You throw in your socket destructor. This makes it very hard to use
safely. In particular, you won't be able to safely put it in Standard
Library containers. Use catch(...) to keep exceptions from propagating.

2. You prevent copy construction by throwing when you can catch almost
the same errors at compile time by making the copy constructor private.

3. If I use your socket I'll find a way to avoid calling
WSAStartup/WSACleanup on every construction/destruction.

Jul 22 '05 #6

P: n/a

Hans Malherbe wrote:
Sorry if this is a double post.
3. putting underscore in front of member variables
the underscores are
there for a reason - Intellisense in VS.NET can get cluttered with
private methods/variables, so I use it to seperate them


It's just that identifiers starting with underscore are reserved for
compiler use.
How about using "m_" instead? Intellisense stops working anyway as

soon as you start using lots of angle brackets.
Compilers use __double underscores, single underscores should be fine.

A few other comments:

1. You throw in your socket destructor. This makes it very hard to use safely. In particular, you won't be able to safely put it in Standard
Library containers. Use catch(...) to keep exceptions from propagating.

I'd rather throw an exception than leave a socket open without letting
the developer know. It is non-copyable, so usage in STL containers
(without smart pointers) is out of the question anyway.

2. You prevent copy construction by throwing when you can catch almost the same errors at compile time by making the copy constructor private.

The copy contructor _is_ private, the throw should never happen.

3. If I use your socket I'll find a way to avoid calling
WSAStartup/WSACleanup on every construction/destruction.


If built as a DLL, WSAStartup/WSACleanup is only called once. I put it
in the ctor/dtor to avoid apps needing to call an init()/cleanup()
function when using it as a static library. Though, now that I think
of it, this could probably be accomplished with a global class that
does this on ctor/dtor.

Jul 22 '05 #7

P: n/a
[ ... ]
It's just that identifiers starting with underscore are reserved for compiler use.

[ ... ]
Compilers use __double underscores, single underscores should be

fine.

A leading underscore followed by either another another underscore OR a
capital letter is reserved. A leading underscore followed by something
else allowable sometimes (e.g. as a class member) but not others (e.g.
as global variable). IMO, trying to memorize all the details of when
it's allowed and when it's not is a waste of time and likely to lead to
problems anyway -- it's better to just treat all leading undrscores as
reserved.

--
Later,
Jerry.

The universe is a figment of its own imagination.

Jul 22 '05 #8

P: n/a
>I'd rather throw an exception than leave a socket open without letting
the developer know. It is non-copyable, so usage in STL containers
(without smart pointers) is out of the question anyway.
Yes, bad example. What was I thinking?
Here's a better one:
In a function I declare a socket on the stack. Somewhere in the
function I decide to exit the function with an exception. If there's
something wrong with my socket at this time and it cannot close, my
program terminates. OUCH.

I know what you're thinking...
Just catch(...) in your destructor, check for uncaught exceptions and
rethrow if clear.
No, no, no!

Go look in c.l.c++.* and you'll find all the reasons why you have to
make absolutely sure exceptions never wander aimlessly out of your
destructors.
The copy contructor _is_ private, the throw should never happen.


Oops, sorry. You're right. Your version is better because the compiler
won't complain if a member function do a copy.
You might want to do the same for copy assignment.

Jul 22 '05 #9

P: n/a
Hans Malherbe wrote:
I'd rather throw an exception than leave a socket open without lettingthe developer know. It is non-copyable, so usage in STL containers
(without smart pointers) is out of the question anyway.
Yes, bad example. What was I thinking?
Here's a better one:
In a function I declare a socket on the stack. Somewhere in the
function I decide to exit the function with an exception. If there's
something wrong with my socket at this time and it cannot close, my
program terminates. OUCH.


Hmm.. I think we'll have to agree to disagree here. I'll make it
non-throwing with a #define.
I know what you're thinking...
Just catch(...) in your destructor, check for uncaught exceptions and
rethrow if clear.
No, no, no!

Go look in c.l.c++.* and you'll find all the reasons why you have to
make absolutely sure exceptions never wander aimlessly out of your
destructors.
The copy contructor _is_ private, the throw should never happen.
Oops, sorry. You're right. Your version is better because the

compiler won't complain if a member function do a copy.
You might want to do the same for copy assignment.


Jul 22 '05 #10

P: n/a
Here's another cross platform c++ wrapper library for sockets:
http://www.alhem.net/Sockets/
It separates networking code pretty well from code that has to use
networking...
And thanks Cory for making your code available!
Jul 23 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.