RE: C++ Development

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

<added>
I had forgotten about having other programs link into Nmap, and that _does_
cause some big problems if nmap is in C++, so I am going to defer to
Fyoder's point.  However, I decided am going to send this response to
Etaoin's message anyway, as there are some questions that I have based on
it, and some of the points might be interesting to some people.  Besides, I
spent a lot of time typing it, and I am going to feel like I wasted a lot of
time if I don't send it SOMEWHERE, hehe.

Considering I am now going to agree that core nmap development should be
continued in C, the sections marked digressions are even more digressions
than they were before before :).  I'm really interested in responses to the
points about "what goes into nmap" sections (which are marked <important/>).

Oh, and to comment on Fyoder's point #3 quickly:

I wasn't suggesting building a new nmap from scratch.  I was simply thinking
that a slow migration towards a C++ code base might be desirable, slowly
swapping out this with a C++ part there, and this with one there, etc.
</added>

------------------------------------

My responses to your comments are inline.  The really important bits are
marked as <important/> and the all out digressions are labelled as
<digression/>.

Sincerely,
Jay Freeman (saurik)
saurik () saurik com

> -----Original Message-----
> From: shrdlu () cnchost com [mailto:shrdlu () cnchost com]On Behalf Of Etaoin
> Shrdlu
> Sent: Saturday, September 09, 2000 10:00 PM
> To: Nmap-Dev
> Subject: Re: C++ Development
>
>
> "Jay Freeman (saurik)" wrote:
>
> [some very well written, and quite lengthy, arguments as to why nmap
> might be moved to C++]
>
> > 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 am leaving in the first couple of lines, so that you might thing about
> tightening up the rules on your Outlook (all the funny question mark
> things are those special MS characters that don't really transcribe too
> well). I left them in to make a simple point.

Personally, I like those characters :).  I hope this response will be more
to your stringent likings.

> While it might seem useful to add in the complex and rich language of
> C++, instead of using the more restrictive C, the baggage that comes
> along with it brings unexpected extras that might not fit in with the
> purpose of the tool. I am already beginning to find nmap growing large.
> I see many proposed functionalities, such as application/port
> determination, but at least these are optional add ons.

<important>
OK, so you would rather keep all this stuff out of nmap.  That's a rather
useful opinion.  What are your thoughts on some of the features that are
already in nmap?  IP Protocol scan?  RPC scan?  Those seem to go away from
the original concept of just having a port scanner.  Maybe what is needed is
more feedback here about what is even ending in nmap in the first place.
</important>

> Not everyone is a fan of C++. I consider it to be a garbage language,
> although I liked it (and used it) in some of its earlier incarnations.
> It is not as though it is a separate language from C, but is rather
> quite dependent on it. Much of the claimed improvements from such things
> as STL are just that: claims. When I compare similar code written in C++
> and C at the assembler or machine code level, the C++ is less efficient.
> With a tool such as nmap, efficiency counts.

<digression>
This is EXACTLY what I'm talking about.  Someone who did work in C++ "in
some of its earlier incarnations" and now seems to have a vendetta against
it.  Yes, some stuff is going to be more inefficient at the assembly level.
Yes, you could definitly make a more efficient anything than STL provides.
The real question is: did you?  Nmap didn't.  It has some optomizations in
it, but most of what it does isn't the most efficient way to do it (and I
don't mean "most" like "most" possible, I mean it in a relative sense).
</digression>

<important>
BTW, here is the real crux of the problem.  Does it count?  In Nmap, of all
tools, does every last drop of power that can be squeezed out of the
compiler count?  We aren't talking about orders of magnitude here.  Maybe
I'm not using Nmap the way other people are, but I've never needed more
speed out of it.  I even go as far as to purposely sacrifice speed by using
a non-parallel implementation of a dinky language I wrote for scanning ports
and determining what is running on them (nmap+V).  The only time I sit
around staring at Nmap wondering "man, this sucks" is when Nmap can't scan
the remote host for whatever reason, and doesn't know that it can't.

<important>
I would be much happier making the scan last longer, but have 5 more ways of
getting information from the remote host, one of which having the
possibility of telling Nmap: "this scan is going to make you go crazy and
take an hour to complete because this host is purposely blocking this kind
of scan, or is running an OS that doesn't support it, don't waste an hour
sitting there pretending to try it just to return that all the ports are
'open'".  This would go a long way towards speeding up scans than a small
amount of low-level efficiency ever could.  Unfortunatly, in its current
state, the chance that Nmap will ever have something like that is minimal.
Every time someone has come up with anything that isn't a blanket scan (such
as IP protocol, or the RPC scan), something that only has special
circumstances where it is useful, like the Cisco scan I always use in my
examples, it has been denied by Fyoder, a decision I agree with.  Right now,
Nmap can't handle a bunch of special purpose scans (which would be required
for most of the cases of "scans don't work here"), no matter how useful they
might be.  The code base would just become too difficult to deal with for
the major maintainer: Fyoder.
</important>
</important>

<digression>
Most of this could be elieviated by rearchitecturing it and leaving it in C.
I agree with that.  But you could go a lot farther if you could have
complete encapsulation of scoping and had cleaner syntax for just about
everything, including memory allocation... I'm sick of looking at malloc()
calls.
</digression>

> If this were a large "software engineering" project, requiring multiple
> bodies, and design experts, and all that other claptrap from the 70s and
> 80s, something like C++ helps to keep everyone in the same camp, on the
> same road, and singing the same tune. It occupies the place that Ada had
> been expected to, and doesn't do too bad a job of it.

<important>
This _is_ a "software engineering" project.  Fyoder isn't the _only_ person
working on Nmap.  There are lots of people out there, _all_ working on Nmap.
Finding this bug, contributing this feature, or that optomization.  Nmap has
the potential to be a really large, very important project, capable of doing
just what it claims to: network map.  The real question is: does Nmap
realize that.  I think it does.  I believe Fyoder realizes that, based on
all the conversations I've had with him and everything he has stated on the
list.  A lot of other people out there do as well, as can be extrapolated
from the discussions of modularizing Nmap, and the shear fact that people
bother to put together the new functionality in the first place.
</important>

<digression>
I understand that you like C, and I agree that you can achieve almost the
same abstractions in C as you can in C++.  The question is, do you want to?
After all that the world has learned, do you care enough to hoist the flag
of C over your head and believe that you have the "last language".  That's
the question we, as programmers, must all ask ourselves at some point.  But
I digress :).
</digression>

<important>
If what you are really saying is that you want Nmap to be a small project
developed almost solely by one person that does only a few core bits of
functionality, then OK.  I understand your arguments.  I don't agree with
them, but I understand where you are coming from on every one of your
points.  Yes, efficiency matters, we can gain code clarity by just chopping
out the parts we don't need, and not adding anything else that isn't
essential in the future.
</important>

> > Anyone out there mind helping me understand why people don?t like C++?
>
> I would have been one of the people answering the survey who claimed
> that C++ sucks. My opinion hasn't changed. When I interview someone, I
> ask which language they learned first, and it counts against them if it
> was C++, then C, rather than the other way around (not much, but it can
> be a deciding factor).

<digression>
<digression>
I'm quite the opposite.  I've always found that people who learned C first
think in C first, and never quite "get" the OOP way of doing things.  I am
often used by a company I work for, as well as my college (and occasionaly
my old high school) to make decisions about programmers and what their
capabilities are.  To me, there are two big hits you can have against you:
you don't know C++, you learned C before C++ and use it for everything.
</digression>
</digression>

> > 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.
>
> Here you are mistaken. The footprint for C is much smaller than C++, due
> to the libraries that you don't need to include. You can write clean,
> well formed code in C, without classes (use struct instead), and without
> all of that terrible overhead and obfuscation that seems to be part and
> parcel of C++. Sure, memory handling can be better in C++, but
> forgetting to free memory in C++ is just as disastrous as in C, and just
> as easy. Array overruns, infinite loops, and any other problems you
> might think of exist equally in both. At least with C, I know that it
> will compile everywhere, and I know where to find the libraries for it.

Wasn't claiming that C++ did that, just that if need be, a developer could
do that in C and make it have similar syntax and equivilant functionality as
C++ objects.  The paragraph you quoted was a block to keep you from bringing
up that argument by bringing it up myself.  My point was that having STL and
I/O streams means I don't have to have all sorts of linked list or dynamic
array management code in my program.

<digression>
Obfusication?!?  Where are you getting this stuff from?  I would MUCH rather
look at C++ code than C code with pseudo-objects.  Things like being able to
declare my object on the stack, AND call its constructor, and having its
destructor called AUTOMATICALLY when it goes out of scope.  Let's see...
have a pointer, call a pseudo-constructor, allocate on the heap, use "->"
instead of ".", then explicitly call the destructor in the end... no....
Maybe have my pseudo-constructor call take a pointer to an already existant
memory area, but then I need to always allocate memory up front and I still
need to call my destructor.
</digression>

Once again, I don't consider C++ a magical solution.  I do NOT CLAIM that it
helps with memory management and keeps you from making stupid mistakes.  I
did not, I will not, and I do not now.  I claim that it has easier syntax,
that it already has abstractions of various data structures that are
reletively efficient... MORE EFFICIENT than what most people would build off
the top of their heads (which is how most of nmap is written), EASIER to
swap out later when you realize that linked list really should be a tree
because now we need to search it.

> I have had years of experience with multiple languages, everything from
> CDC Compass (for the Cyber) to PIXAR assembler for the CHAP (that was a
> GREAT machine, I loved it), from PASCAL to SNOBOL, and from LISP (more
> dialects than I care to name) to C++. Please, leave nmap in C. You can
> make all the C++ additions you want -- it's not like it won't compile
> for you.
>
> Sorry for the novelette, guess you touched a nerve.
>
> .shrdlu
>
> --
> Computer security is an oxymoron.
> Prepare for the worst.
>                 -- Bruce Schneier


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