"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahdqvg$1cru$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message
> news:ahd42a$lt8$1@digitaldaemon.com...
> Just to clarify: .net doesn't have a VM. It's just got a runtime.
Microsoft
> calls it CLR for .net
> and CLI in the ecma spec Common Language Runtime (or Infrastructure I
> think).

Let me put it another way. If I download a C# app (not source code, but a ready to run app), I need the VM, CLR, or CLI which is (correct me if I'm wrong) over 10 megabytes of memory. That may not be so important in the future, but it is now.

> For some embedded work this is probably mandatory. I get the feeling,
> though, that
> many system apps do not require this feature. Though it doesn't hurt to
have
> it.

Correct, you can write systems apps that don't use inline assembler, but the more sophisticated and commercially successful ones generally do.


> I just don't like to see too much Java and C# bashing here on the D
> newsgroup.
> You can write compilers, editors, jvm's in Java (can't say I know *how*
they
> did it), so

I took the Java compiler written in Java and translated it to C++. It ran ten times faster.

> I'm sure that it would be pretty hard to come up with a task that just
flat
> can't be done.

Sure, it's less of an issue of can/cannot be done, but how practical it is.

> > 2) it doesn't require an abstraction layer or virtual machine between it
> and
> > the actual hardware
> Does this mean that D doesn't have a runtime?
> Or more likely that you can optionally leave out the runtime at link time?

D does have a runtime, but it is pretty minimal at 40k rather than multiple megabytes. The runtime can also be bypassed for special apps. One other conceptual difference is that D apps do not run under the control of the runtime (like Java and C# apps do), the runtime is an accessory to the D app. D apps do not run in a sandbox created by the runtime, and D apps can do every down and dirty programming trick if you really want to use them.


> > 3) it can interface directly to the raw operating system entry points
> Is this the C  interoperability at work?

Yes. I don't know how that works in C#, but in Java to call a C function you need to create a DLL with wrappers, and you need to do considerable translation for passing other than the most basic types.


> > 4) type checking, semantic analysis, etc., is done at compile time, not
> run
> > time, so the executable code runs at maximal speed with minimal overhead
> I also get the feeling from other posts that the D implementation uses
whole
> program optimisation techniques to decide when methods need not be dynamically dispatched. yes?

D can do this, although the current implementation does not.

"Walter" <walter@digitalmars.com> wrote in message news:ahf57o$2j1a$1@digitaldaemon.com...
>
> "Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahdqvg$1cru$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message
> > news:ahd42a$lt8$1@digitaldaemon.com...
> > Just to clarify: .net doesn't have a VM. It's just got a runtime.
> Microsoft
> > calls it CLR for .net
> > and CLI in the ecma spec Common Language Runtime (or Infrastructure I
> > think).
>
> Let me put it another way. If I download a C# app (not source code, but a ready to run app), I need the VM, CLR, or CLI which is (correct me if I'm wrong) over 10 megabytes of memory. That may not be so important in the future, but it is now.

I don't know how much memory the CLR takes up. I think the embedded version is being worked on.

> *snip*
>
> > I just don't like to see too much Java and C# bashing here on the D
> > newsgroup.
> > You can write compilers, editors, jvm's in Java (can't say I know *how*
> they
> > did it), so
>
> I took the Java compiler written in Java and translated it to C++. It ran ten times faster.

Typical jvms has this lazy compilation of methods which I think is not such
a great idea.
This could have been a large part of the time taken. To see what a
difference it
makes you could use something like beanshell, run the compiler once to
ensure
it is compiled and then again to measure. It would be interesting to see how
the results differ when using gcj.

I can see, though, that with D, you don't have to worry about startup speed. And that's a good thing. Startup speed won't be such a factor with C#/CLR as it is with Java/JVM.

> > I'm sure that it would be pretty hard to come up with a task that just
> flat
> > can't be done.
>
> Sure, it's less of an issue of can/cannot be done, but how practical it
is.

Sure.

> > > 2) it doesn't require an abstraction layer or virtual machine between
it
> > and
> > > the actual hardware
> > Does this mean that D doesn't have a runtime?
> > Or more likely that you can optionally leave out the runtime at link
time?
>
> D does have a runtime, but it is pretty minimal at 40k rather than
multiple
> megabytes. The runtime can also be bypassed for special apps. One other conceptual difference is that D apps do not run under the control of the runtime (like Java and C# apps do), the runtime is an accessory to the D app. D apps do not run in a sandbox created by the runtime, and D apps can do every down and dirty programming trick if you really want to use them.

I'm not sure what you're getting at here. Could you please provide an example?

> > > 3) it can interface directly to the raw operating system entry points
> > Is this the C  interoperability at work?
>
> Yes. I don't know how that works in C#, but in Java to call a C function
you
> need to create a DLL with wrappers, and you need to do considerable translation for passing other than the most basic types.

This is something that really makes D different. I really hate JNI wrappers.
CLR
has platform invoke but I don't know enough to comment on it.

> > > 4) type checking, semantic analysis, etc., is done at compile time,
not
> > run
> > > time, so the executable code runs at maximal speed with minimal
overhead
> > I also get the feeling from other posts that the D implementation uses
> whole
> > program optimisation techniques to decide when methods need not be dynamically dispatched. yes?
>
> D can do this, although the current implementation does not.

This could be hard/impossible to achieve in the face of dynamic loading.
Java implementations can handle this at runtime, purging native code when
dynamic loading causes invalidation of a this optimisation.
I think C# will optimise heavily within an assembly. Native code could be
purged when assemblies are loaded at runtime, too but I don't think the
current
implementations do it that way.

I like D. A smallish, fast to compile, fast to execute, modular, java-style
oo,  gc'ed language.
Practical for many purposes. No need to bash Java and C# to like D :-) I
like them all.

--Cheers, Steve.

Walter wrote:

> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ahci0h$47g$1@digitaldaemon.com...
> > Sets and ranges were both quite useful.
>
> > You can't use ++ and -- on enum variables in C++... can you in D?
>
> You know, I never thought of that. What do you think?

I would vote no, because I think that enums should be a different "idea space" than integers.

I'm likely to get outvoted, though, and that's ok.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

Walter wrote:
> 
> 
> 
> You know, I never thought of that. What do you think?
> 

It seems enums (anonymous especially) are used a lot for
constants, so it doesn't seem appropriate to modify them
like that.

Just my opinion,
 Jon

that got posted in the wrong place, Sorry!
> 

On Sun, 21 Jul 2002 22:32:14 -0700 Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:

>> > You can't use ++ and -- on enum variables in C++... can you in D?
>>
>> You know, I never thought of that. What do you think?
> 
> I would vote no, because I think that enums should be a different "idea space" than integers.
> 
> I'm likely to get outvoted, though, and that's ok.

Me, I like that feature of Pascal. Makes sense sometimes, when you have a set of sequential elements, and want to traverse back and forth. At least it doesn't hurt in other cases. =)

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:ahg4lr$g45$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:ahf57o$2j1a$1@digitaldaemon.com...
> > I took the Java compiler written in Java and translated it to C++. It
ran
> > ten times faster.
> Typical jvms has this lazy compilation of methods which I think is not
such
> a great idea.
> This could have been a large part of the time taken. To see what a
> difference it
> makes you could use something like beanshell, run the compiler once to
> ensure
> it is compiled and then again to measure. It would be interesting to see
how
> the results differ when using gcj.

Why it was faster in C++ is a complicated matter, it's more than just startup time. And no, it wasn't the garbage collector <g>.

> > D does have a runtime, but it is pretty minimal at 40k rather than
> multiple
> > megabytes. The runtime can also be bypassed for special apps. One other conceptual difference is that D apps do not run under the control of the runtime (like Java and C# apps do), the runtime is an accessory to the D app. D apps do not run in a sandbox created by the runtime, and D apps
can
> > do every down and dirty programming trick if you really want to use
them.
> I'm not sure what you're getting at here. Could you please provide an example?

For example, you can write a garbage collector in D. There is no way to do it in Java - the type checking and the sandbox will prevent it.

> This could be hard/impossible to achieve in the face of dynamic loading.

Yes, but currently D is not defined to deal with dynamic loading. <g>

> I like D. A smallish, fast to compile, fast to execute, modular,
java-style
> oo,  gc'ed language.
> Practical for many purposes. No need to bash Java and C# to like D :-) I
> like them all.

They each have their place. D is not targetted at what Java is, so the design tradeoffs are different. Using D for what Java is best at is inappropriate, and vice versa.

Enums with integer properties (++, --) would be nice. I sometimes like to mix integers and enums together. For example I may use the last 8 places for a byte storage and the first part for enable/disable bit flags. Although now D has bits included, it's still useful in things such as file saving. ++, -- and any other integer maths would be useful on enums, although I suppose it's possible to cast an enum to a int.

Also how about a specific structure or extention to enums for enable disable bits. I know that D's bits data type goses some way, but it doesn't provide a labling system enable/disable bits. And before you point it out, you could use:

enum EnableBit //You may reconise this from GL (Although it's missing a few)
{
    ALPHA_TEST = 1,
    AUTO_NORMAL = 2,
    BLEND = 4,
    COLOR_MATERIAL = 8,
    CULL_FACE = 16,
    DEPTH_TEST = 32,
    DITHER = 64,
    FOG = 128,
    LIGHTING =256,
    LINE_SMOOTH = 1024,
    LINE_STIPPLE = 2048,
    LOGIC_OP = 4096,
    NORMALIZE = 8192,
    POINT_SMOOTH = 16384,
    POLYGON_SMOOTH = 32768,
    POLYGON_STIPPLE = 65536,
    SCISSOR_TEST = 131072,
    STENCIL_TEST = 262144,
    TEXTURE_1D = 524288,
    TEXTURE_2D = 1048576
};

EnableBit CurrentEnable;

CurrentEnable &= ALPHA_TEST;
ect...


--------------------------------------------------------------------------------


But how about

enable EnableBit
{
ALPHA_TEST, //Auto generates the numbers

...
};

EnableBit CurrentEnable;

CurrentEnable &= ALPHA_TEST;

And even syntax sugur,

CurrentEnable.enable(ALPHA_TEST);
CurrentEnable.disable(ALPHA_TEST);
ect...


"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN37459427319294@news.digitalmars.com...
> On Sun, 21 Jul 2002 22:32:14 -0700 Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:
> 
> >> > You can't use ++ and -- on enum variables in C++... can you in D?
> >>
> >> You know, I never thought of that. What do you think?
> > 
> > I would vote no, because I think that enums should be a different "idea space" than integers.
> > 
> > I'm likely to get outvoted, though, and that's ok.
> 
> Me, I like that feature of Pascal. Makes sense sometimes, when you have a set of sequential elements, and want to traverse back and forth. At least it doesn't hurt in other cases. =)
> 

  "anderson" <anderson@firestar.com.au> wrote in message news:ahglim$12gp$1@digitaldaemon.com...
  Enums with integer properties (++, --) would be nice. I sometimes like to mix integers and enums together. For example I may use the last 8 places for a byte storage and the first part for enable/disable bit flags. Although now D has bits included, it's still useful in things such as file saving. ++, -- and any other integer maths would be useful on enums, although I suppose it's possible to cast an enum to a int.

  Also how about a specific structure or extention to enums for enable disable bits. I know that D's bits data type goses some way, but it doesn't provide a labling system enable/disable bits. And before you point it out, you could use:

  enum EnableBit //You may reconise this from GL (Although it's missing a few)
  {
      ALPHA_TEST = 1,
      AUTO_NORMAL = 2,
      BLEND = 4,
      COLOR_MATERIAL = 8,
      CULL_FACE = 16,
      DEPTH_TEST = 32,
      DITHER = 64,
      FOG = 128,
      LIGHTING =256,
      LINE_SMOOTH = 1024,
      LINE_STIPPLE = 2048,
      LOGIC_OP = 4096,
      NORMALIZE = 8192,
      POINT_SMOOTH = 16384,
      POLYGON_SMOOTH = 32768,
      POLYGON_STIPPLE = 65536,
      SCISSOR_TEST = 131072,
      STENCIL_TEST = 262144,
      TEXTURE_1D = 524288,
      TEXTURE_2D = 1048576
  };

  EnableBit CurrentEnable;

Should be...

CurrentEnable |= ALPHA_TEST; //Enable bit
  ect...


------------------------------------------------------------------------------


  But how about

  enable EnableBit
  {
  ALPHA_TEST, //Auto generates the numbers

  ...
  };

  EnableBit CurrentEnable;

Should be...

CurrentEnable |= ALPHA_TEST; //Enable bit

  And even syntax sugur,

  CurrentEnable.enable(ALPHA_TEST);
  CurrentEnable.disable(ALPHA_TEST);
  ect...


  "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN37459427319294@news.digitalmars.com...
  > On Sun, 21 Jul 2002 22:32:14 -0700 Russ Lewis
  > <spamhole-2001-07-16@deming-os.org> wrote:
  >
  > >> > You can't use ++ and -- on enum variables in C++... can you in D?
  > >>
  > >> You know, I never thought of that. What do you think?
  > >
  > > I would vote no, because I think that enums should be a different "idea
  > > space" than integers.
  > >
  > > I'm likely to get outvoted, though, and that's ok.
  >
  > Me, I like that feature of Pascal. Makes sense sometimes, when you
  > have a set of sequential elements, and want to traverse back and
  > forth. At least it doesn't hurt in other cases. =)
  >

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3D3B98DE.CDF15BC@deming-os.org...
> Walter wrote:
>
> > "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ahci0h$47g$1@digitaldaemon.com...
> > > Sets and ranges were both quite useful.
> >
> > > You can't use ++ and -- on enum variables in C++... can you in D?
> >
> > You know, I never thought of that. What do you think?
>
> I would vote no, because I think that enums should be a different "idea space" than integers.

Hmm..
Sometimes I use enum for naming the states of a process.
In this idea space it seems logical to read ++ as "step into the next
state". So please implement it.
I admit, there are some problems with the analogy: steping to the next
state, does not necessarily mean
"increment the underlying integer value with 1". Especially when the last
state is reached.

OTOH, there are cases when I use enums as a collection of unique values with names, but the particular value is not important. In these cases I would be really happy if the compiler would check that I do no integer operations on these values.

Summary:
The best would be two enum types! One with all integer operations (enum
alias), and one without any (enum typedef).

Yours,
Sandor