C++ Development

["Jay Freeman \(saurik\)" <saurik () saurik com>]

So I’m sitting here working on nmap+V, I’m thinking to myself “man, I wish I
was working in C++”.  I finally ask (for the umpteenth time), “Why aren’t
 I?”  That’s the question I am posing to this list :-).

I realize the question sounds pretty silly/stupid, asking why _I_ don’t do
something.  To emphasize this silliness, I am going to continue the rest of
this e-mail in dialogue form, just because I can (although, I will not claim
to do so well).

<dialogue>

Jay looks around him and sighs.  Frustrations having finally overwhelmed
him, he screams, “Why am I not working in C++?”

> From the other side of the room a sarcastic reply rings out, “I believe the
key word was ‘I’.”  “If you want to so much, use it.”

Looking a tad frazzled, Jay retorts, “You think this was my decision?”

“Wasn’t it?”

“Well, technically… yes… but every time someone has brought up the idea of
using C++ for anything before, people seem to freak.  Fyoder released a
survey a while back, and one of the questions was ‘do you have a working C++
compiler’, and 13.9% of the replies were ‘C++ sucks’, not even ‘yes’ or ‘no’
.  Not very encouraging when you are trying to write code that you want
other people to use.  8.5% answered ‘no’, which also surprised me.”

“Well, not sure if this helps, but I have always heard that C++ was less
efficient than C, and resulted in slower programs.  A while back some people
managed to get the Linux kernel compiling in the C++ compiler, and it ran
much slower than the same code compiling in the C compiler.  Since then, the
project was disbanded, and no one even brings that idea up anymore.”

“Yes, I heard about that as well.  But it wasn’t a by-product of using C++;
it was from using the C++ compiler, which, at the time, was much slower than
the C compiler.  With today’s C++ compilers, the difference _should_ be
non-existent.  Even if you use the STL to abstract such things as strings
and resizable arrays, you shouldn’t incur much of a penalty at all, if any.
It really depends on your usage.  Obviously if you decide that all of your
strings will be an STL std::string, and every time you need part of that
string you cut it apart and allocate new memory for the resultant sections,
you are going to be making your program a lot slower.  However, in many
situations, the wrappers that are provided map directly to what you would be
doing anyway, and don’t cause a speed disparity.  If every time I go to
resize my array, I’m reallocating the memory for it, and then copying the
data from the old buffer to the new one, the STL class isn’t going to be
doing something that’s slower than that.  Theoretically, the STL classes can
optimize your program past what you would likely do yourself by handing to
you, for no extra work, intelligent algorithms for data storage and memory
reallocation.”

 “Well, even if you _did_ start writing your code in C++ it still wouldn’t
be a perfect solution.  Your code needs to integrate with nmap, a C
application.  You are going to need to do a lot of extra work to export your
symbols correctly; and I know for a fact that even if it _is_ easy, the last
time you thought about it your stomach turned over sideways.”

“While that may be the case, the problem is no longer an issue.  A while
back I made all the necessary changes to nmap to get it compiling using C++
compilers, and as of nmap-2.54b4, Fyoder has integrated these changes into
the core distribution.  Not only can I start writing my code in C++, but I
_could_ start taking nmap and moving parts of _it_ over.  A lot of the
existing nmap code could be cut down _just_ with the addition of the STL
std::string and std::list classes.  There is way too much code keeping track
of how large buffers are, what memory is where, what parts of which
structures need to be initialized to what, that shouldn’t cause any problems
when abstracted.  Not to mention that a lot of the code could be organized
better if the functionality was syntactically bound to the data structures.”

“Whoa… hold up there.  One of the things nmap prides itself on is being able
to run on all sorts of platforms without issues.  If parts of it were moved
to C++, that would be greatly compromised.  C++ compilers always compile
things differently, and code that works perfectly on one system might not
work at all somewhere else.”

“No way!  I guess what they say about first impressions really _is_ true.
First, let’s go over a little history.  That was always because C++ wasn’t a
standardized language, and if a compiler wanted to exist it had to make some
assumptions in areas where the spec didn’t cover things quite correctly.
Combine that with the fact that the language was being modified in new
drafts every now and then, and of course you are going to end up with
compilers that don’t compile things quite right.  Never fear, this is no
longer the case.  As of a year and a half ago (maybe even two years ago),
C++ is now a fully standardized language, and almost all compilers have been
spec’d up to support the final drafts.”

“Yeah right… as if the compiler people ever care about the standards.”

“Sure a few compilers are more internally compliant than others, but the
differences are minimal, and almost always unnoticeable (just like C library
differences, which are usually easy to get around).  Unfortunately, g++, the
compiler we would likely be targeting, has a few annoying quirks, but in
general its standards compliance is almost on par with Microsoft VC++ (which
seems to be the leader in the C++ arena, assuming you turn off their hacks
to make VC++ 6.0 compatible with earlier versions that were build before the
standard).  Of the C++ standard problems I know of in g++, they are all
totally unnoticeable unless you are working on implementing the STL itself,
or have some unbelievably insane code structures set up.”

“Oh come on… why are we even discussing this?  Take nmap and move it to C++?
Fyoder would be all over you in a minute.”

“Actually, Fyoder seems like he would greet the process.  The reason he had
that question on the survey in the first place was because he was thinking
of moving nmap to C++ some day, a point he explicitly stated on the survey
itself (a quote: ‘Fyoder may move Nmap to C++’).  Also, if you read the
source code, in portlist.c there is a comment which reads ‘gawd, my next
project will be in c++ so I don't have to deal with this crap ... simple
linked list implementation’.”

“So one of your first goals would be to redo portlist?”

Jay pauses for a few seconds while he thinks that over, and then responds,
“No.  To tell you the truth, I don’t agree with this case.  The way portlist
works would _definitely_ be made much easier with C++, but the way portlist
is currently implemented (with a large array of pointers) allows for much
faster retrieval of ports from the list for a memory cost of no more than
64k, an amount which goes down as more ports are added (until the linked
list with 64k ports uses just as much memory as the pointer array).  Might
want to do something about how the freeports system, though.  C++ and STL
aren’t magical solutions for all cases, but they do have their place.”

“Good point.  I know some of those C++ people are a little wacky about ‘form
over function’ instead of ‘form follows function’, Frank Lloyd Wright’s old
adage.”

“Hopefully, as some of the sections are moved to C++, nmap will become
easier to manage in the future, and all of those nifty features that have
been put off or passed on will be more easily added.  That’s the real goal,
to make administration of the code easier and allow for more functionality
to be added without nmap losing all cohesiveness, not to make it faster.  We
should be able to build anything we want in C, its just a question of
whether we _want_ to build anything we want in C.  C++ cleans the syntax
slightly and makes the code easier to look at.”

“Hmmm.  Maybe I should take a look at this C++ stuff.”

“Unfortunately, that brings us back to the problem that people seem so
negative about C++.  Just like you and your preconceived notions based on
obsolete information, a lot of people out there seem to be anti-C++, as is
clearly shown by the results from Fyoder’s survey.”

“Well, that’s annoying….”

</dialogue>

Anyone out there mind helping me understand why people don’t like C++?  (Or
tell me that people _do_ like C++ now and I just didn’t notice? :-) )  74.9%
of the people answering Fyoder’s survey said they had a working C++ compiler
and didn’t answer, “C++ sucks”, so maybe there isn’t a problem.  Really, I
would just like to see this a little clearer, so I don’t find out later “oh,
no one really has any complaints with C++, we just like watching you make a
fool of yourself”.

As I mentioned, C++ can’t do anything C can’t, and C++ isn’t even that
fundamentally different from C (as “objects” can be built as structs with
“methods” that take pointers to the struct); but having STL and I/O streams
can make things much easier over the ways the equivalents are usually
implemented in C.

Sincerely,
Jay Freeman (saurik)
saurik () saurik com <mailto:saurik () saurik com>


---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to 
nmap-dev-help () insecure org . List run by ezmlm-idx (www.ezmlm.org).