8/3 What do people think about STL (Standard Template Library) for C++?
I used it recently and it looks pretty cool. -emin
\_ STL is a good advance in terms of API, but the implementations
will need a while to mature to avoid foiling compiler
optimizations. This will come soon from KAI, Sun, et al. -mel
\_ for more docs try:
http://www.sgi.com/Technology/STL
--jeff
\_ for Java "port", see http://www.objectspace.com/jgl and forget all about
them java.util collection classes --petr
\_ It's pretty convenient.
\_ I think it tends to be arcane. (And I'm a Unix bigot, so I have
a high tolerance for arcana.) Having a copy of the C++ standard
handy helps. Failing that, Stroustrup is your friend, sort of.
-brg
\_ In my humble opinion if there is a real need to use templates
for what you need to do, Lisp may be a better language than
C++. -- ilyas
\_!!! You're kidding, right? A good portion of the reason
for using templates is for inlining code while providing
\_ huh? inlining code? stl has nothing to do with inlining.
\_ Try again. It has *a lot* to do with inlining. That
is what your functors do when you pass them to
classes like map, priority_list, etc.
\_ Even with STL, C++ is much much harder to write and maintain
than Lisp. Furthermore, there is little evidence that
explicit memory management outperforms a good garbage collector
receiving hints from the programmer (something Lisp allows and
encourages). -- ilyas
\_ The STL is about not having to write general-purpose
code any more. Efficiency is a requirement, not the
goal.
\_ My point is that we've had things like qsort()
in the standard library for a while, but you
had to pass a function pointer. That meant a
function call for every compare. Inlining the
code makes a *huge* difference.
flexibility. I don't need or want the overhead of a
garbage collector and closures.
\_ Even with STL, C++ is much much harder to write and
maintain than Lisp. Furthermore, there is little
evidence that explicit memory management outperforms a
good garbage collector receiving hints from the
programmer (something Lisp allows and encourages). -- ilyas
\_ "C++ is much harder to write and maintain than Lisp"?
Please list your sources for this ridiculous
assertion.
\_ This is not an academic point, but a practical one.
In practice, me and many of my friends and coworkers
found the assertion to be true. If it is not true for you
I would be happy to know why. -- ilyas
\_ ilyas loses THREE POINTS. -1: One of the biggest benefits of
templates is typesafe containers. LISP does not have type
safety at all. LISP can't compete.
-1: Large LISP programs are MUCH harder to maintain than
c++ programs. -ali.
\_ Given two programs of equal size (down to a line), a
Lisp program will probably have a LOT more
functionality than a C++ program due to Lisp's
inherent terseness. I don't see a single thing that
will make C++ easier to maintain in the long run.
Not only will a given amount of C++ code express a
lot less than the same amount of code of Lisp, but
the C++ maintaner is forced to cope with bugs on two
fronts -- memory and logic, whereas a Lisp programmer
only needs to worry about logic. Strict type safety
can be easily implemented in LISP using CLOS methods,
if the programmer wants it. -- ilyas
\_ The industry didn't side with typed languages like
C++ and Java over Lisp/Scheme on a whim. They did
it because the C++ projects were getting done on time
and on budget and the Lisp programs weren't. That's
why Lisp has been consigned to academia and think tanks
while C++ programmers have jobs. -mel
\_ This may be the case, although I certainly wouldn't
say industry sides with things for a good technical reason.
Witness clueless executives gather around NT like scared
cubs around their dead lioness mother. I don't know if
anyone actually did a rigorous in-depth study of software
development times across languages. It may be that Lisp
is consigned to Academia and think tanks, but remember that
this is generally where the best and the brightest make
their living. -- ilyas
\_ This is much like English vs. Spanish. People often
claim that Spanish is much more consistent and simpler
than English hence better. The problem with LISP is that
although simple and consistent, it's too simple and
consistent making it visually difficult to distinguish
different constructs and mechanisms easily (too many
parens and no type declarations). You can argue that
declarations are a bad part of language but on a large
scale they tend to help a lot whereas languages lke LISP
and LOGO or acceptable for grade school pedagogy uses.
\_ Declarations, type safety and private data members
are useful features of a language, but they tend
to be used as crutches by programmers who are not
careful. Which language looks visually more
intuitive is a very subjective thing. Moreover,
one shouldn't need a type declaration to be able
\_ I find type declarations very useful for various
reasons. It's ability to restrict space and
functionality of a variable helps increase it's
compactness and computational efficiency. Plus,
I don't mind having an explicit reminder of what
type something is. The alternative is to use
\_ I am saying that often these features are not
as necessary for programming as people say, and often
may be more trouble than they are worth. In
particular, static typing is often a cludgy,
complicated affair that really only tells the
programmer that he can't stick a round peg in a square
hole (something he ought to know anyways if he put
sufficient thought into design). Btw,
ad hominem has no place in a mature discussion.
-- ilyas
the Hungarian notation and I would rather declare
types any day over using the Hungarian notation.
\_ Hungarian notation is just one convention, and
a rather cludgy one at that. Also, if you remember,
this convention is mainly used in languages with
explicit types like C++ and Visual Basic -- if type
declarations were as helpful as some people say the
convention wouldn't need to be used in such languages.
Furthermore, it is not true that a language with
static typing has to have type declarations, remember
ML?
And it is not true that a language with dynamic types
has to be inefficient. Good programming practices and
a good compiler will make sure that most things you
care about, such as arithmetic, will be fast. -- ilyas
to distinguish variables, else one doesn't know
how to name variables correctly. That Lisp is a
pedagogy language is a serious misconception. --ilyas
\_ "tend to be used"? You're saying that because
some features are used by bad programmers in
the wrong way the language is flawed? Please
crawl back under the hole you came out of.
\_ I am saying that often these features are
not as necessary for programming as people
say, and often may be more trouble than they
are worth. In particular, static typing is
often a cludgy, complicated affair that
really only tells the programmer that he
can't stick a round peg in a square hole
(something he ought to know anyways if he
put sufficient thought into design). Btw,
ad hominem has no place in a mature
discussion. -- ilyas
\_ Neither do baseless assertions belong.
Go away.
\_ That's only TWO POINTS. You owe ilyas a point,
bitch.
\_ Everyone loses a point for taking part.
\_ Static typing is not especially useful. It requires
a lot of work for very little benefit. |
http://csua.com/feed/