Dag-Erling Smørgrav wrote:
Don Dugger <[EMAIL PROTECTED]> writes:
But "streams" have been around a lot longer then c++. I first encountered
them in AIX protocol stacks. Didn't like 'em then either.
SysV streams and C++ I/O streams are completely unrelated (except that
they both originated at AT&T and one probably inspired the other)
Although the idea of pushing functional units down a pipe does seem
interesting, however I have never found it works very well in
practice, and the reason was always performance.
No "functional units" are being "pushed down the pipe" with C++ I/O
streams. The << stuff is mere syntactic sugar. What happens is
simply that the correct function is called to format each element and
pass it to the output stream.
Ok you don't like my way of describing it. Functional units lined up one
after the other or however
you prefer. The point is that they both use the word streams and that's
what both of them are about
functional units which pass information form one to the other.
My point was that I do believe that the one inspired the other. If you
know this not to be the case
please enlighten me.
I think the problem is in fact is a general problem the more under
lying functionality you have the less performance.
Wrong. Higher-level constructs allow the compiler more latitude to
optimize the code. This is why well-written Lisp, for instance, can
outperform well-written C (provided you use a decent Lisp compiler).
Wait are trying to say that it not true that doing more takes more time.
While I will agree that
higher-level constructs can lead to better optimization. I stand by the
statement, doing more stuff
takes more time.
If you need to you can us
e the c lib stuff and only use the c++
added functionality when it pays to. After all some of the c++ stuff
is just better, "//" comments and passing by reference and etc.
// comments are neither better nor worse than /* */ comments, and they
have been available in C for seven years now.
That's pure opinion and one that I haven't head.
C++ references are very nice, but almost impossible for a non-expert
to use properly (any object passed by reference *must* be of a class
which has a correctly designed copy constructor)
That doesn't make foo(int& i) very hard to use. And come on you seem to
be capable,
writing a copy constructor isn't that bad and when your done you have
done just as much
moving of the data as you need, if you leave that up to a compiler it
may not be what
you want. Of course there are time when your not concerned about
performance but I thought
that's what we there talking about. Look writing good code takes work
and if you think
that's going away by a better language get in line they been try for 50
years and so far
what see is what we've got.
I think the reason streams was added to c++ early on was that a lot
of people didn't like printf(), the found it hard to use, which I
never understood.
Nobody claims printf() is hard to understand, but it is neither
extensible nor type-safe.
And how many times have I seen "<<" simply impl'd as a printf(), how
does that change anything.
The tact is the first time someone told me about c++ they there telling
how they didn't have to use that
printf() thing any more, as if it was a life changing thing. I don't
think it's hard to use and
I agree that it has major draw back and you only mention two. I just
don't like iostreams and I happen
to agree that there performance is bad.
What C++ lacks to be a top-notch OO language is garbage collection and
iterators which aren't a PITA to use. Both will be present in C++0x.
DES
I'm not sure I follow that statement, however lisp is not a replacement
the c++ and OO is not the only way
to go and in many cases is a very pour way to go. While I like it for a
lot of reasons I don't think that
it's the answer to all the problem that come along. Hey I like lisp too
but there's times it just not the right
language for the job.
Don 8)
_______________________________________________
freebsd-chat@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-chat
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
