New C++ sockets library

[Cory Nelson]

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.

[Hans Malherbe]

>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("hell o", 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.

[phrosty]

> Thinly wrapped socket classes like these are the first steps toward a

cross platform sockets library. Code like

sock.send("hell o", 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.

[phrosty]

"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

[Alex Vinokur]

<ph*****@gmail. com> wrote in message news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

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

sock.send("hell o", 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

[Hans Malherbe]

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.

[phrosty]

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.

[Jerry Coffin]

[ ... ]

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.

[Hans Malherbe]

>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.

[phrosty]

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.