Re: "STL from the Ground Up"
- From: Michael <kain0_0@xxxxxxxxxx>
- Date: Fri, 15 Feb 2008 21:24:01 +1000
On 2008-02-15 13:38:54 +1000, Jon Harrop <usenet@xxxxxxxxxxxxxx> said:
My seven cents...
"Stephen Howe" <sjhoweATdialDOTpipexDOTcom> wrote:Such as? F#? Ocaml?
Even C# would be a significant step in the right direction.
In what sense? Because it supports Garbage collection?
For one, yes. There are many other benefits as well like safety, a
high-level intermediate language than can interoperate with many other
languages, run-time compilation and so on.
Yes, it provides safety in the face of incorrect programming and subtle flaws. In somecases this is usefull. However it is usually more agreeable to have well written code in the first place.
Intermediate languages (i assume your refering to Java Bytecode & others?) are not features of a language. It is perfectly acceptable for java, C#, and your lovely languages to be directly compiled into processor native instructions. Vice versa, C, C++ and even fortran 77 could be compiled to the intermediate languages. (I do concede that these compilers aren't common or even existant. I assume that if the need was sufficient the task of writing such would be undertaken.)
Run time compilation? Is a feature of an IDE - XCode can be set to perform run time behind the scenes compilation of c, c++, objective-c and java. (At last reference many months ago, the feature isn't likely to have been dropped).
Garbage collection has been around since the 1950s,
Garbage collection has come a long way since then and remains an active
research topic.
True. He wasn't saying it doesn't have a place, he was saying that it is not necessary. In some circumstances it may even become a hindrance (Typically speed of allocation during a time important code sequence.)
Another situation is during guarded allocation to detect buffer overruns. It is more useful to findout closer to the offending code. In GC the error may never be found for years.
it is good for some problems but it is no universal panacea.
Sure but there are very few problems that GC is bad for, e.g. embedded
devices.
It isn't that usefull.
The real power of garbage collection is that it is an enabling technology
for language features like first-class lexical closures that could not
exist usably without it.
True.
And I have seen Herb Sutter's presentation on template support for Java,
C# and C++.
C++'s was the most flexible.
Absolutely. C++'s template system is a Turing complete programming language.
This "flexibility" is one of the reasons why C++ is so slow to compile and
it is the main reason why error messages from template-heavy C++ code are
so obfuscated.
I've made extensive use of both template metaprogramming in C++ and
parametric polymorphism with type inference in SML, OCaml, Haskell, F# and
so on. The latter is simply vastly more productive for a huge variety of
tasks.
To each his own.
Usually a language that provides molly coddling is not fast.
Our products got a lot faster.
Faster than a comparable compiled c/c++ program. Or faster in comparison to prior versions of the same program?
How?
My work was impossible in C++ five years ago and I'm quite sure it will
be impossible in C++0x. They are decades behind the current state of the
art...
In what areas are they behind?
Off the top of my head:
. Static checking.
. Encapsulation.
. Pattern matching.Regex, yes? Usually seen as a library in anything bellow a scripting language.
. Type inference.Hmm, RTTI
. Interoperability.I can't think of anything more common than c. Most OS's are written in it, and export to it.
. Run-time compilation.IDE. Look at XCode, i'm sure there are others.
. Marshalling.This sounds like RPC and related. See Pattern Matching.
. Compile times.I would rather a slightly longer compile vs run time.
. Optimizations.hmm, This would be compiler dependant. If i'm not wrong most optimisation are micro and applied to an intermediate language between input and output. The best place to look for optimisations would be in a multi language compiler.
. Concurrency.Wow, threads (and synchronisers). Again usually in libraries (re Marshalling & PMatching). Many languages don't support concurrency as primitives because of the many approaches to achieve it. You would be limiting the code's portability.
. Parallelism.Yes, similar arguement as with concurrency. It is best to let the compiler decide, or the system decide.
. Structural typing.Probably a given, you've found a hole i my knowledge.
. Recursion.Most languages support recursion, C and C++ do. Are you instead refering to thier optimisation?
. Closures.Probably a given, you've found a hole i my knowledge.
This has an adverse effect on lots of practical applications like parsing
and the manipulation of trees.
it does? I never knew using a library would be wrong. That is the usual method for gaining access to complex methods, without having to write them ground up.
Cheers,
Mike
.
- Follow-Ups:
- Re: "STL from the Ground Up"
- From: Jon Harrop
- Re: "STL from the Ground Up"
- References:
- "STL from the Ground Up"
- From: Stephen Howe
- Re: "STL from the Ground Up"
- From: Jon Harrop
- Re: "STL from the Ground Up"
- From: Stephen Howe
- Re: "STL from the Ground Up"
- From: Jon Harrop
- Re: "STL from the Ground Up"
- From: Stephen Howe
- Re: "STL from the Ground Up"
- From: Jon Harrop
- "STL from the Ground Up"
- Prev by Date: Re: "STL from the Ground Up"
- Next by Date: Re: LLVM was Results of the memswap() smackdown . . .
- Previous by thread: Re: "STL from the Ground Up"
- Next by thread: Re: "STL from the Ground Up"
- Index(es):
Relevant Pages
|
