Re: [leafnode-list] local groups, use as archive

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

phil hunt <philh@xxxxxxxxxxxxxxxxxxxxxx> writes:

> And before we had snprintf(), sprintf() had buffer lengthy problems.

Apart from broken (i. e. suffering from off-by-one faults) snprintf
implementations. Why not use the C++ approach and format each argument
on its own.

> > I'm wondering if switching to C++ would buy us anything, because it
> > would require reworking all APIs and group libraries functions and data
> > structures into classes, but I'm not feeling like spinning of yet
> > another leafnode derivative to try it, I don't have the time to do it;
> 
> If there was a group effort to do this, I'd be happy to lend a hand.

Thanks for volunteering, but we'll need for Cornelius' statement.

> Would it? What?
> 
> My understanding is that gcc is portable, and runs on lots of
> platforms.

Well, yes, but then again, you might encounter a system with SUNpro or
MIPSpro compilers, and my study thesis dealt with just that: adding a
piece to a software project supposed to work on an Octane (MIPSpro, no
ANSI C++ on *that* box, slow GCC) and on Linux (gcc 2.95.2). First of
all, I had to fix the borkne binutils on Linux, then I had to work
around missing features in MIPSpro. Might not be too much fun if you use
latest features.

I'm still looking for a good compiled language with *strict* typing
which it's easy to do secure POSIX network applications in.
 
> > and with some real passing around of classes, it gets a space and
> > performance issue as well.
> 
> This depends entirely on how well-coded it is. Well-written C++ shouldn't
> require any more resources performance-wise than well-written C.

You'd have to define what "well-coded" and "well-written" mean, first of
all. C++ is supposed to use a class approach, and "passing methods
through inherited classes" may easily bloat your code although it's
well-written in terms of maintainability.

> If the STL isn't very good, 

why not?

> > working around old compilers and things, which would then
> > compensate the advantages somewhat.
> 
> Would it not be possible to specify gcc as the compiler? Or use a
> subset of C++ (e.g. no templates or exceptions) that gets round some
> of the problems.

"No exceptions" is a limitation so severe you could as well stick to C.

> Leafnode could probably be re-written in Python quite
> quickly; unfortunately performance would be too slow, I think.

Leafnode is I/O bound, so that might not be so serious as you expect
now. 

Mailman is written in Python mostly; and if Python has a compilation
pass like Perl or Tcl 8 have, you might get long start-up latencies, but
still a good run-time performance, so that might not be too much of an
issue. The problem with interpreted language is memory consumption. You
can't really bound Perl's memory usage, not sure about Python or Tcl,
and you most certainly would not want to run the nntpd out of inetd, but
have it standalone and forking on its own.

-- 
Matthias Andree

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list