www.digitalmars.com         C & C++   DMDScript  

D - switch default

reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
In debug build I got a "switch default" runtime error!

Is this true, that you *must* provide a default case, and that a switch
without a matching case is an error?  I dislike the idea of having to
provide an explicit default which does nothing, but there may be other
reasons for this (safety I guess)

Lotta little things to get used to in D.  ;)

Sean
May 27 2002
next sibling parent reply "Carlos" <carlos8294 msn.com> writes:
 Is this true, that you *must* provide a default case, and that a switch
 without a matching case is an error?  I dislike the idea of having to
 provide an explicit default which does nothing, but there may be other
 reasons for this (safety I guess)


it makes no sense to have a default in every switch. it would be like having
an else in every single if.
May 27 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Carlos" <carlos8294 msn.com> wrote in message
news:acurl4$g05$1 digitaldaemon.com...


 Is this true, that you *must* provide a default case, and that a switch
 without a matching case is an error?  I dislike the idea of having to
 provide an explicit default which does nothing, but there may be other
 reasons for this (safety I guess)


 it makes no sense to have a default in every switch. it would be like


having

 an else in every single if.


Not really so. It helps to resolve problems like when you add a new member
to an enum, and forget to add the appropriate case for it.

And besides, is a single "default:" at the end of case so hard to type?
May 27 2002
next sibling parent "Carlos" <carlos8294 msn.com> writes:
 And besides, is a single "default:" at the end of case so hard to type?


it is if you see it under one of 2 (or more) points of view:
1) under logical eyes (already explained)
2) under the eyes of a common C programmer
May 27 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:acuuif$kq6$1 digitaldaemon.com...

 "Carlos" <carlos8294 msn.com> wrote in message
 news:acurl4$g05$1 digitaldaemon.com...


<Snip>


 And besides, is a single "default:" at the end of case so hard to type?


1. The less code often makes things quicker to read (compare reading point
for to an essay).
2. Allowing optional components don't make things much more difficult.
3. If you can shave 10% of typing in a program, that's 10% more time to
spend elsewhere.

I agree that a language needs to be strongly typed, but something like not
using "default:" isn't going to cause that many more errors.
May 27 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:acv659$tb5$1 digitaldaemon.com...


 1. The less code often makes things quicker to read (compare reading point
 for to an essay).
 2. Allowing optional components don't make things much more difficult.
 3. If you can shave 10% of typing in a program, that's 10% more time to
 spend elsewhere.

 I agree that a language needs to be strongly typed, but something like not
 using "default:" isn't going to cause that many more errors.


In general, I agree with you. I just told the "official explanation" for
this
feature.
May 28 2002
parent reply "anderson" <anderson firestar.com.au> writes:
And before we start another war with the bracket clan :) As long as the
language is much better then C++ these things are really very insignficant.

PS - I wonder if they had the same arguments when inventing A,B,C, C++ and


"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad0218$27n0$1 digitaldaemon.com...

 "anderson" <anderson firestar.com.au> wrote in message
 news:acv659$tb5$1 digitaldaemon.com...


 1. The less code often makes things quicker to read (compare reading




point

 for to an essay).
 2. Allowing optional components don't make things much more difficult.
 3. If you can shave 10% of typing in a program, that's 10% more time to
 spend elsewhere.

 I agree that a language needs to be strongly typed, but something like




not

 using "default:" isn't going to cause that many more errors.


 In general, I agree with you. I just told the "official explanation" for
 this
 feature.
May 28 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:ad035g$2960$1 digitaldaemon.com...


 PS - I wonder if they had the same arguments when inventing A,B,C, C++ and




be terminated...
May 28 2002
prev sibling parent "Matthew Wilson" <mwilson nextgengaming.com> writes:
Surely the cost of writing some code is inconsequential c/w the effort of
diagnosing bugs and/or maintaining & updating code? Or have I missed
something fundamental in all these years ... ? ;)

"anderson" <anderson firestar.com.au> wrote in message
news:acv659$tb5$1 digitaldaemon.com...

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:acuuif$kq6$1 digitaldaemon.com...

 "Carlos" <carlos8294 msn.com> wrote in message
 news:acurl4$g05$1 digitaldaemon.com...


 <Snip>


 And besides, is a single "default:" at the end of case so hard to type?


 1. The less code often makes things quicker to read (compare reading point
 for to an essay).
 2. Allowing optional components don't make things much more difficult.
 3. If you can shave 10% of typing in a program, that's 10% more time to
 spend elsewhere.

 I agree that a language needs to be strongly typed, but something like not
 using "default:" isn't going to cause that many more errors.
May 28 2002
prev sibling next sibling parent reply "cblack01" <cblack01 cox.net> writes:
Hey,


reflection?

parameters using the params keyword like this:

void Print(params string stuffToPrint[])
{
    foreach(oneThing in stuffToPrint) System.Console.WriteLn(oneThing);
}

Then you would call it like this:

Print("Printing ", "variable ", "parameters");


use it since I do a lot of scientific applications that are too



Thanks,

Craig
May 28 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"cblack01" <cblack01 cox.net> wrote in message
news:ad0rbq$88q$1 digitaldaemon.com...


 reflection?


Only partially, via the .classinfo property.





variable

 parameters using the params keyword like this:

 void Print(params string stuffToPrint[])
 {
     foreach(oneThing in stuffToPrint) System.Console.WriteLn(oneThing);
 }

 Then you would call it like this:

 Print("Printing ", "variable ", "parameters");


D does variable parameter lists exactly like C does. While not typesafe, it
is efficient.
May 28 2002
parent reply "Matthew Wilson" <mwilson nextgengaming.com> writes:
Walter,


good. Would the performance be prohibitive? Do you have any
figures/impressions as to how much it would cost?

"Walter" <walter digitalmars.com> wrote in message
news:ad0uv7$cbc$1 digitaldaemon.com...

 "cblack01" <cblack01 cox.net> wrote in message
 news:ad0rbq$88q$1 digitaldaemon.com...


 reflection?


 Only partially, via the .classinfo property.





 variable

 parameters using the params keyword like this:

 void Print(params string stuffToPrint[])
 {
     foreach(oneThing in stuffToPrint) System.Console.WriteLn(oneThing);
 }

 Then you would call it like this:

 Print("Printing ", "variable ", "parameters");


 D does variable parameter lists exactly like C does. While not typesafe,


it

 is efficient.
May 28 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Matthew Wilson" <mwilson nextgengaming.com> wrote in message
news:ad1mcg$2bir$1 digitaldaemon.com...


 Walter,




is

 good. Would the performance be prohibitive? Do you have any
 figures/impressions as to how much it would cost?


After all, both ways could be left, old C-style for printf (and whoever
cares of perfomance can always use it), and something new, safe and easy
to use.
May 28 2002
next sibling parent "Richard Krehbiel" <rich kastle.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad1qrq$2hau$1 digitaldaemon.com...

 "Matthew Wilson" <mwilson nextgengaming.com> wrote in message
 news:ad1mcg$2bir$1 digitaldaemon.com...


 Walter,


 is
 good. Would the performance be prohibitive? Do you have any
 figures/impressions as to how much it would cost?


 After all, both ways could be left, old C-style for printf (and whoever
 cares of perfomance can always use it), and something new, safe and easy
 to use.


...at which point, I have to mention my favorite design again.  :-)

    void takes_variable_args(int... args)
    {
    }

This function takes a variable number of arguments, all of type int.  The
variable "args" really has the type "int[] args" (just as, in C, a function
parameter declared with [] really has type "pointer to...").  The "..."
variation indicates that, when the caller codes separate function
parameters, they are collected for the user into a dynamic array.

    class ArgType
    {
        this(char[] var) { }
        this(int var) { }
    }

    void mixed_types(ArgType... args)
    {
    }

The arguments are collected into a dynamic array "ArgType[] args" where
ArgType is some user-defined class.  The arguments given must be of the
parameter type; else a derived type; else an instance of the parameter type
must be constructible using the given expression; else it's an error.

So when the user writes this:

    ArgType myVar;
    mixed_types(myVar, 1, "string");

...this would compile *as if* the user had coded:

    ArgType[] _temp_;
    _temp_.length = 3;
    _temp_[0] = myVar;
    _temp_[1] = new ArgType(1);
    _temp_[2] = new ArgType("string");
    mixed_types(_temp_);

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 comcast.net  (personal)
May 29 2002
prev sibling parent reply Patrick Down <pat codemoon.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in
news:ad1qrq$2hau$1 digitaldaemon.com: 


 "Matthew Wilson" <mwilson nextgengaming.com> wrote in message
 news:ad1mcg$2bir$1 digitaldaemon.com...
 

 Walter,


 implementation 


 is

 good. Would the performance be prohibitive? Do you have any
 figures/impressions as to how much it would cost?


 
 After all, both ways could be left, old C-style for printf (and
 whoever cares of perfomance can always use it), and something new,
 safe and easy to use.


extern(C) functions could use to old way.

There is already a typeInfo class for a lot of types.
Why not automatically push the number of parameters and
then push pairs of TypeInfo references and values?  It would
nice to have a replacement for the va* macros too.

void func(vararg,...)
{
  for(int i = 0; i < vararg.length; ++i)
  {
    TypeInfo t = vararg.GetType(i);
    void* pv = vararg.getValue(i);
    
  }
}
May 29 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Patrick Down" <pat codemoon.com> wrote in message
news:Xns921D6A359FF5Apatcodemooncom 63.105.9.61...


 After all, both ways could be left, old C-style for printf (and
 whoever cares of perfomance can always use it), and something new,
 safe and easy to use.


 extern(C) functions could use to old way.


I thought about this as well. It seems like the best approach.
"..." is already known to C/C++ programmers to indicate vararg
function, why break the tradition?
May 29 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <mwilson nextgengaming.com> wrote in message
news:ad1mcg$2bir$1 digitaldaemon.com...

 Walter,




is

 good. Would the performance be prohibitive? Do you have any
 figures/impressions as to how much it would cost?


The proper way to do it would be to create a variant type, and then have
variable parameter lists be passed as arrays of variants.
May 29 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ad3pg0$2hgm$1 digitaldaemon.com...


 The proper way to do it would be to create a variant type, and then have
 variable parameter lists be passed as arrays of variants.


So, what about variants?
May 29 2002
next sibling parent Patrick Down <pat codemoon.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in news:ad4d3a$83g$1
 digitaldaemon.com:


 "Walter" <walter digitalmars.com> wrote in message
 news:ad3pg0$2hgm$1 digitaldaemon.com...
 

 The proper way to do it would be to create a variant type, and then have
 variable parameter lists be passed as arrays of variants.


 
 So, what about variants?


I would vote for a basic variant type too.
May 29 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad4d3a$83g$1 digitaldaemon.com...

 "Walter" <walter digitalmars.com> wrote in message
 news:ad3pg0$2hgm$1 digitaldaemon.com...

 The proper way to do it would be to create a variant type, and then have
 variable parameter lists be passed as arrays of variants.


 So, what about variants?


They're a good idea, I just need to do more work on it.
Jun 11 2002
prev sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:ad3pg0$2hgm$1 digitaldaemon.com...

 "Matthew Wilson" <mwilson nextgengaming.com> wrote in message
 news:ad1mcg$2bir$1 digitaldaemon.com...

 Walter,




 is

 good. Would the performance be prohibitive? Do you have any
 figures/impressions as to how much it would cost?


 The proper way to do it would be to create a variant type, and then have
 variable parameter lists be passed as arrays of variants.


With the a basic variant type and the "array of variants" approach, every
type is always a valid parameter type.  Same with the C/C++ varargs
approach.

May I direct your attention?
news://news.digitalmars.com/ad2ead$a6i$1 digitaldaemon.com

With my approach the compiler will enforce legal argument types; but if you
want to code up a universal Variant class and use it, you may.

IMHO I'd rather avoid having "variant" be a basic type in the language.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 comcast.net  (personal)
May 30 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Richard Krehbiel" <rich kastle.com> wrote in message
news:ad53sp$1847$1 digitaldaemon.com...


 With the a basic variant type and the "array of variants" approach, every
 type is always a valid parameter type.  Same with the C/C++ varargs
 approach.


Yes, but it is typesafe, and simple to implement.
May 30 2002
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad5kht$1hlr$1 digitaldaemon.com...

 "Richard Krehbiel" <rich kastle.com> wrote in message
 news:ad53sp$1847$1 digitaldaemon.com...


 With the a basic variant type and the "array of variants" approach,




every

 type is always a valid parameter type.  Same with the C/C++ varargs
 approach.


 Yes, but it is typesafe, and simple to implement.


My version is "stronger" (it can enforce vararg parameter types at compile
time; the variant accepts every type) and I fail to see how injecting a
basic type as disruptive as "variant" would be simpler.

variant a, b, c;
a = b + c;

Integer, or floating point math?  Vector sum?  Can't tell.  The compiler
must generate code to sense types and perform every valid operation at run
time.  Or else, call it illegal to perform operatins on "variant," and rule
that they must be converted to real types before anything can be done with
them.

--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 comcast.net  (personal)
May 30 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Richard Krehbiel" <rich kastle.com> wrote in message
news:ad5sul$2q3r$1 digitaldaemon.com...


 My version is "stronger" (it can enforce vararg parameter types at compile
 time; the variant accepts every type) and I fail to see how injecting a
 basic type as disruptive as "variant" would be simpler.

 variant a, b, c;
 a = b + c;

 Integer, or floating point math?  Vector sum?  Can't tell.  The compiler


Forbid such things at all. Variants are not for math, they are to store
(and pass to functions) values of diffenrent types, varying at run-time.
Variant math should clearly be forbidden, and explicit cast required for
such cases:

    variant a, b, c;
    a = cast(int)b + cast(int)c;
May 31 2002
prev sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:


It should in theory be able to be as fast as C++.

Sean

"cblack01" <cblack01 cox.net> wrote in message
news:ad0rbq$88q$1 digitaldaemon.com...

 Hey,


 reflection?



variable

 parameters using the params keyword like this:

 void Print(params string stuffToPrint[])
 {
     foreach(oneThing in stuffToPrint) System.Console.WriteLn(oneThing);
 }

 Then you would call it like this:

 Print("Printing ", "variable ", "parameters");




never

 use it since I do a lot of scientific applications that are too



 Thanks,

 Craig
May 30 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ad5q85$2mv2$1 digitaldaemon.com...





AFAIK, there are three modes: JIT-compilation (default), complete
precompilation,
and straight interpretation.


 It should in theory be able to be as fast as C++.


As long as it uses COM, I doubt it will be as fast even when programs
are precompiled into native code.
May 31 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ad7b97$1sis$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ad5q85$2mv2$1 digitaldaemon.com...





 AFAIK, there are three modes: JIT-compilation (default), complete
 precompilation,
 and straight interpretation.


 It should in theory be able to be as fast as C++.




Mmmm....
Java also uses JIT compiling doesn't it?
It takes every lame little Java program an age to
start because of this....It is definitely not as
fast as native code!



 As long as it uses COM, I doubt it will be as fast even when programs
 are precompiled into native code.


COM is not slow. Even DirectX uses COM and they would never
do that if it really were slow. Ofcourse when you use COM
to build a remote component to be accessed over the internet
that's slow... :) But when you just use a .dll it is fast.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
Jun 03 2002
next sibling parent reply andy <acoliver apache.org> writes:
 
 COM is not slow. Even DirectX uses COM and they would never
 do that if it really were slow. Ofcourse when you use COM
 to build a remote component to be accessed over the internet
 that's slow... :) But when you just use a .dll it is fast.
 


And its deprecated.


 
 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
 _________________________________________________
 Remove _XYZ from my address when replying by mail
Jun 03 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"andy" <acoliver apache.org> wrote in message
news:3CFBCFB5.2070304 apache.org...

 COM is not slow. Even DirectX uses COM and they would never
 do that if it really were slow. Ofcourse when you use COM
 to build a remote component to be accessed over the internet
 that's slow... :) But when you just use a .dll it is fast.


 And its deprecated.



No it isn't, the whole .net framework is built on it's
foundations. That's just the usual 'Microsoft Marketing
Blabber' (tm). The are not about to deprecate the milions
of lines of code written with COM. Just think of your
excel sheet embedded in your Word document (OLE), all
the Windows Explorer extension, all the ActiveX controls,
allmost all the games written in the last few years,
etcetera, etcetera, etcetera. Ofcourse they do want you
to switch to .net, but that is another story.

--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
Jun 09 2002
parent reply andy <acoliver apache.org> writes:
 
 No it isn't, the whole .net framework is built on it's
 foundations. That's just the usual 'Microsoft Marketing
 Blabber' (tm). The are not about to deprecate the milions
 of lines of code written with COM. Just think of your
 excel sheet embedded in your Word document (OLE), all
 the Windows Explorer extension, all the ActiveX controls,
 allmost all the games written in the last few years,
 etcetera, etcetera, etcetera. Ofcourse they do want you
 to switch to .net, but that is another story.
 


You're right.  I was thinking of MFC.


 --
 Stijn
 OddesE_XYZ hotmail.com
 http://OddesE.cjb.net
 _________________________________________________
 Remove _XYZ from my address when replying by mail
Jun 09 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"andy" <acoliver apache.org> wrote in message
news:3D03D095.6090807 apache.org...

 No it isn't, the whole .net framework is built on it's
 foundations. That's just the usual 'Microsoft Marketing
 Blabber' (tm). The are not about to deprecate the milions
 of lines of code written with COM. Just think of your
 excel sheet embedded in your Word document (OLE), all
 the Windows Explorer extension, all the ActiveX controls,
 allmost all the games written in the last few years,
 etcetera, etcetera, etcetera. Ofcourse they do want you
 to switch to .net, but that is another story.


 You're right.  I was thinking of MFC.



And good riddance!   ;)


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
Jun 11 2002
prev sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:adgi89$276q$1 digitaldaemon.com...


 COM is not slow. Even DirectX uses COM and they would never
 do that if it really were slow. Ofcourse when you use COM
 to build a remote component to be accessed over the internet
 that's slow... :) But when you just use a .dll it is fast.


DX doesn't really uses COM to its fullest. It provides
functions to create DX objects fast, without using the
slow-as-hell COM/Automation mechanisms (CoCreateInstance
etc). It does not use dual interfaces, as far as I know.
It does not use SAFEARRAY and BSTR. Etc etc etc.

Just compare DX VB library (COM!) to DX C++ library (COM?),
and see the difference in speed...
Jun 04 2002
parent "OddesE" <OddesE_XYZ hotmail.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:adhor6$dqa$1 digitaldaemon.com...

 "OddesE" <OddesE_XYZ hotmail.com> wrote in message
 news:adgi89$276q$1 digitaldaemon.com...


 COM is not slow. Even DirectX uses COM and they would never
 do that if it really were slow. Ofcourse when you use COM
 to build a remote component to be accessed over the internet
 that's slow... :) But when you just use a .dll it is fast.


 DX doesn't really uses COM to its fullest. It provides
 functions to create DX objects fast, without using the
 slow-as-hell COM/Automation mechanisms (CoCreateInstance
 etc). It does not use dual interfaces, as far as I know.
 It does not use SAFEARRAY and BSTR. Etc etc etc.

 Just compare DX VB library (COM!) to DX C++ library (COM?),
 and see the difference in speed...


So just say "Automation is slow", not "COM is slow".
Automation is a superset of COM, it's like comparing
C++ to C, they are just not the same thing.
And I agree that automation is slow, but there are
benefits to compensate for this.
DirectX does use CoCreateInstance, it is just
wrapped in a more user-friendly call. However after
you have created the first object all others are
created through calls to this object.


--
Stijn
OddesE_XYZ hotmail.com
http://OddesE.cjb.net
_________________________________________________
Remove _XYZ from my address when replying by mail
Jun 09 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:ad5q85$2mv2$1 digitaldaemon.com...



 It should in theory be able to be as fast as C++.

 Sean


That was the theory with Java JITs, too, but the various semantics of the
language seem to have defeated that. For example, arrays are always objects
allocated on the heap, and they are always bounds checked. The translation
layer needed to interface with C doesn't help. The biggest slowdown is
probably the lack of lightweight objects. No support for byte chars hurts. I
could go on ... <g>.

Some experiments show that expert Java programmers can approach the speed of
C++, but it shouldn't be necessary to be in that top 1% to get fast code.

D has some features which will make it slower than C/C++, and some that will
make it faster. It's too soon to tell how on balance it will work out. The
neat thing about D is you should be able to get the reliability of Java with
the performance of C/C++.
Jun 11 2002
parent "Matthew Wilson" <dmd synesis.com.au> writes:
Guys

I wrote an article for CUJ, which Walter helped a little with, that is being
published in the September edition. It was entitled "A performance


are very good performers on the Win32 platform, and although one can get
C/C++ to outperform, it requires explicit coding to that end (which kind of
defeats the purpose, for most scenarios)

Walter, I haven't heard back from the publisher re my forwarding you a
pre-print, so assume I cannot. It'll be out in 8 weeks, though ... ;)


"Walter" <walter digitalmars.com> wrote in message
news:ae4ctn$1udb$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:ad5q85$2mv2$1 digitaldaemon.com...



 It should in theory be able to be as fast as C++.

 Sean


 That was the theory with Java JITs, too, but the various semantics of the
 language seem to have defeated that. For example, arrays are always


objects

 allocated on the heap, and they are always bounds checked. The translation
 layer needed to interface with C doesn't help. The biggest slowdown is
 probably the lack of lightweight objects. No support for byte chars hurts.


I

 could go on ... <g>.

 Some experiments show that expert Java programmers can approach the speed


of

 C++, but it shouldn't be necessary to be in that top 1% to get fast code.

 D has some features which will make it slower than C/C++, and some that


will

 make it faster. It's too soon to tell how on balance it will work out. The
 neat thing about D is you should be able to get the reliability of Java


with

 the performance of C/C++.
Jun 11 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:acurhn$foq$1 digitaldaemon.com...

 In debug build I got a "switch default" runtime error!
 Is this true, that you *must* provide a default case, and that a switch
 without a matching case is an error?


Correct.


  I dislike the idea of having to
 provide an explicit default which does nothing, but there may be other
 reasons for this (safety I guess)


The reason for it is all the bugs I've had over the years where I add
another value to something, and forget to add a case for it in a
corresponding switch somewhere in the code. It means one must be explicit
about ignoring the default case.


 Lotta little things to get used to in D.  ;)


Yup <g>. D doesn't have one killer feature, it is more the aggregate of a
lot of little things.
May 28 2002
parent "Matthew Wilson" <mwilson nextgengaming.com> writes:
Agree that this is a good policy. Now, if only we can get mandatory braces
... ;)

"Walter" <walter digitalmars.com> wrote in message
news:ad0tkb$as8$1 digitaldaemon.com...

 "Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
 news:acurhn$foq$1 digitaldaemon.com...

 In debug build I got a "switch default" runtime error!
 Is this true, that you *must* provide a default case, and that a switch
 without a matching case is an error?


 Correct.


  I dislike the idea of having to
 provide an explicit default which does nothing, but there may be other
 reasons for this (safety I guess)


 The reason for it is all the bugs I've had over the years where I add
 another value to something, and forget to add a case for it in a
 corresponding switch somewhere in the code. It means one must be explicit
 about ignoring the default case.


 Lotta little things to get used to in D.  ;)


 Yup <g>. D doesn't have one killer feature, it is more the aggregate of a
 lot of little things.
May 28 2002