Re: The Decline of C/C++, the rise of X
From: Walter (walter_at_digitalmars.nospamm.com)
Date: 07/25/04
- Next message: Ricardo Gibert: "Re: Ranking Without Sorting"
- Previous message: Aarlo Stone Fish: "Re: Ranking Without Sorting"
- In reply to: Eric: "Re: The Decline of C/C++, the rise of X"
- Next in thread: Eric: "Re: The Decline of C/C++, the rise of X"
- Reply: Eric: "Re: The Decline of C/C++, the rise of X"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 25 Jul 2004 06:57:36 GMT
"Eric" <anon21h@yahoo.co.uk> wrote in message
news:5ed9ec27.0407240108.40d42a66@posting.google.com...
> "Walter" <walter@digitalmars.nospamm.com> wrote in message
news:<aLTLc.145018$IQ4.139615@attbi_s02>...
> > D has these with the exception of bit-fields, which aren't that useful
and
> > easilly emulated.
> Can they be easily emulated with the same savings in space?
Yes.
> Bit-fields
> tend to be most useful for encoding Boolean values in data structures
> that will be instantiated a very large number of times (e.g token info
> in a lexical analyser, transaction info in a transaction processor,
> etc).
I usually just define some bit masks in an enum for that.
> If the D compiler automatically compacts several boolean fields in a
> struct into a bit-field, then I'd say you've taken good care of
> business :-).
Sadly, it doesn't do that yet, though nothing in the D spec would prevent
it.
> > D is generally a garbage collected language. However, one can still
allocate
> > on the stack, use malloc/free, statically allocate, or roll your own
> > allocator on a per-class or case-by-case basis.
> Most flexible indeed. How do all these interact though? Did you have
> an problems defining the rules for that degree of flexibility?
There isn't any problem interacting with them, other than one shouldn't try
to free() a pointer obtained from the gc, and such obvious errors.
Implementing RAII is hard, but that's par for the course.
> > D offers garbage collection for automatic memory management. However,
one
> > can still use RAII techniques for resources that are not appropriate for
> > lazy gc. One can also use stack allocation, explicit malloc/free, etc.,
as
> > explained before.
> Can you *mix* both in a program?
Sure.
> If so, I'd be interested to see how
> you make the GC stay out of the way during the execution of critical
> sections for example.
GC collections can be paused/resumed if desired.
> > > Those are the simpler issues,
> > > the harder one is efficiently abstracting the memory mapping idiom
> > > used to facilitate access to things like I/O ports (this is crucial
> > > for things like writing device drivers).
> >
> > Not sure what you mean here.
>
> You know, like taking a pointer to the video buffer and doing your own
> blit operations for graphics. Or like the way the x86 architecture
> allows memory mapped I/O ports, which you can access via pointers in
> C/C++.
You can do it in D just the same way you'd do it in C/C++.
> > Although D offers const as a storage class, it is not a type modifier.
After
> > many years of experience with C and C++, I haven't found
const-correctness
> > to be a useful attribute of a language. It's never found a single bug in
any
> > of my programs.
>
> Oh ok. Could it be because C++ allows const-ness to be cast away hence
> somewhat defeating the feature? I am under the impression that having
> it would help with some optimisation scenarios (e.g if you use ref
> counting GC, it helps eliminate the need for an increment/decrement
> operation because assignments are not allowed on the reference).
Actually, C++ const is quite useless as a hint to the optimizer. The reason
is because const can be cast away, and also because one pointer being a
pointer to const doesn't prevent any *other* pointer from altering that
supposedly const location. Oh well.
> This recent wave in the increased publicity of design patterns, seems
> to be a good source of info on what future languages could support
> natively. If something is done so commonly that you can recognise it
> as a pattern, then there's a good chance you can provide native syntax
> for it (I suspect thats how we got the "for..each" loop construct in
> some languages).
I agree.
> D's probably the closest language in existence, to being able to
> replace C/C++. With your impressive track record Walter, you should
> don a suit and tie, then go convince Joe CEO to give you wads of cash
> and promote D. You really should :-).
LOL. Donning a suit and tie and giving presentations to CEO's is something
I'm not good at. A man's got to know his limitations, you know! Besides, if
a CEO actually does give me wads of cash, it'd probably just delay D as I'd
be reporting to him rather than the D users.
> > 1) internationalization support - D front-to-back supports UTF-8, UTF-16
and
> > UTF-32 character encodings, leaving behind code pages,
> > implementation-defined wchar sizes, etc. Internationalization is where
the
> > future is.
>
> Sweet. And the standard library works transparently for all those
> encodings?
It's supposed to. It's not quite there yet.
> (i.e do you have overloaded versions of functions for each
> encoding?)
No, that's the beauty of it. You just have to provide one. UTF-8, etc., are
all easilly converted between each other. There's no need for a separate,
parallel set of 'w' functions like C has.
> > 2) generic programming - D supports templates, partial specializations,
> > explicit specializations, etc., and even mixins.
>
> Great. What about constraints?
D 2.0 <g>.
> Can templates be compiled and
> distributed in binary form?
With D you get 'exported templates' for free falling out of the semantics of
the language. If an implementation chose to do it in binary form, that would
be easy enough to do.
> How do you address the issue of code bloat?
How so? Template instantiations are done as COMDAT records, and the linker
discards duplicates.
> Do you check them at the point of definition or at the point of
> instantiation?
Template arguments are evaluated in the scope of the point of instantiation,
template bodies are evaluated at the point of definition. Just as one would
expect <g>.
> > 3) inline assembler - while many C/C++ compilers support it, they do so
as
> > incompatible extensions. D supports inline assembler in a defined,
> > consistent format. Inline assembler is very important for writing system
> > apps and doing low level support code.
> Excellent. I suppose you use x86 assemby code?
Yes.
> Does the language spec allow use of any other?
If you're using a CPU with a different instruction set, yes.
> > 6) C ABI compatibility - C is the lingua franca of the programming
world. D
> > recognizes this and fully supports the C ABI (even better than C++
does). C
> > functions and all C datatypes can be accessed directly without resorting
to
> > wrappers, marshallers, or complex protocols. No need to put the C code
in a
> > separate DLL, either, just link it in.
>
> Does it work the other way round as well? i.e C/C++ -> D? I think that
> would help increase D's rate of adoption.
Having implemented a C++ compiler, I know what that entails - implementing
much of a C++ compiler within D. Unfortunately, that goes way beyond the
scope of D.
-Walter
www.digitalmars.com/d/ The D Programming Language
www.digitalmars.com/d/ctod.html comparison with C
www.digitalmars.com/d/cpptod.html comparison with C++
www.digitalmars.com/d/pretod.html comparison with C preprocessor
www.digitalmars.com/d/comparison.html feature comparison table with
C/C++/C#/Java
- Next message: Ricardo Gibert: "Re: Ranking Without Sorting"
- Previous message: Aarlo Stone Fish: "Re: Ranking Without Sorting"
- In reply to: Eric: "Re: The Decline of C/C++, the rise of X"
- Next in thread: Eric: "Re: The Decline of C/C++, the rise of X"
- Reply: Eric: "Re: The Decline of C/C++, the rise of X"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
