D - D vs Other Languages

Alisdair Meredith (56/56) May 30 2003 I originally sent this to Walter privately, but he suggested I post here

Walter (20/68) May 30 2003 The idea is that one can do anything with an add-on library with enough

Luna Kid (6/12) May 30 2003 I may be wrong, but I'd say, libraries and standard libraries

Alisdair Meredith (20/24) May 30 2003 Especially when design goals of some languages (notably C++) are NOT to

DRS (7/13) May 30 2003 "Alisdair Meredith" wrote in messag...

Ilya Minkov (15/16) May 30 2003 How come? Object Pascal has "set", which is an efficient and good thing

Matthew Wilson (3/27) May 30 2003 Sure, this is a good point ...

Walter (11/21) May 30 2003 is

Georg Wrede (27/34) May 30 2003 ..

Alisdair Meredith (24/35) May 30 2003 The other question I ask of every advert is 'Do I trust it?'

Matthew Wilson (9/44) May 30 2003 Just because there are classes that support certain semantics, residing ...

Alisdair Meredith (20/27) May 30 2003 But namespaces can be reopened at any time, and pre-compiled libraries

Sebastian Moleski (6/16) May 30 2003 duplicates
Andy Friesen (61/119) May 30 2003 My pleasure. This comparison isn't as useful as others, though, since

Ilya Minkov (9/27) May 30 2003 Automated memory managemenr through refence counting. :)
C (45/45) Jun 01 2003 By the looks of your reply and those of others,

Georg Wrede (13/18) May 31 2003 The world is a kind of Yin-Yang thing. Two

C (15/17) Jun 02 2003 Ack, thats what you get for leaving the
Georg Wrede (5/23) Jun 03 2003 I've found out that not everybody recognized

Walter (12/38) May 31 2003 duplicates

Garen Parham (9/15) Jun 03 2003 I'd be in the "C++ doesn't have a module system" camp. One thing that m...

Walter (17/31) Jun 03 2003 duplicates

DRS (64/123) May 30 2003 "Alisdair Meredith" wrote in messag...

Sebastian Moleski (5/7) May 30 2003 That's a union in C.

DRS (10/15) May 30 2003 [...]

Walter (4/6) May 31 2003 constants

Ilya Minkov (11/13) May 31 2003 "Mutable constants"

Walter (3/15) May 31 2003 I wouldn't call that a feature of the Delphi language, then.

Alisdair Meredith (51/79) May 30 2003 Does this mean you can only overload operators for a small subset of

Sebastian Moleski (13/42) May 30 2003 Yes. If you want to read more about that, I would suggest you go to the

Alisdair Meredith (7/11) May 30 2003 Yes, but what about them?!

Sebastian Moleski (9/17) May 30 2003 If you have one common root in your inheritance tree, you can expect cer...
Ilya Minkov (5/10) May 30 2003 You can get TObject in a function, and dispatch dynamically based on

DRS (13/28) May 30 2003 [...]

Alisdair Meredith (5/7) May 30 2003 I remember using it in Delphi2, not sure about Delphi 1

William Meyer (5/6) Jun 01 2003 You're right -- it surfaced in D2.

Sebastian Moleski (6/8) Jun 01 2003 "William Meyer" wrote in message

Ignacio Vazquez (7/14) Jun 12 2003 seen.

Sebastian Moleski (8/19) May 30 2003 No. Read again. The OP was saying that Delphi has two ways to pass a val...

DRS (7/12) May 30 2003 "Sebastian Moleski" wrote in message

Sebastian Moleski (6/12) May 30 2003 5:35 AM? Hmm, I wonder where you are located now. It's 2:49 PM here at

DRS (7/13) May 30 2003 [...]

Sebastian Moleski (3/14) May 30 2003 Sweet dreams.

DRS (22/44) May 30 2003 I'm not necessarily competent to argue all the finer points of Delphi's

Alisdair Meredith (10/12) May 30 2003 Actually the last Delphi I used was V2

Ilya Minkov (61/109) May 30 2003 (YES!)

DRS (37/58) May 30 2003 So are sets.

Walter (8/16) May 31 2003 a

DRS (9/12) Jun 01 2003 "Walter" wrote in message

Sebastian Moleski (5/6) Jun 01 2003 ROFL

Sebastian Moleski (6/8) May 30 2003 Why not?
Ignacio Vazquez (8/19) Jun 11 2003 It can generate both C and C++ .obj files, as well as C DLLs/SOs.

Walter (4/6) Jun 11 2003 don't

Ignacio Vazquez (5/11) Jun 12 2003 Ah yes, figured it out.

Alisdair Meredith (10/14) Jun 12 2003 Records are not objects though, as they do not support member

DRS (9/14) Jun 12 2003 [...]

Alisdair Meredith (13/16) Jun 12 2003 I guess that's what I get for posting without checking against the

DRS (22/33) Jun 12 2003 What's wrong with the help files?

Ignacio Vazquez (9/17) Jun 12 2003 The thing about 'object' is that it's the same as 'class', the only

DRS (6/13) Jun 12 2003 No, objects. The "object" was deprecated in favour of "class".

Ilya Minkov (5/21) Jun 13 2003 Records *can* be considered "lightweight object". Look at the left part

DRS (10/13) Jun 14 2003 "Ilya Minkov" wrote in message

Andy Friesen (2/17) Jun 14 2003 Neither do C structs, but they obviously qualify.

DRS (6/23) Jun 14 2003 Why obviously?

Fabian Giesen (3/5) Jun 14 2003 Because C is listed as having "lightweight objects" in the

Alisdair Meredith (6/9) Jun 15 2003 I'll pur the counter-argument: This is another error in the table, like

DRS (8/14) Jun 15 2003 I'd agree. What is a "lightweight" object anyway? At the minimum an ob...

Sebastian Moleski (6/19) Jun 15 2003 object
Ilya Minkov (17/20) Jun 15 2003 Nope. I believe that you very often need a simple agregate, which has

DRS (6/12) Jun 16 2003 Whatever they are they're manifestly not objects.

Sean L. Palmer (14/26) Jun 18 2003 object!

Walter (8/10) May 31 2003 assert is a basic building block for design by contract, but design by

Alisdair Meredith (4/4) May 30 2003 Oh, and another language I know nothing about but may be part of the
Garen Parham (8/21) Jun 03 2003 Perhaps a poor choice of words, but unit testing is a native concept in ...

DRS (8/11) Jun 03 2003 "Garen Parham" wrote in message

Garen Parham (3/6) Jun 04 2003 Don't know, Walter? In any case I'm pretty sure Walter has said he want...

Alisdair Meredith (29/31) Jun 04 2003 Well, my languages were chosen for a reason

Garen Parham (7/34) Jun 04 2003 Yeah me too, but it's got a lower ceiling w.r.t. potential uses due to

Georg Wrede (5/9) Jun 05 2003 Maybe such a table should be on an unofficial site? I agree that

Helmut Leitner (11/22) Jun 05 2003 You can use

Georg Wrede (5/10) Jun 05 2003 For those interested and knowledgeable, I already filled in

Walter (4/14) Jun 05 2003 No problem, make your own version of the table, as long as it is identif...

Ilya Minkov (4/4) Jun 08 2003 I'm looking at the comparison on Helmut's WIKI:

Carlos Santander B. (12/12) Jun 08 2003 "Ilya Minkov" escribi� en el mensaje

Ilya Minkov (9/16) Jun 09 2003 "overload"? First time i hear. It's not in my Delphi 2.0 book.

DRS (13/16) Jun 09 2003 function Divide(X, Y: Real): Real; overload;

Ilya Minkov (5/7) Jun 09 2003 Yeah, yeah, i know already. It just wasn't yet there as i learned

DRS (7/13) Jun 09 2003 D8 will be out around the end of the year. You have a lot of catching u...

jerlyn camina (1/16) Sep 05 2005

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

I originally sent this to Walter privately, but he suggested I post here
so we can get more involved in any discussion <g>

Following up some recent debate in the Borland Delphi newsgroups about 
this page [http://www.digitalmars.com/d/index.html] I would like to
query a couple of items in the list.  (I expect you will get a message
or two with Delphi's capabilities shortly <g>) 

i/ Huge play is made on the versatility of array type, which seems
somewhat unfair to languages that explictly support the listed behaviour
in their STANDARD libraries that are expected as part of a conforming
implementation.

Specifically, C++ does not have 'resizable arrays' as a langauge
feature because they are in the standard library, std::vector.  There is
no likelihood any proposal to add such a feature to the language would
ever pass committee because it is already required to be present (in the
library) in any conforming C++ implementation.

While I can understand your desire to show your own product in the best
possible light, I would like to at least see a 3rd option between 'yes'
and 'no' for features implemented in the standard library of other
languages (rather than 3rd party libraries, no matter how common)

Suggest a 'LIB' cell coloured yellow.

[otherwise such clear bias on something I do know well will give me
doubts about other items I am less clear on, see below]


Under OOP you say C++ has module support.  News to me, this is one of
the most requested extensions to the library and I still don't know
anyone with a clear idea how to approach it!  I suggest you change this
to 'No'

Also, Covariant return types is duplicated in OOP and functions
sections, is that intentional?


Under reliablility I am very surprised that only 'D' rates as unit
testable.  I would at least like a link to some material explaining why
only 'D' qualifies here.  A good opportunity for a sales pitch if ever I
saw one, this is the detail that caught my attention most!!  [Although I
don't use Java, I was surprised that its extensive reflection API and
unit-testing community did not qualify]


Again, a footnote explaining why C++ does not support all 'C' types
would be useful.  Do you mean C99 here, or are there even more obvious
cases I am missing?


I would be happy to see 'struct member alignment control' dropped from
C++ (and presumably C) as this relies on common compiler extensions,
rather than true features of the language itself.  If we are going to
permit extensions, there are several popular C++ variants supporting
delegates, but I would not suggest you add that to the list either <g>
Rather, be stricter and say 'no' to struct layout control.


Last but not least, it would be really nice to turn the logic on the
Macro Preprocessor.  The presence of this mis-feature is the cause of
endless annoyance to C++, and its lack is certainly another score for
'D'.


Oh, and as a cheeky new feature you might want to add 'reference
implementation available' given that I am not yet aware of a conforming
C++ implementation [although EDG-based solutions are getting very close
now]


Interesting chart though.  If you can find the people to contribute I
would be interested in seeing how Eiffel, Python, Smalltalk and Haskell
score as well.

-- 
AlisdairM

May 30 2003

"Walter" <walter digitalmars.com> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED71CC3.F205F89F uk.renaultf1.com...
 i/ Huge play is made on the versatility of array type, which seems
 somewhat unfair to languages that explictly support the listed behaviour
 in their STANDARD libraries that are expected as part of a conforming
 implementation.
 Specifically, C++ does not have 'resizable arrays' as a langauge
 feature because they are in the standard library, std::vector.  There is
 no likelihood any proposal to add such a feature to the language would
 ever pass committee because it is already required to be present (in the
 library) in any conforming C++ implementation.

The idea is that one can do anything with an add-on library with enough
effort, so to compare the languages, library add-ons were excluded. Java
strings are explicitly handled by the compiler, as operations involving
string literals are translated by the compiler into calls to
Java.lang.string.


 While I can understand your desire to show your own product in the best
 possible light, I would like to at least see a 3rd option between 'yes'
 and 'no' for features implemented in the standard library of other
 languages (rather than 3rd party libraries, no matter how common)
 Suggest a 'LIB' cell coloured yellow.
 [otherwise such clear bias on something I do know well will give me
 doubts about other items I am less clear on, see below]

That's a good thought.

 Under OOP you say C++ has module support.  News to me, this is one of
 the most requested extensions to the library and I still don't know
 anyone with a clear idea how to approach it!  I suggest you change this
 to 'No'

The namespace feature of C++ coupled with separate compilation duplicates
enough of the features of modules I decided to give it the nod.

 Also, Covariant return types is duplicated in OOP and functions
 sections, is that intentional?

No, it's a bug.

 Under reliablility I am very surprised that only 'D' rates as unit
 testable.  I would at least like a link to some material explaining why
 only 'D' qualifies here.  A good opportunity for a sales pitch if ever I
 saw one, this is the detail that caught my attention most!!  [Although I
 don't use Java, I was surprised that its extensive reflection API and
 unit-testing community did not qualify]

It's done in Java with add-on libraries. It is not part of the language.

 Again, a footnote explaining why C++ does not support all 'C' types
 would be useful.  Do you mean C99 here, or are there even more obvious
 cases I am missing?

I mean C99 types.


 I would be happy to see 'struct member alignment control' dropped from
 C++ (and presumably C) as this relies on common compiler extensions,
 rather than true features of the language itself.  If we are going to
 permit extensions, there are several popular C++ variants supporting
 delegates, but I would not suggest you add that to the list either <g>
 Rather, be stricter and say 'no' to struct layout control.

You're right.

 Last but not least, it would be really nice to turn the logic on the
 Macro Preprocessor.  The presence of this mis-feature is the cause of
 endless annoyance to C++, and its lack is certainly another score for
 'D'.

It is a feature - there will always be some clever thing you can do with a
preprocessor that you can't do otherwise.

 Oh, and as a cheeky new feature you might want to add 'reference
 implementation available' given that I am not yet aware of a conforming
 C++ implementation [although EDG-based solutions are getting very close
 now]

DMD is not a perfect implementation of D, either <g>.


 Interesting chart though.  If you can find the people to contribute I
 would be interested in seeing how Eiffel, Python, Smalltalk and Haskell
 score as well.

My problem is I don't know those languages well enough to write a fair
comparison. Also, the chart is designed to compare D with the languages it
replaces as well as the pretenders to the throne as replacements <g>.

May 30 2003

"Luna Kid" <lunakid neuropolis.org> writes:

 feature because they are in the standard library, std::vector.  There is
 no likelihood any proposal to add such a feature to the language would
 ever pass committee because it is already required to be present (in the
 library) in any conforming C++ implementation.

 The idea is that one can do anything with an add-on library with enough
 effort, so to compare the languages, library add-ons were excluded. Java

I may be wrong, but I'd say, libraries and standard libraries
are fundamentally different things in this context. (And nowadays,
with extensible languages coming along, the language vs. stdlib
thing is going to be even less clear-cut.)

Cheers,
Sz.

May 30 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Luna Kid wrote:

 I may be wrong, but I'd say, libraries and standard libraries
 are fundamentally different things in this context. (And nowadays,
 with extensible languages coming along, the language vs. stdlib
 thing is going to be even less clear-cut.)

Especially when design goals of some languages (notably C++) are NOT to
provide features in the syntax if they can be provided by a library, but
to instead make sure said library is part of the standard.  C++ does
have associative containers and dynamic arrays 'out-the-box', but they
will never be native syntax.  I think it would do no harm for the chart
to reflect this.

The langauge/library barrier is even more blurred as you get to some
low-level library classes.  Most exception-supporting languages require
certain library execptions to be thrown when language-construct fail (in
C++, bad_alloc, bad_typeid, bad_dog...)  Java would be lost without the
Object class, etc.  This blurring is a deliberate policy of the language
designers.

As to which libraries to include?  In C/C++ it appears simple as there
is a clear ISO standard.  Where do you draw the line with Java packages

be considered, but we need to be clear which libraries are indeed
'standard' for each language.

-- 
AlisdairM

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
3ED79A33.AAF47CD1 uk.renaultf1.com

[...]

 Especially when design goals of some languages (notably C++) are NOT to
 provide features in the syntax if they can be provided by a library, but
 to instead make sure said library is part of the standard.  C++ does
 have associative containers and dynamic arrays 'out-the-box', but they
 will never be native syntax.  I think it would do no harm for the chart
 to reflect this.

By that criteria Object Pascal would probably get a few extra ticks.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

Ilya Minkov <midiclub 8ung.at> writes:

DRS wrote:

--- 8< ---(...out-of-the-box...)--- >8 ---

 By that criteria Object Pascal would probably get a few extra ticks.

How come? Object Pascal has "set", which is an efficient and good thing 
combined with enumerations, but too weak to be a general container. 
Dynamic array support has only appeared since Delphi 4.0 and is fairly 
weak, i.e. no multidimensional arrays. Strings were a strong point till 
short ago, but how when all flavors of unicode rule the world, it seems 
more appropriate if it were possible to subclass strings.

BTW, other more-or-less interesting but still comparable languages are 
GNU Pascal and GNU Sather. I shall contribute to the comparison with 
these languages.

-i.

--
(all the world are belong to us!)
- new media cyclops fighting against space invaders.

May 30 2003

"Matthew Wilson" <matthew stlsoft.org> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED79A33.AAF47CD1 uk.renaultf1.com...
 Luna Kid wrote:

 I may be wrong, but I'd say, libraries and standard libraries
 are fundamentally different things in this context. (And nowadays,
 with extensible languages coming along, the language vs. stdlib
 thing is going to be even less clear-cut.)

 Especially when design goals of some languages (notably C++) are NOT to
 provide features in the syntax if they can be provided by a library, but
 to instead make sure said library is part of the standard.  C++ does
 have associative containers and dynamic arrays 'out-the-box', but they
 will never be native syntax.  I think it would do no harm for the chart
 to reflect this.

Sure, this is a good point ...

 The langauge/library barrier is even more blurred as you get to some
 low-level library classes.  Most exception-supporting languages require
 certain library execptions to be thrown when language-construct fail (in
 C++, bad_alloc, bad_typeid, bad_dog...)  Java would be lost without the
 Object class, etc.  This blurring is a deliberate policy of the language
 designers.

 As to which libraries to include?  In C/C++ it appears simple as there
 is a clear ISO standard.  Where do you draw the line with Java packages

 be considered, but we need to be clear which libraries are indeed
 'standard' for each language.

 --
 AlisdairM

May 30 2003

"Walter" <walter digitalmars.com> writes:

"Luna Kid" <lunakid neuropolis.org> wrote in message
news:bb83p8$21ch$1 digitaldaemon.com...
 feature because they are in the standard library, std::vector.  There



is
 no likelihood any proposal to add such a feature to the language would
 ever pass committee because it is already required to be present (in



the
 library) in any conforming C++ implementation.

 The idea is that one can do anything with an add-on library with enough
 effort, so to compare the languages, library add-ons were excluded. Java

 I may be wrong, but I'd say, libraries and standard libraries
 are fundamentally different things in this context. (And nowadays,
 with extensible languages coming along, the language vs. stdlib
 thing is going to be even less clear-cut.)

Sure. There are a lot of different ways to look at the issue. I personally
look at something in the compiler vs something in the library as
fundamentally different. Perhaps because I'm a compiler writer <g>.

Even with language features, there is plenty of room for argument. For
example, I've gotten a lot of email arguing that C++ does not have modules.
I view C++ namespaces combined with separate compilation as addressing that
issue (however badly), hence I gave it a 'yes' for modules.

May 30 2003

Georg Wrede <Georg_member pathlink.com> writes:

(sorry if this is a repost...)

In article <bb85of$24d9$1 digitaldaemon.com>, Walter says...
Even with language features, there is plenty of room for argument. For
example, I've gotten a lot of email arguing that C++ does not have modules.
I view C++ namespaces combined with separate compilation as addressing that
issue (however badly), hence I gave it a 'yes' for modules.

..

Sure. There are a lot of different ways to look at the issue. I personally
look at something in the compiler vs something in the library as
fundamentally different. Perhaps because I'm a compiler writer <g>.

There are indeed. But then we should decide on the viewpoint in the 
comparison list. It probably started as Walter's private note, then
gradually got to where it is now. But today, is it for compiler 
writers, D users, potential D converts, an academic comparison,
or advertising?

Its position on the web pages entertains the notion of advertising.
Which is OK, those pages are _supposed_ to advertise. In that case
maybe the point of view shoud be that of a prospective customer.

What counts for the customer is 
- is this genuinely in it? (I get it automatically)
- does this come with it? (I have to write extra words to get it)
- is this a 3rd party thing? (see below)

In the customer's mind the last one reads "heck, so I have to shop
all over the Internet to gather bits and pieces before I can do
non trivial programming. And probably those bits and pieces don't
even work well together, so it's bound to be a mess.

So, IMHO, that list being there, the issue is not whether something
is "built-in" or "library" or "looks built-in but still library"
(like some Java string stuff mentioned in this thread).

The issue is what's the effort. An example:

You can do module stuff in C++, like Walter said. But, hey, with
the same amount of work you can do OO in plain C. (Really?
Yes, I talked with this guy who's written programs for the Mars
Pathfinder rovers. They did it in OO plain C.)

May 30 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Georg Wrede wrote:

 Its position on the web pages entertains the notion of advertising.
 Which is OK, those pages are _supposed_ to advertise. In that case
 maybe the point of view shoud be that of a prospective customer.

 What counts for the customer is 
 - is this genuinely in it? (I get it automatically)
 - does this come with it? (I have to write extra words to get it)
 - is this a 3rd party thing? (see below)

The other question I ask of every advert is 'Do I trust it?'
In order to evaluate this table, I compare the column I know well with
my own knowledge.  I look at the dynamic array row and say to myself
'heck, this is the C++ standard, a required part of any conforming C++
distribution, but this table flat out says it is not supported'  I think
about it, and see where Walter is coming from, but it means I am looking
for a twist on every entry.

OTOH, to simply say 'Yes C++ has dynamic arrays' clearly does
dis-service to the D array.  No point in having advertising if it
doesn't push your product <g>

I think a standard library type option would solve a lot of the 'niggly'
issues, and make it easier to take the table at face value.

 You can do module stuff in C++, like Walter said. But, hey, with
 the same amount of work you can do OO in plain C. (Really?
 Yes, I talked with this guy who's written programs for the Mars
 Pathfinder rovers. They did it in OO plain C.)

IIRC, it was a big thing at MS that COM programming should be possible
in C, and many of the early COM texts came with decent examples of how
you could create a vtable using structs of function pointers.  Done this
way, OO in C can be as dynamic as Python, where you can override a
method for a single instance of a class if you choose <g>

I think the comparison to modules in C++ is good too, as it certainly
requires the same level of discipline and convention to turn the
available language features into something non-C++ fans might recongise
as a module system.

-- 
AlisdairM

May 30 2003

"Matthew Wilson" <matthew stlsoft.org> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED7B457.9AC9B9A9 uk.renaultf1.com...
 Georg Wrede wrote:

 Its position on the web pages entertains the notion of advertising.
 Which is OK, those pages are _supposed_ to advertise. In that case
 maybe the point of view shoud be that of a prospective customer.

 What counts for the customer is
 - is this genuinely in it? (I get it automatically)
 - does this come with it? (I have to write extra words to get it)
 - is this a 3rd party thing? (see below)

 The other question I ask of every advert is 'Do I trust it?'
 In order to evaluate this table, I compare the column I know well with
 my own knowledge.  I look at the dynamic array row and say to myself
 'heck, this is the C++ standard, a required part of any conforming C++
 distribution, but this table flat out says it is not supported'  I think
 about it, and see where Walter is coming from, but it means I am looking
 for a twist on every entry.

Just because there are classes that support certain semantics, residing in
standard libraries, does not mean that the language supports the feature

albeit that most have common/standard library features that do so.

I think Walter is quite correct here.

 OTOH, to simply say 'Yes C++ has dynamic arrays' clearly does
 dis-service to the D array.  No point in having advertising if it
 doesn't push your product <g>

 I think a standard library type option would solve a lot of the 'niggly'
 issues, and make it easier to take the table at face value.

 You can do module stuff in C++, like Walter said. But, hey, with
 the same amount of work you can do OO in plain C. (Really?
 Yes, I talked with this guy who's written programs for the Mars
 Pathfinder rovers. They did it in OO plain C.)

 IIRC, it was a big thing at MS that COM programming should be possible
 in C, and many of the early COM texts came with decent examples of how
 you could create a vtable using structs of function pointers.  Done this
 way, OO in C can be as dynamic as Python, where you can override a
 method for a single instance of a class if you choose <g>

Some of use still do the occasional bit of COM in C, for the reasons you
cite. :)

 I think the comparison to modules in C++ is good too, as it certainly
 requires the same level of discipline and convention to turn the
 available language features into something non-C++ fans might recongise
 as a module system.

 --
 AlisdairM

May 30 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Walter wrote:

 The namespace feature of C++ coupled with separate compilation duplicates
 enough of the features of modules I decided to give it the nod.

But namespaces can be reopened at any time, and pre-compiled libraries
are very fragile in the face of the preprocessor.  Header files are
continually reparsed.  I am a bona-fide member of the C++ fan club, but
feel more than uncomfortable saying C++ has 'units'.

I guess that if 'D' relies on the same justification, I want to drop
units for 'D' as well.  I'm hoping you can find a neater solution
though, that would really give D a push!!

 It is a feature - there will always be some clever thing you can do with a
 preprocessor that you can't do otherwise.

Yes, but I'm still prejudiced <g>
[Boost actually have quite a powerful pre-processor library that can do
some amazing things, including confusing the heck out of me!  PP
programming is a black art, and even with Boost it remains a murky
grey...]


 My problem is I don't know those languages well enough to write a fair
 comparison. Also, the chart is designed to compare D with the languages it
 replaces as well as the pretenders to the throne as replacements <g>.

Fair enough, but would be quite nice to have a parallel table covering
the less C-like languages if we can find contributors.  I expect you
will be hearing from some vocal Delphi supporters shortly <g>  It would
be nice to track down a Python guy too, as that is next langauge on my
list-to-learn <gg>

-- 
AlisdairM

May 30 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED79C54.380633B uk.renaultf1.com...
 Walter wrote:

 The namespace feature of C++ coupled with separate compilation


duplicates
 enough of the features of modules I decided to give it the nod.

 But namespaces can be reopened at any time, and pre-compiled libraries
 are very fragile in the face of the preprocessor.  Header files are
 continually reparsed.  I am a bona-fide member of the C++ fan club, but
 feel more than uncomfortable saying C++ has 'units'.

 I guess that if 'D' relies on the same justification, I want to drop
 units for 'D' as well.  I'm hoping you can find a neater solution
 though, that would really give D a push!!


assemblies.

sm

May 30 2003

Andy Friesen <andy ikagames.com> writes:

Alisdair Meredith wrote:
 [...] It would
 be nice to track down a Python guy too, as that is next langauge on my
 list-to-learn <gg>

My pleasure.  This comparison isn't as useful as others, though, since 
Python doesn't do a very good job as a systems language. ;)

Garbage Collection

Yup.

 Function overloading


Nope.

 Function delegates


Yes.

 Out function parameters


No.

 Nested functions


Yes.

 Function literals


Yes. (lambda)

 Dynamic closures


Yes.

 Covariant return types


Python is dynamically typed, so I suppose so. :)

 Lightweight arrays


No?

 Resizeable arrays


Yes.

 Arrays of bits


No.

 Built-in strings
 Array slicing
 Array bounds checking


Yes.

 Associative arrays


Yes.

 Strong typedefs


No. (doesn't make sense)

 String switches


No switch at all.

 Aliases


I guess so.  Classes are objects, so you can just create another 
reference to the class.

ie.   MyAlias = TheClass

 Object Oriented


Yes.

 Multiple Inheritance


Yes.

 Interfaces


Not explicitly so.  Python looks for methods by name.  If your 
"interface" has a method called doThis, then any object with a doThis 
will do.  So... yes?

 Operator overloading


Yes.

 Modules


Yes.

 Dynamic class loading


Yes. (all class loading is dynamic, technically)

 Inner classes


I don't think so.

 Performance
 Inline assembler
 Direct access to hardware


No.

 Lightweight objects


No.

 Explicit memory allocation control
 Independent of VM
 Direct native code gen


No.

 Templates


Not applicable.  They're not there, but they have no use in a 
dynamically typed language, since any variable can reference anything 
anyway.

 Design by Contract


Through assert statements, yes.

 Unit testing


No.

 Static construction order


Yes.  Things are constructed the first time the module is imported.

 Guaranteed initialization


Yes.

 RAII


Yes.  Python currently uses reference counting to garbage collect, so 
object destruction is deterministic.

 Exception handling
 try-catch-finally blocks


Yes.

 Thread synchronization primitives


No.  The library has a lock object, though.

 Algol-style syntax
 Enumerated types
 Support all C types
 Long double floating point


No.

 Complex and Imaginary


Yes.

 Direct access to C
 Use existing debuggers
 Struct member alignment control
 Generates standard object files


No.

 Macro preprocessor


No.

 Other
 Conditional compilation


No. (not compiled)

 And what are other stuff that you can add to this list that is found 


in OP^H^HPython and
 not in D?


Variants.
Lexical closures.
Argument defaults.
Keyword arguments.
Variable argument lists.
Metaclasses. (classes whose instances are actually classes themselves. 
Amounts to creating object types on the fly)
Multiple assignment. (you can swap two variables with "x,y = y,x")
List/dictionary (associative array) literals.
Portability.
Embeddability. (unfair, because D isn't meant to be used that way)

May 30 2003

Ilya Minkov <midiclub 8ung.at> writes:

Comments follow.

Andy Friesen wrote:
 Alisdair Meredith wrote:

 [...] It would
 be nice to track down a Python guy too, as that is next langauge on my
 list-to-learn <gg>

 My pleasure.  This comparison isn't as useful as others, though, since 
 Python doesn't do a very good job as a systems language. ;)

  >Garbage Collection
 Yup.

Automated memory managemenr through refence counting. :)

  >> Lightweight arrays
 No?

Standard library defines c-arrays, but i believe that's not what is 
meant. Walter, did you mean statically sized arrays or something else?

  >> Interfaces
 Not explicitly so.  Python looks for methods by name.  If your 
 "interface" has a method called doThis, then any object with a doThis 
 will do.  So... yes?

Multiple inheritance makes interfaces irrelevant, since they are a 
backdoor to make an object have multiple parents in a single-inheritance 
typesystem.

-i.

May 30 2003

C <cc.news gateway.mirlex.com> writes:

By the looks of your reply and those of others,
we need three extra catorgries in the comparason
table in addition to the ones already suppiled.

Yes	- Full support of said feature.

No	- No support or no direct language
	support - support added by other
	means should either result in one
	of the following options

LIB	- Supported by the standard library -
	which must be defined along with the
	semantic standard (eg. STL dynamic
	arrays in C++) - support supplied
	by third party libraries should
	result in a No.

N/A	- Not applicable - this feature would
	be useless in light of another feature
	(eg. Templates are normally useless with
	dynamic typing or generic programming)

Part	- Partial support - some aspects of
	this feature are available but not
	everything (eg. asserts vs. full
	design by contract) - to many
	languages supplying partial support
	would indicate the feature needs to
	be split into subfeatures - as is
	probably the case with DBC vs asserts

Specifying such options would result in a
more fair comparason which would not detract
from the appeal of D - such fairness may
even enhance said appeal, with people being
less suspicious of such advertising.

However, due to the more complex nature of
the resulting table a definition of these
terms would be required, one similar to
the aforementioned proposal should suffice.

(Oh, and a note to email you, or post to
this group correcting any errors in the
comparason would also help - it such a
request has not been made explicit elsewhere.

C 2003/5/31

'I see in the near future a crisis approaching
that unnerves me and causes me to tremble for
the safety of my country ... corporations have
been enthroned and an era of corruption in
high places will follow.' -- Abraham Lincoln

Jun 01 2003

Georg Wrede <Georg_member pathlink.com> writes:

'I see in the near future a crisis approaching
that unnerves me and causes me to tremble for
the safety of my country ... corporations have
been enthroned and an era of corruption in
high places will follow.' -- Abraham Lincoln

The world is a kind of Yin-Yang thing. Two
powers struggling eternally. In times of war
or need, the able see to our needs, and their
offspring prevail. In times of stagnation and
safety it is the socially adept who prevail.
That leads to nepotism and corruption. A time
of democracy is only to be found fleetly at the 
transition from the ables' time to the socially
adepts' time. 

What Today is, is for you to ponder.

-- Georg Wrede

(Sorry, I couldn't resist! The above is donated
to Public Domain: all I ask is to be credited.)

May 31 2003

C <cc.news gateway.mirlex.com> writes:

Georg Wrede wrote:

 (Sorry, I couldn't resist! The above is donated
 to Public Domain: all I ask is to be credited.)

Ack, thats what you get for leaving the
random signature file option on the favourate
quotes section :-) Always detracts from the
issues discussed.

I, however, would like to discuss your comments
further; but to reply here would be far too
offtopic. Could you send your email address to
cc *at* gateway.mirlex.com as your supplied
address is not working (550 / user not found)

C 2003/6/1

(Please ignore the quote behind the curtain).

"Emancipate yourself from mental slavery,
  None but ourselves can free our minds ..."
	-- Bob Marley (Redemption Song)

Jun 02 2003

Georg Wrede <Georg_member pathlink.com> writes:

In article <bbbat8$2ot3$1 digitaldaemon.com>, Georg Wrede says...
'I see in the near future a crisis approaching
that unnerves me and causes me to tremble for
the safety of my country ... corporations have
been enthroned and an era of corruption in
high places will follow.' -- Abraham Lincoln

The world is a kind of Yin-Yang thing. Two
powers struggling eternally. In times of war
or need, the able see to our needs, and their
offspring prevail. In times of stagnation and
safety it is the socially adept who prevail.
That leads to nepotism and corruption. A time
of democracy is only to be found fleetly at the 
transition from the ables' time to the socially
adepts' time. 

What Today is, is for you to ponder.

I've found out that not everybody recognized
this as a travesty of Fortune quotes. 

-- Georg Wrede

(Sorry, I couldn't resist! The above is donated
to Public Domain: all I ask is to be credited.)

Not even this rang a bell with some.

Ah, well, what can you do.

Jun 03 2003

"Walter" <walter digitalmars.com> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED79C54.380633B uk.renaultf1.com...
 Walter wrote:
 The namespace feature of C++ coupled with separate compilation


duplicates
 enough of the features of modules I decided to give it the nod.

 But namespaces can be reopened at any time, and pre-compiled libraries
 are very fragile in the face of the preprocessor.  Header files are
 continually reparsed.

You're right. But namespaces do provide the biggest feature of modules.


 I am a bona-fide member of the C++ fan club, but
 feel more than uncomfortable saying C++ has 'units'.
 I guess that if 'D' relies on the same justification, I want to drop
 units for 'D' as well.  I'm hoping you can find a neater solution
 though, that would really give D a push!!

I'm not sure what you mean by 'units' in D.


 It is a feature - there will always be some clever thing you can do with


a
 preprocessor that you can't do otherwise.

 Yes, but I'm still prejudiced <g>
 [Boost actually have quite a powerful pre-processor library that can do
 some amazing things, including confusing the heck out of me!  PP
 programming is a black art, and even with Boost it remains a murky
 grey...]

The C preprocessor is a difficult thing to understand when you get into the
details of nested macros and their arguments. I suspect most people just
flail away at it until it produces what they want, and never dare change it
<g>.


 My problem is I don't know those languages well enough to write a fair
 comparison. Also, the chart is designed to compare D with the languages


it
 replaces as well as the pretenders to the throne as replacements <g>.

 Fair enough, but would be quite nice to have a parallel table covering
 the less C-like languages if we can find contributors.  I expect you
 will be hearing from some vocal Delphi supporters shortly <g>  It would
 be nice to track down a Python guy too, as that is next langauge on my
 list-to-learn <gg>

I know next to nothing about Delphi, other than it being in the Pascal camp.

May 31 2003

Garen Parham <nospam garen.net> writes:

Walter wrote:

...
 
 The namespace feature of C++ coupled with separate compilation duplicates
 enough of the features of modules I decided to give it the nod.

I'd be in the "C++ doesn't have a module system" camp.  One thing that might
be interesting to point out is that there's a proposal that aims to add a
module system to C++ (can't find the URL atm, but its from ...Pete(r?) Becker).
Within the C++ community it's also thought that C++ doesn't have a module
system - though the std goes to some effort not to exclude it as a future
possibility AFAICT.

 My problem is I don't know those languages well enough to write a fair
 comparison. Also, the chart is designed to compare D with the languages it
 replaces as well as the pretenders to the throne as replacements <g>.

Care to elaborate on the pretenders? :)

Jun 03 2003

"Walter" <walter digitalmars.com> writes:

"Garen Parham" <nospam garen.net> wrote in message
news:bbij5j$190e$1 digitaldaemon.com...
 Walter wrote:
 The namespace feature of C++ coupled with separate compilation


duplicates
 enough of the features of modules I decided to give it the nod.

 I'd be in the "C++ doesn't have a module system" camp.  One thing that

might
 be interesting to point out is that there's a proposal that aims to add a
 module system to C++ (can't find the URL atm, but its from ...Pete(r?)

Becker).
 Within the C++ community it's also thought that C++ doesn't have a module
 system -

Well, I have to have something controversial in there <g>. I freely concede
that the chart reflects my professional opinion.

 though the std goes to some effort not to exclude it as a future
 possibility AFAICT.

The C++ standards group missed a golden opportunity to add modules by
instead of introducing:

    #include <cstdio>

they should have introduced:

    import stdio;

and explicitly stated it was a symbolic include rather than a textual one.
But at this point, I don't see that there's much profit in layering still
more stuff on top of C++. Time to reengineer the language - D!

 My problem is I don't know those languages well enough to write a fair
 comparison. Also, the chart is designed to compare D with the languages


it
 replaces as well as the pretenders to the throne as replacements <g>.

 Care to elaborate on the pretenders? :)

Jun 03 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
3ED71CC3.F205F89F uk.renaultf1.com

[...]

 Following up some recent debate in the Borland Delphi newsgroups about
 this page [http://www.digitalmars.com/d/index.html] I would like to
 query a couple of items in the list.  (I expect you will get a message
 or two with Delphi's capabilities shortly <g>)

Note: Delphi in Borland's parlance means both the language and the package
which includes the compiler, RAD IDE, standard libraries (VCL for Win32, CLX
for cross-platform), and sundry other bits.  For that reason I shall refer
to the language by the older name of Object Pascal.

As best I can make out, this is the current consensus over at
borland.public.delphi.non-technical:

 Garbage Collection

No (and we like it that way!).

 Function delegates
 Function overloading
 Out function parameters
 Nested functions

Yes

 Function literals

No.

 Dynamic closures

No?

 Covariant return types

No.

 Lightweight arrays
 Resizeable arrays

Yes.

 Arrays of bits

No.

 Built-in strings
 Array slicing
 Array bounds checking

Yes.

 Associative arrays

No.

 Strong typedefs

Yes.

 String switches

No.

 Aliases
 Object Oriented

Yes.

 Multiple Inheritance

No.

 Interfaces

Yes.

 Operator overloading

Yes (custom variants).

 Modules

Yes.

 Dynamic class loading

Yes (via RegisterClass).

 Inner classes

No.

 Performance
 Inline assembler
 Direct access to hardware

Yes.

 Lightweight objects

Yes (deprecated).

 Explicit memory allocation control
 Independent of VM
 Direct native code gen

Yes.

 Templates

No.

 Design by Contract

Yes (assert).

 Unit testing

No.

 Static construction order

Yes (modules only).

 Guaranteed initialization

Yes (consts only).

 RAII

No.

 Exception handling
 try-catch-finally blocks

Yes.

 Thread synchronization primitives

No?

 Algol-style syntax
 Enumerated types
 Support all C types
 Long double floating point

Yes.

 Complex and Imaginary

No.

 Direct access to C
 Use existing debuggers
 Struct member alignment control
 Generates standard object files

Yes.

 Macro preprocessor

No.

 Other
 Conditional compilation

Yes.

 And what are other stuff that you can add to this list that is found in OP

and
 not in D?

Set types
Variant records
True constants
Default parameters
Open array parameters
Reintroduce
Dynamic
Return value as variable vs. return
Run-Time Type Information (RTTI) operators
Ur-types
Packages

This stuff you probably wouldn't accept without referring to libraries, but
Delphi was practically designed around them:

Native UI librar(y/ies)
Interactive UI design
Native DB librar(y/ies)

We're still arguing about some of the definitions. :-)

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb85ot$24dv$1 digitaldaemon.com...
 Variant records

That's a union in C.

 True constants

I didn't understand then nor do I understand what you are referring to here.

sm

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Sebastian Moleski" <s.moleski tcu.edu> wrote in message
bb8686$254h$1 digitaldaemon.com
 "DRS" <drs removethis.ihug.com.au> wrote in message
 news:bb85ot$24dv$1 digitaldaemon.com...

[...]

 True constants

 I didn't understand then nor do I understand what you are referring to
 here.

I think Ignacio might have been trying to distinguish between true constants
and OP's variable constants.  :-)
Perhaps you should ask him, I just tried to make sense out of all the stuff
in the thread.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

"Walter" <walter digitalmars.com> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb86gp$25d2$1 digitaldaemon.com...
 I think Ignacio might have been trying to distinguish between true

constants
 and OP's variable constants.  :-)

variable constants? Dare I ask? <g>

May 31 2003

Ilya Minkov <midiclub 8ung.at> writes:

Walter wrote:
and OP's variable constants.  :-)

 variable constants? Dare I ask? <g>

"Mutable constants"

Turbo Pascal could not draw any wisdom of constants being constant. They 
were just global variables, assignable, with a slight difference that 
they could be used in any context, where constants could. For example, 
as array boundaries. Dynamite. :>

Since Delphi 1.0, the const-ness of constants is enforced in a strong 
manner by a compiler, exactly like in D, they are even inlined. But for 
compatibility reasons, there is a switch which allows for the Turbo 
pascal treatment of constants.

-i.

May 31 2003

"Walter" <walter digitalmars.com> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bbakhk$1veg$1 digitaldaemon.com...
 Walter wrote:
and OP's variable constants.  :-)

 variable constants? Dare I ask? <g>

 "Mutable constants"

 Turbo Pascal could not draw any wisdom of constants being constant. They
 were just global variables, assignable, with a slight difference that
 they could be used in any context, where constants could. For example,
 as array boundaries. Dynamite. :>

 Since Delphi 1.0, the const-ness of constants is enforced in a strong
 manner by a compiler, exactly like in D, they are even inlined. But for
 compatibility reasons, there is a switch which allows for the Turbo
 pascal treatment of constants.

I wouldn't call that a feature of the Delphi language, then.

May 31 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

DRS wrote:

 Operator overloading

 Yes (custom variants).

Does this mean you can only overload operators for a small subset of
classes (i.e. only through Variants) 
I'm not convinced Delphi support is complete enough to claim this, but
am ready to be proven wrong (the last version of Delphi I used predated
this support)


 Design by Contract

 Yes (assert).

Many languages on the table support asserts <g>  I don't think this
qualifies as DBC.

 Static construction order

 Yes (modules only).

 Guaranteed initialization

 Yes (consts only).

Erm, doesn't 'XXX only' mean that initialization is NOT guaranteed then?
<g>

 RAII

 No.

And I still maintain Delphi supports this, but it isn't practiced!!
It is a side effect of the Delphi interface mechanism.  All RAII needs
is a guaranteed function call when something leaves scope, and the
ability to provide your own cleanup in that function call.


 Support all C types

 Yes

I think this is intended for C99 support, and I doubt anything but C99
will ever support the full range!
[Correction, I just checked the chart and D has them!]

 And what are other stuff that you can add to this list that is found 
 in OP and not in D?


To take highlights from the list...

 Set types

Good choice for the chart to contrast the D array support.

 Variant records



 True constants

Erm, I think Delphi was last language to get these!
'fake-constants' might be more the language feature <g> but I'd simply
drop this

 Default parameters



 Open array parameters

Is a Delphi Open Array a langauge level tuple?

 Reintroduce

Not sure about this one, but the override keyword would be my other big
plus for Delphi syntax.

 Dynamic

Just another kind of virtual dispatch, already covered

 Return value as variable vs. return

Now this one is interesting, if badly phrased!

[For those that don't know Delphi]
Delphi, as a language level feature, allows you to assume a variable
called 'result' in every function.  You can simply assign to result
through the function call and this value will automatically be returned
as the function exits.  After you have assigned the value, you can (of
course) query and use result just like any other local variable.

Alternatively, you can return a value at any point with a return
statement, just as in the other languages.

 Run-Time Type Information (RTTI) operators

How does this differ from RTTI support in other languages?
C++ has dynamic_cast, Java does similar with its casting.  [Not sure how


 Ur-types

Is this just another way of saying 'reflection API'?


 Packages

As opposed to modules?
[I think Units and Packages are simply different kinds of modules]


 This stuff you probably wouldn't accept without referring to libraries, but
 Delphi was practically designed around them:

 Interactive UI design

I think this is as core to Delphi as Design-by-contract is to D, so it
would be nice to sneak it in somehow <g>
Besides, it at least requires linker-level support (if not language) to
support the .dfm format (a text file associated with the
gui-integration)

-- 
AlisdairM

May 30 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED7A688.15D9FD43 uk.renaultf1.com...
 DRS wrote:

 Operator overloading

 Yes (custom variants).

 Does this mean you can only overload operators for a small subset of
 classes (i.e. only through Variants)
 I'm not convinced Delphi support is complete enough to claim this, but
 am ready to be proven wrong (the last version of Delphi I used predated
 this support)

Yes. If you want to read more about that, I would suggest you go to the
Borland documentation page and download the D6 help files. It has all the
information in it.

 Default parameters



They could probably add this. The lack of default parameters is a rather
annoying misfeature in both .NET and Java.

 Open array parameters

 Is a Delphi Open Array a langauge level tuple?

In limited ways. If the language added support to store it in variables, it
would be.

 Return value as variable vs. return

 Now this one is interesting, if badly phrased!

 [For those that don't know Delphi]
 Delphi, as a language level feature, allows you to assume a variable
 called 'result' in every function.  You can simply assign to result
 through the function call and this value will automatically be returned
 as the function exits.  After you have assigned the value, you can (of
 course) query and use result just like any other local variable.

 Alternatively, you can return a value at any point with a return
 statement, just as in the other languages.

Return statement? Since when does Delphi have that?

 Run-Time Type Information (RTTI) operators

 How does this differ from RTTI support in other languages?
 C++ has dynamic_cast, Java does similar with its casting.  [Not sure how




 Ur-types

 Is this just another way of saying 'reflection API'?


No. He was referring to TObject and IInterface.

sm

May 30 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Sebastian Moleski wrote:

 Ur-types

 Is this just another way of saying 'reflection API'?


 No. He was referring to TObject and IInterface.

Yes, but what about them?!

but what is it they do?

-- 
AlisdairM
Team Thai Kingdom

May 30 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3ED7A9D7.5592D5BF uk.renaultf1.com...
 Sebastian Moleski wrote:

 Ur-types

 Is this just another way of saying 'reflection API'?


 No. He was referring to TObject and IInterface.

 Yes, but what about them?!

 but what is it they do?

If you have one common root in your inheritance tree, you can expect certain
things of all objects that you can't if you have multiple user-defined
ultimate base classes (like C++ offers). Personally, I prefer single-base
languages to multi-base languages just because it makes object-handling much
easier. I know that that's in direct conflict with what a lot of OOP "gurus"
say in regards to C++.

sm

May 30 2003

Ilya Minkov <midiclub 8ung.at> writes:

Alisdair Meredith wrote:
No. He was referring to TObject and IInterface.

 
 Yes, but what about them?!

 but what is it they do?

You can get TObject in a function, and dispatch dynamically based on 
object type. :)

This usage gives trouble if non-tagged types don't get boxing!

-i.

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Sebastian Moleski" <s.moleski tcu.edu> wrote in message
bb89br$29k5$1 digitaldaemon.com
 "Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
 news:3ED7A688.15D9FD43 uk.renaultf1.com...
 DRS wrote:


[...]

 Return value as variable vs. return

 Now this one is interesting, if badly phrased!


Hey!  I'm doing a lot of cutting and pasting!

 [For those that don't know Delphi]
 Delphi, as a language level feature, allows you to assume a variable
 called 'result' in every function.  You can simply assign to result
 through the function call and this value will automatically be returned
 as the function exits.  After you have assigned the value, you can (of
 course) query and use result just like any other local variable.

 Alternatively, you can return a value at any point with a return
 statement, just as in the other languages.

 Return statement? Since when does Delphi have that?

For *ages*.  At least since D4 (see D4 OP reference manual, p 6-4).

My example:

function foo : boolean;

begin
  Result := false;
end;

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

DRS wrote:

 Return statement? Since when does Delphi have that?


 For *ages*.  At least since D4 (see D4 OP reference manual, p 6-4).

I remember using it in Delphi2, not sure about Delphi 1

-- 
AlisdairM
Team Thai Kingdom

May 30 2003

"William Meyer" <bill_meyer earthlink.net> writes:

oN 30-May-03, Alisdair Meredith said:

 I remember using it in Delphi2, not sure about Delphi 1

You're right -- it surfaced in D2.

-- 
Bill
Posted with XanaNews Version 1.15.2.2

Jun 01 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"William Meyer" <bill_meyer earthlink.net> wrote in message
news:bbe6ed$27l$1 digitaldaemon.com...
oN 30-May-03, Alisdair Meredith said:

 I remember using it in Delphi2, not sure about Delphi 1


 You're right -- it surfaced in D2.

Huh? Am I blind? I have Delphi 7 and there's no return statement to be seen.
Any pointers?

sm

Jun 01 2003

"Ignacio Vazquez" <ivazquez orioncommunications.com> writes:

"Sebastian Moleski" <s.moleski tcu.edu> wrote in message
news:bbe6hc$29g$1 digitaldaemon.com...
 "William Meyer" <bill_meyer earthlink.net> wrote in message
 news:bbe6ed$27l$1 digitaldaemon.com...
 oN 30-May-03, Alisdair Meredith said:

 I remember using it in Delphi2, not sure about Delphi 1


 You're right -- it surfaced in D2.

 Huh? Am I blind? I have Delphi 7 and there's no return statement to be

seen.
 Any pointers?

There isn't one. The traditional way to return a value from a function in
Pascal was to assign it to the functoin name.

Cheers,
  Ignacio

Jun 12 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb8ab5$2ave$1 digitaldaemon.com...
 [For those that don't know Delphi]
 Delphi, as a language level feature, allows you to assume a variable
 called 'result' in every function.  You can simply assign to result
 through the function call and this value will automatically be returned
 as the function exits.  After you have assigned the value, you can (of
 course) query and use result just like any other local variable.

 Alternatively, you can return a value at any point with a return
 statement, just as in the other languages.

 Return statement? Since when does Delphi have that?

 For *ages*.  At least since D4 (see D4 OP reference manual, p 6-4).

No. Read again. The OP was saying that Delphi has two ways to pass a value:
via Result or "with a return *statement*, just as in the other languages".
What you showed me was using Result. I am posing that Delphi has no such
"return statement, just as in the other languages" although it has been
requested for quite some time.

sm

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Sebastian Moleski" <s.moleski tcu.edu> wrote in message
bb8b3u$2c33$1 digitaldaemon.com

[...]

 No. Read again. The OP was saying that Delphi has two ways to pass a
 value: via Result or "with a return *statement*, just as in the other
 languages". What you showed me was using Result. I am posing that Delphi
 has no such "return statement, just as in the other languages" although
 it has been requested for quite some time.

You know what?  It's 5:35am and I'm going to bed. :-)

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb8bp7$2d0u$1 digitaldaemon.com...
 No. Read again. The OP was saying that Delphi has two ways to pass a
 value: via Result or "with a return *statement*, just as in the other
 languages". What you showed me was using Result. I am posing that Delphi
 has no such "return statement, just as in the other languages" although
 it has been requested for quite some time.

 You know what?  It's 5:35am and I'm going to bed. :-)

5:35 AM? Hmm, I wonder where you are located now. It's 2:49 PM here at
GMT-6. So that would place you at GMT+9, e.g. Japan, the Koreas or parts of
Australia. Right?

sm

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Sebastian Moleski" <s.moleski tcu.edu> wrote in message
bb8cou$2ee8$1 digitaldaemon.com
 "DRS" <drs removethis.ihug.com.au> wrote in message
 news:bb8bp7$2d0u$1 digitaldaemon.com...

[...]

 You know what?  It's 5:35am and I'm going to bed. :-)

 5:35 AM? Hmm, I wonder where you are located now. It's 2:49 PM here at
 GMT-6. So that would place you at GMT+9, e.g. Japan, the Koreas or parts
 of Australia. Right?

I'm on the east coast of Australia.  *And* *I* *am* *going* *to* *bed*.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb8d25$2er2$1 digitaldaemon.com...
 "Sebastian Moleski" <s.moleski tcu.edu> wrote in message
 bb8cou$2ee8$1 digitaldaemon.com
 "DRS" <drs removethis.ihug.com.au> wrote in message
 news:bb8bp7$2d0u$1 digitaldaemon.com...

 [...]

 You know what?  It's 5:35am and I'm going to bed. :-)

 5:35 AM? Hmm, I wonder where you are located now. It's 2:49 PM here at
 GMT-6. So that would place you at GMT+9, e.g. Japan, the Koreas or parts
 of Australia. Right?

 I'm on the east coast of Australia.  *And* *I* *am* *going* *to* *bed*.

Sweet dreams.

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
3ED7A688.15D9FD43 uk.renaultf1.com
 DRS wrote:

I'm not necessarily competent to argue all the finer points of Delphi's
language constructs, particularly against other languages with which I am
less familiar.  My post was primarily a compilation of the thread in
b.p.d.non-technical at the time and in the absence here of many who
contributed to that it probably should be continued over there.  Or we get
them over here and take over. :-)

 Operator overloading

 Yes (custom variants).

 Does this mean you can only overload operators for a small subset of
 classes (i.e. only through Variants)

I think so.

 I'm not convinced Delphi support is complete enough to claim this, but
 am ready to be proven wrong (the last version of Delphi I used predated
 this support)

Tsk, tsk.  Native variants were introduced in D6 as part of the introduction
of CLX and Kylix, and variants as a whole underwent a lot of changes.  Prior
to that variants were a fudge.

[...]

 And what are other stuff that you can add to this list that is found
 in OP and not in D?


 To take highlights from the list...

[...]

 Ur-types

 Is this just another way of saying 'reflection API'?


TObject, IInterface, and IUnknown.  So Java would score but not C/C++.  I
don't know about D.

[...]

 This stuff you probably wouldn't accept without referring to libraries,
 but Delphi was practically designed around them:

 Interactive UI design

 I think this is as core to Delphi as Design-by-contract is to D, so it
 would be nice to sneak it in somehow <g>
 Besides, it at least requires linker-level support (if not language) to
 support the .dfm format (a text file associated with the
 gui-integration)

.dfms can also be binary (they can be both since D5).  What version of
Delphi are you using?

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

DRS wrote:

 .dfms can also be binary (they can be both since D5).  What version of
 Delphi are you using?

Actually the last Delphi I used was V2 <g>
I've been on BCBuilder since then, so my Delphi knowledge is more
by-association these days.

I think there is enough Delphi-specific info in this thread now for
Walter, unless he wants to query something.  Probably best to take
detailed discussion back over to the borland forum, or we'll drown out
the 'D' discussion!

-- 
AlisdairM

May 30 2003

Ilya Minkov <midiclub 8ung.at> writes:

I have to correct. :)

DRS wrote:
 Arrays of bit

 
 No.

(YES!)
You are wrong: arrays of boolean turn out to be bit-arrays.

 Built-in strings Array slicing Array bounds checking

 
 Yes.

Array slicing? Really? HOW? Please explain.
(I guess NO)

 Aliases


(NO?)

 Operator overloading

 Yes (custom variants).

Unusable! Painfully slow! a standard complex type is implemented this
way, and is (according to rumors) 10-100 times slower than IN PYTHON!!!

 Dynamic class loading

 Yes (via RegisterClass).

Interesting. :)

 Performance Inline assembler


YES.

 Lightweight objects

 Yes (deprecated).

The turbo pascal ones? I don't even know how they work. Is it that
terrible kludge that mimics C++ in a most inappropriate manner?

 Explicit memory allocation control


YES.

 Independent of VM


YES.


 Unit testing

 No.

This is not exactly true. Units have initalisation section. Fill it with
asserts - and there you have it.

 Guaranteed initializatio

 Yes (consts only).

Wait... class fields and something else also always have default values
(0 numerics, "" strings, ...). This is however not true in other Object
Pascal compilers, only in Delphi.

 Thread synchronization primitives

 No?

(YES, i believe.)
I remember, when writing something that belongs to the main thread (GUI
stuff, etc.), you must write something like

syncronize(DoYourWritesToOtherThreadsHere);

 Algol-style syntax


Dunno algol :) I'm too young for this. :)

 Enumerated types


YES.

 Support all C types


(Yes?)

 Complex and Imaginary

 No.

(YES.)
Complex, since version 6, VERY SLOW.

 Direct access to C


YES.

 Use existing debuggers


YES.

 Struct member alignment control


YES. Usually structs are aligned in a system-dependant manner. But if
declaration specifies "packed", the fields are placed after each other
with byte-alignment. You can then control alighnment by
selecting corresponding data types. Until data is "packed", not even the
ordering of fields is specified.

This ability applies not only to structs, but also to arrays.

 Generates standard object files

 Yes.

(more or less) :)

 Macro preprocessor

 No.

(Partial)
IIRC only {$INCLUDE} and conditional compilation features.

GNU Pascal also adds a complete C-like pre-processor, with both
case-sensitive and case-agnostic multi-line macro definitions. Thus,
Templates can be somewhat emulated.

Unlike CPP, where you make a multi-line macro by using "\" at the end of
each line, GNU Pascal defines macros inside comments. This makes macro
definitions automatically span as many lines as requiered.

 And what are other stuff that you can add to this list that is 
 found in OP and not in D?


 Set types

D's bitarray. Yes, Set is better.

 Variant records

This one can be defined in a library in D. IIRC it even is. :)

 True constants

D constants are very true! As opposed to Pascal, where they were mutable
before Delphi. :)

 Default parameters

We have them.

 Open array parameters

Dynamic arrays are more consistent and fulfil the same purpose.

 Reintroduce

What is it?

 Dynamic

Performance-hit kludge!

 Return value as variable vs. return

What?

 Run-Time Type Information (RTTI) operators

WE HAVE FULL RTTI IN D, the same as in Delphi and more powerful than in
any other compiled language! You can even walk classes' fields for types.

 Ur-types

What?
 Packages

What?

 We're still arguing about some of the definitions. :-)

Delphi is quite a seasoned language. :)

-i.

May 30 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
bb8bbe$2cbs$1 digitaldaemon.com
 I have to correct. :)

 DRS wrote:
 Arrays of bit

 No.

 (YES!)
 You are wrong: arrays of boolean turn out to be bit-arrays.

So are sets.

[...]

 Lightweight objects

 Yes (deprecated).

 The turbo pascal ones? I don't even know how they work. Is it that
 terrible kludge that mimics C++ in a most inappropriate manner?

I think this refers to the deprecated Object type, replaced by the Class.

[...]

 Algol-style syntax


 Dunno algol :) I'm too young for this. :)

There's no question of it.  As I said in b.p.d.non-technical (where this
discussion should return), any OP programmer can look at the Algol-60 spec
and will see huge chunks of it still in use in OP today.  The Pascal family
arguably has greater claim to being Algol-like than the C family but that's
not an argument I want to get into.

[...]

 Macro preprocessor

 No.

 (Partial)
 IIRC only {$INCLUDE} and conditional compilation features.

It's a no.  OP's compiler directives are nothing like C/C++'s macros.

[...]

 Reintroduce

 What is it?

Reintroduce allows you to hide an inherited virtual method with a new one:

procedure DoSomething; reintroduce;  // the ancestor class also has a
DoSomething method

It is the opposite of override:

procedure DoSomething; override; // inherit the DoSomething method

MyClass.DoSomething;
begin
  ... do stuff
  inherited DoSomething; // call the ancestor method
end;

[...]

 We're still arguing about some of the definitions. :-)

 Delphi is quite a seasoned language. :)

Yes, but some of the terminology is not the same and not all of us are
intimately familiar with the other languages, so there are cases where we
need to be careful that we know what we're talking about.  Also, there are a
lot of things which Delphi can kinda-sorta do (for example, it can
kinda-sorta do multiple inheritance via interfaces but it's not the same as
C++'s genuine multiple inheritance) or there are things which are library
dependant (since every Delphi unit by default uses the System unit does that
mean everything in Sytem constitutes part of the language?) and so on.

This discussion really belongs back in the borland groups, I think.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

May 30 2003

"Walter" <walter digitalmars.com> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb8ci1$2dtl$1 digitaldaemon.com...
 Yes, but some of the terminology is not the same and not all of us are
 intimately familiar with the other languages, so there are cases where we
 need to be careful that we know what we're talking about.  Also, there are

a
 lot of things which Delphi can kinda-sorta do (for example, it can
 kinda-sorta do multiple inheritance via interfaces but it's not the same

as
 C++'s genuine multiple inheritance) or there are things which are library
 dependant (since every Delphi unit by default uses the System unit does

that
 mean everything in Sytem constitutes part of the language?) and so on.

That's one reason I'd have a problem including Delphi in the chart - I
simply don't know enough about Delphi to make such calls in a consistent
manner with the other languages. Not to say the rest is perfect, either.

May 31 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Walter" <walter digitalmars.com> wrote in message
bb9s9i$18pa$2 digitaldaemon.com

[...]

 That's one reason I'd have a problem including Delphi in the chart - I
 simply don't know enough about Delphi to make such calls in a consistent
 manner with the other languages. Not to say the rest is perfect, either.

You can't reasonably leave it out.  It's a major player despite the fact
that Borland can't market water in the desert, especially outside the US
where it suffers less from the "not made by Microsoft" syndrome.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 01 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bbddpu$2em0$1 digitaldaemon.com...
 that Borland can't market water in the desert, >

ROFL

That was a good one. And sadly true.

sm

Jun 01 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bb8bbe$2cbs$1 digitaldaemon.com...
 Aliases


 (NO?)

Why not?

type MyInt = Integer;

declares an alias names MyInt to the Integer type.

sm

May 30 2003

Ignacio Vazquez <Ignacio_member pathlink.com> writes:

In article <bb8bbe$2cbs$1 digitaldaemon.com>, Ilya Minkov says...
 Lightweight objects

 Yes (deprecated).

The turbo pascal ones? I don't even know how they work. Is it that
terrible kludge that mimics C++ in a most inappropriate manner?

No, records.

 Generates standard object files

 Yes.

(more or less) :)

It can generate both C and C++ .obj files, as well as C DLLs/SOs.

 Macro preprocessor

 No.

(Partial)
IIRC only {$INCLUDE} and conditional compilation features.

That's not a macro preprocessor. Slight difference, but enough.

Cheers,
Ignacio

PS, is there an free NNTP server anywhere that hosts this newsgroup? I don't
want to have to go through this web interface...

Jun 11 2003

"Walter" <walter digitalmars.com> writes:

"Ignacio Vazquez" <Ignacio_member pathlink.com> wrote in message
news:bc8117$2q5p$1 digitaldaemon.com...
 PS, is there an free NNTP server anywhere that hosts this newsgroup? I

don't
 want to have to go through this web interface...

I access it using Outlook Express as news.digitalmars.com

Jun 11 2003

"Ignacio Vazquez" <ivazquez orioncommunications.com> writes:

"Walter" <walter digitalmars.com> wrote in message
news:bc82pf$2s1v$1 digitaldaemon.com...
 "Ignacio Vazquez" <Ignacio_member pathlink.com> wrote in message
 news:bc8117$2q5p$1 digitaldaemon.com...
 PS, is there an free NNTP server anywhere that hosts this newsgroup? I

 don't
 want to have to go through this web interface...

 I access it using Outlook Express as news.digitalmars.com

Ah yes, figured it out.

Thanks,
  Ignacio

Jun 12 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Ignacio Vazquez wrote:

The turbo pascal ones? I don't even know how they work. Is it that
terrible kludge that mimics C++ in a most inappropriate manner?


 No, records.

Records are not objects though, as they do not support member
fucntions/methods.
The deprecated OP objects do count, though, I think.  [Perhaps a
'depracated' flag to further complicate the table!!]


 [Delphi] can generate both C and C++ .obj files, as well as C DLLs/SOs.

Not quite: Delphi does NOT generate C++ .obj files, only 'C' although
these do conform to whatever the prevalant standard is.  [I am a C++
guy, not C, so can't remember the name of the format]

-- 
AlisdairM

Jun 12 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
3EE87BEC.43A521B4 uk.renaultf1.com
 Ignacio Vazquez wrote:

[...]

 [Delphi] can generate both C and C++ .obj files, as well as C DLLs/SOs.

 Not quite: Delphi does NOT generate C++ .obj files, only 'C' although
 these do conform to whatever the prevalant standard is.  [I am a C++
 guy, not C, so can't remember the name of the format]

Not true.  Start a project in Delphi and go to Project > Options... >
Linker.  You get three options for linker output, "Generate DCUs", "Generate
C object files" and "Generate C++ object files".

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 12 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

DRS wrote:

 Not true.  Start a project in Delphi and go to Project > Options... >
 Linker.  You get three options for linker output, "Generate DCUs", "Generate
 C object files" and "Generate C++ object files".

I guess that's what I get for posting without checking against the
latest version <g>

Do you have any references I can look this up on? [Other than the
manuals]
While it makes sense to create standard 'C' .objs (where I believe there
ARE standards) what does it mean to create C++ .objs?  Which C++ linkers
do they work with?

The .obj format is very non-portable in the C++ world, although I
beleive there are efforts under way on Linux to agree a common binary
model.

-- 
AlisdairM

Jun 12 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
3EE8D502.ADAB4392 uk.renaultf1.com
 DRS wrote:

 Not true.  Start a project in Delphi and go to Project > Options... >
 Linker.  You get three options for linker output, "Generate DCUs",
 "Generate C object files" and "Generate C++ object files".

 I guess that's what I get for posting without checking against the
 latest version <g>

 Do you have any references I can look this up on? [Other than the
 manuals]

What's wrong with the help files?

 While it makes sense to create standard 'C' .objs (where I believe there
 ARE standards) what does it mean to create C++ .objs?  Which C++ linkers
 do they work with?

From the D6 help files:

-Generate DCUs: Output standard Delphi DCU format files.
-Generate C object files: Create a C object file for linking with a C
program (no name mangling).
-Generate C++ object files: Create a C++ object file for linking with
C++Builder (uses C++ name mangling).

Choosing to generate C++ object files activates two other options:

-Include namespaces: Puts information into namespaces and mangles the
namespace (the name of the unit) into the symbol. This must be checked if
sharing code with C++Builder. (This option is enabled if Generate C++Object
files is checked.)
-Export all symbols: Creates DLL exports for exported functions in the
project. It is for use when generating OBJs for packages that will be linked
into C++Builder applications. (This option is enabled if Generate C++Object
files is checked.)

Don't ask me what it all means.  I don't do C++.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 12 2003

"Ignacio Vazquez" <ivazquez orioncommunications.com> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
news:3EE87BEC.43A521B4 uk.renaultf1.com...
 Ignacio Vazquez wrote:
The turbo pascal ones? I don't even know how they work. Is it that
terrible kludge that mimics C++ in a most inappropriate manner?


 No, records.

 Records are not objects though, as they do not support member
 fucntions/methods.
 The deprecated OP objects do count, though, I think.  [Perhaps a
 'depracated' flag to further complicate the table!!]

The thing about 'object' is that it's the same as 'class', the only
difference being that it instantiates in the stack instead of the heap and
doesn't support dynamic functions.

OTOH, records can contain function and procedure variable types, they just
don't have a 'self' to them.

Cheers,
  Ignacio

Jun 12 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Ignacio Vazquez" <Ignacio_member pathlink.com> wrote in message
bc8117$2q5p$1 digitaldaemon.com
 In article <bb8bbe$2cbs$1 digitaldaemon.com>, Ilya Minkov says...
 Lightweight objects

 Yes (deprecated).

The turbo pascal ones? I don't even know how they work. Is it that
terrible kludge that mimics C++ in a most inappropriate manner?

 No, records.

No, objects.  The "object" was deprecated in favour of "class".

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 12 2003

Ilya Minkov <webmaster midiclub.de.vu> writes:

DRS wrote:
 "Ignacio Vazquez" <Ignacio_member pathlink.com> wrote in message
 bc8117$2q5p$1 digitaldaemon.com
 
In article <bb8bbe$2cbs$1 digitaldaemon.com>, Ilya Minkov says...

Lightweight objects

Yes (deprecated).

The turbo pascal ones? I don't even know how they work. Is it that
terrible kludge that mimics C++ in a most inappropriate manner?

No, records.

 
 
 No, objects.  The "object" was deprecated in favour of "class".

Records *can* be considered "lightweight object". Look at the left part 
of the table, it says C:YES, C++:YES, Java: NO (IIRC). And guess what's 
the only thing next to the objects is which C supports?

-i.

Jun 13 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Ilya Minkov" <webmaster midiclub.de.vu> wrote in message
bcdnsu$1ule$1 digitaldaemon.com

[...]

 Records *can* be considered "lightweight object". Look at the left part
 of the table, it says C:YES, C++:YES, Java: NO (IIRC). And guess what's
 the only thing next to the objects is which C supports?

Pascal records do not encapsulate both data and code; they do not have
methods.  They therefore are not objects in any meaningful sense.  The
deprecated "object" type is an object in the OO sense but inferior to the
current "class" type.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 14 2003

Andy Friesen <andy ikagames.com> writes:

DRS wrote:
 "Ilya Minkov" <webmaster midiclub.de.vu> wrote in message
 bcdnsu$1ule$1 digitaldaemon.com
 
 [...]
 
 
Records *can* be considered "lightweight object". Look at the left part
of the table, it says C:YES, C++:YES, Java: NO (IIRC). And guess what's
the only thing next to the objects is which C supports?

 
 
 Pascal records do not encapsulate both data and code; they do not have
 methods.  They therefore are not objects in any meaningful sense.  The
 deprecated "object" type is an object in the OO sense but inferior to the
 current "class" type.

Neither do C structs, but they obviously qualify.

Jun 14 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Andy Friesen" <andy ikagames.com> wrote in message
bcfu95$10g9$1 digitaldaemon.com
 DRS wrote:
 "Ilya Minkov" <webmaster midiclub.de.vu> wrote in message
 bcdnsu$1ule$1 digitaldaemon.com

 [...]


Records *can* be considered "lightweight object". Look at the left part
of the table, it says C:YES, C++:YES, Java: NO (IIRC). And guess what's
the only thing next to the objects is which C supports?


 Pascal records do not encapsulate both data and code; they do not have
 methods.  They therefore are not objects in any meaningful sense.  The
 deprecated "object" type is an object in the OO sense but inferior to the
 current "class" type.

 Neither do C structs, but they obviously qualify.

Why obviously?

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 14 2003

"Fabian Giesen" <rygNO SPAMgmx.net> writes:

 Neither do C structs, but they obviously qualify.

 Why obviously?

Because C is listed as having "lightweight objects" in the
comparision chart while not having any higher-level object-alike
primitives than structs and unions.

Jun 14 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Fabian Giesen wrote:

 Because C is listed as having "lightweight objects" in the
 comparision chart while not having any higher-level object-alike
 primitives than structs and unions.

I'll pur the counter-argument: This is another error in the table, like
C++ modules <gdr>

-- 
AlisdairM
Team Thai Kingdom

Jun 15 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
3EEC8705.4E9D68D6 uk.renaultf1.com
 Fabian Giesen wrote:

 Because C is listed as having "lightweight objects" in the
 comparision chart while not having any higher-level object-alike
 primitives than structs and unions.

 I'll pur the counter-argument: This is another error in the table, like
 C++ modules <gdr>

I'd agree.  What is a "lightweight" object anyway?  At the minimum an object
must provide encapsulation, polymorphism and inheritance, otherwise you
might as well say that Visual Basic's "class" is an object!

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 15 2003

"Sebastian Moleski" <s.moleski tcu.edu> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bcig8b$2b5$1 digitaldaemon.com...
 "Alisdair Meredith" <alisdair.meredith uk.renaultf1.com> wrote in message
 3EEC8705.4E9D68D6 uk.renaultf1.com
 Fabian Giesen wrote:

 Because C is listed as having "lightweight objects" in the
 comparision chart while not having any higher-level object-alike
 primitives than structs and unions.

 I'll pur the counter-argument: This is another error in the table, like
 C++ modules <gdr>

 I'd agree.  What is a "lightweight" object anyway?  At the minimum an

object
 must provide encapsulation, polymorphism and inheritance, otherwise you
 might as well say that Visual Basic's "class" is an object!

I assume that by light-weight objects they were referring to stack-based OOP


sm

Jun 15 2003

Ilya Minkov <webmaster midiclub.de.vu> writes:

DRS wrote:
 I'd agree.  What is a "lightweight" object anyway?  At the minimum an object
 must provide encapsulation, polymorphism and inheritance, otherwise you
 might as well say that Visual Basic's "class" is an object!

Nope. I believe that you very often need a simple agregate, which has 
only a handful of fields and involves as little overhead as possible. 
That means:
  - fast handling on stack, as well as by pointer or reference. 
Obviuosly polymorphic objects incur more overhead, because the space 
which they need cannot be determined at compile-time, making stack copy 
allocation impossible.
  - no VTable pointer -- since this would be a significant overhead for 
agregates consisting of only 2 or 3 fields.

this obviously kills polymorphism to 100%, and inheritance stops making 
much sense in this context either.

But look at the source of DMD itself: i believe most of the "objects" 
there are lightweights, and as such are only a way to better organize 
the code operating on usual C structs. These have an extremely wide use 
in C++ projects, especially in those highly focused on performace.

-i.

Jun 15 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Ilya Minkov" <webmaster midiclub.de.vu> wrote in message
bcimlj$7js$1 digitaldaemon.com
 DRS wrote:
 I'd agree.  What is a "lightweight" object anyway?  At the minimum an
 object must provide encapsulation, polymorphism and inheritance,
 otherwise you might as well say that Visual Basic's "class" is an object!

 Nope. I believe that you very often need a simple agregate, which has
 only a handful of fields and involves as little overhead as possible.

Whatever they are they're manifestly not objects.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 16 2003

"Sean L. Palmer" <palmer.sean verizon.net> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bckrp7$24ov$1 digitaldaemon.com...
 "Ilya Minkov" <webmaster midiclub.de.vu> wrote in message
 bcimlj$7js$1 digitaldaemon.com
 DRS wrote:
 I'd agree.  What is a "lightweight" object anyway?  At the minimum an
 object must provide encapsulation, polymorphism and inheritance,
 otherwise you might as well say that Visual Basic's "class" is an



object!
 Nope. I believe that you very often need a simple agregate, which has
 only a handful of fields and involves as little overhead as possible.

 Whatever they are they're manifestly not objects.

I disagree.  It's basically an object without virtual functions.  You can
still do a LOT of OO that way.  You still gain many of the OO "benefits"...
encapsulation, inheritance, data hiding (not in C); just not polymorphism.

More than half of the classes I write are these kind of lightweight classes.

I do like to package datatypes with the code that works on them.  However
I'm not 100% sold that OO-style syntax is a good idea, as many times it's
unclear which class should be promoted to "this" status, if a function works
with several different class parameters.

Sean

  A: Top-posters.
  Q: What is the most annoying thing on Usenet?

Isn't this a FAQ?  You get the answers before you ask the questions.

Sean

Jun 18 2003

"Walter" <walter digitalmars.com> writes:

"DRS" <drs removethis.ihug.com.au> wrote in message
news:bb85ot$24dv$1 digitaldaemon.com...
 Design by Contract

 Yes (assert).

assert is a basic building block for design by contract, but design by
contract is so much more. It really starts coming into its own by the
addition of class invariants and the inheritance of in and out contracts.
Being able to turn the whole thing on or off with a compile switch makes it
nearly painless to load up your code with DbC.

I'll wager that you'll start seeing all the major languages adding in DbC.

May 31 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Oh, and another language I know nothing about but may be part of the


-- 
AlisdairM

May 30 2003

Garen Parham <nospam garen.net> writes:

Alisdair Meredith wrote:

Agree with most of what you said...

 Under reliablility I am very surprised that only 'D' rates as unit
 testable.  I would at least like a link to some material explaining why
 only 'D' qualifies here.  A good opportunity for a sales pitch if ever I
 saw one, this is the detail that caught my attention most!!  [Although I
 don't use Java, I was surprised that its extensive reflection API and
 unit-testing community did not qualify]

Perhaps a poor choice of words, but unit testing is a native concept in D
AFAICT and not in those other languages.

 Oh, and as a cheeky new feature you might want to add 'reference
 implementation available' given that I am not yet aware of a conforming
 C++ implementation [although EDG-based solutions are getting very close
 now]

EDG claims 100% conformity.  (And, in a mere 350K lines of C.) The Comeau 
compiler is the only one to use 'export' iirc though.  

 Interesting chart though.  If you can find the people to contribute I
 would be interested in seeing how Eiffel, Python, Smalltalk and Haskell
 score as well.

Wouldn't that be stretching it a bit?  The audience for D is primarily for the
C-derivative languages and I think thats what Walter was shooting for.

Jun 03 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Garen Parham" <nospam garen.net> wrote in message
bbibft$118r$1 digitaldaemon.com

[...]

 Wouldn't that be stretching it a bit?  The audience for D is primarily
 for the C-derivative languages and I think thats what Walter was shooting
 for.

Then why is one of the boxes in the language comparison labelled
"Algol-style syntax" and not "C-style syntax?"

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 03 2003

Garen Parham <nospam garen.net> writes:

DRS wrote:


 
 Then why is one of the boxes in the language comparison labelled
 "Algol-style syntax" and not "C-style syntax?"

Don't know, Walter?  In any case I'm pretty sure Walter has said he wanted D
to appeal to your typical C-derivitveish language programmers.

Jun 04 2003

Alisdair Meredith <alisdair.meredith uk.renaultf1.com> writes:

Garen Parham wrote:

 Wouldn't that be stretching it a bit?  The audience for D is primarily for the
 C-derivative languages and I think thats what Walter was shooting for.

Well, my languages were chosen for a reason <g>

Eiffel is the poster-child for Design-By-Contract, one of the big draws
of D.  So it would be interesting to see a comparison here (with a
language I know nothing about other than it has DbC and 'repeated'
inheritance)

Python because I am looking to broaden out from my largely C++ base, and
it is definitely a language I would consider ahead of Java when looking
for a simple to use, garbage collected, OO language.

Delphi because its evolution from Pascal to OO Pascal is quite similar
to C -> C++/Java, and Pascal and C are close enough in constructs to be
dialects within a broader family of languages.  Comparisons between
Delphi and C++/Java are quite straightforward, so it is not unreasonable
on a D list.

Smalltalk is the early playgroud of OO, so it is interesting to see what
routes its successors have taken.

Haskell was just mischief making <g>

I agree that Python/Delphi/Smalltalk (and probably Eiffel, don't know
syntax) are not in the 'C' langauge family that the table covers at the
moment, but they are also close enough to make comparison interesting,
and maybe shed new light on the way you think about using D.  Simply
putting a name on a feature can open up new avenues of thought.  Look at
the explosion in template metaprogramming in C++, or policy based
design, once the terms entered common usage.  Sure people were doing
these things before, but once we had language to describe the ideas,
EVERYONE is doing it <g>

-- 
AlisdairM
Team Thai Kingdom

Jun 04 2003

Garen Parham <nospam garen.net> writes:

Alisdair Meredith wrote:


 Well, my languages were chosen for a reason <g>
 
 Eiffel is the poster-child for Design-By-Contract, one of the big draws
 of D.  So it would be interesting to see a comparison here (with a
 language I know nothing about other than it has DbC and 'repeated'
 inheritance)

That could be okay then, since you'd be comparing 'comparable' features.

 Python because I am looking to broaden out from my largely C++ base, and
 it is definitely a language I would consider ahead of Java when looking
 for a simple to use, garbage collected, OO language.

Yeah me too, but it's got a lower ceiling w.r.t. potential uses due to 
performance reasons.

 Delphi because its evolution from Pascal to OO Pascal is quite similar
 to C -> C++/Java, and Pascal and C are close enough in constructs to be
 dialects within a broader family of languages.  Comparisons between
 Delphi and C++/Java are quite straightforward, so it is not unreasonable
 on a D list.

Those aren't too far out there. I didn't see you mention those ones though.

 Smalltalk is the early playgroud of OO, so it is interesting to see what
 routes its successors have taken.

 Haskell was just mischief making <g>


 I agree that Python/Delphi/Smalltalk (and probably Eiffel, don't know
 syntax) are not in the 'C' langauge family that the table covers at the
 moment, but they are also close enough to make comparison interesting,
 and maybe shed new light on the way you think about using D.  Simply
 putting a name on a feature can open up new avenues of thought.  Look at
 the explosion in template metaprogramming in C++, or policy based
 design, once the terms entered common usage.  Sure people were doing
 these things before, but once we had language to describe the ideas,
 EVERYONE is doing it <g>
 

If such accidents occur with D we could actually change the language to
support the style too. :)

Jun 04 2003

Georg Wrede <Georg_member pathlink.com> writes:

 I agree that Python/Delphi/Smalltalk (and probably Eiffel, don't know
 syntax) are not in the 'C' langauge family that the table covers at the
 moment, but they are also close enough to make comparison interesting,
 and maybe shed new light on the way you think about using D.


Maybe such a table should be on an unofficial site? I agree that 
making such a comparison could give new insight into where D
stands, but if it were on Digital Mars' site then it would have to
be correct from the start, and this would be a totally unnecessary
burden on Walter.

Jun 05 2003

Helmut Leitner <leitner hls.via.at> writes:

Georg Wrede wrote:
 
 I agree that Python/Delphi/Smalltalk (and probably Eiffel, don't know
 syntax) are not in the 'C' langauge family that the table covers at the
 moment, but they are also close enough to make comparison interesting,
 and maybe shed new light on the way you think about using D.


 
 Maybe such a table should be on an unofficial site? I agree that
 making such a comparison could give new insight into where D
 stands, but if it were on Digital Mars' site then it would have to
 be correct from the start, and this would be a totally unnecessary
 burden on Walter.

You can use
   <http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD>
Click on edit and you will see how the wiki works.

The formatseparator   separates parameters from field content.
   3          means that 3 cells are connected horizontally
   ...#color  colors a single cell, you may use simple names (#red)
              or typical HTML rrggbb values (#f37921)

-- 
Helmut Leitner    leitner hls.via.at
Graz, Austria   www.hls-software.com

Jun 05 2003

Georg Wrede <Georg_member pathlink.com> writes:

In article <3EDF7052.90DD838D hls.via.at>, Helmut Leitner says...
Georg Wrede wrote:
 Maybe such a table should be on an unofficial site? 

You can use
   <http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD>
Click on edit and you will see how the wiki works.

For those interested and knowledgeable, I already filled in
the data from the Official comparison (hope I'n not getting
sued for copyright), and put in a few other language columns.

I assume at least the Delphi column will get filled soon?

Jun 05 2003

"Walter" <walter digitalmars.com> writes:

"Georg Wrede" <Georg_member pathlink.com> wrote in message
news:bbo8f6$kk0$1 digitaldaemon.com...
 In article <3EDF7052.90DD838D hls.via.at>, Helmut Leitner says...
Georg Wrede wrote:
 Maybe such a table should be on an unofficial site?

You can use
   <http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD>
Click on edit and you will see how the wiki works.

 For those interested and knowledgeable, I already filled in
 the data from the Official comparison (hope I'n not getting
 sued for copyright), and put in a few other language columns.

No problem, make your own version of the table, as long as it is identified
as unofficial.

 I assume at least the Delphi column will get filled soon?

Jun 05 2003

Ilya Minkov <midiclub 8ung.at> writes:

I'm looking at the comparison on Helmut's WIKI:

http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD


Who found function overloading in Delphi? I believe it's not possible.

-i.

Jun 08 2003

"Carlos Santander B." <carlos8294 msn.com> writes:

"Ilya Minkov" <midiclub 8ung.at> escribi� en el mensaje
news:bc0ccj$203u$1 digitaldaemon.com...
|
| Who found function overloading in Delphi? I believe it's not possible.
|

Isn't there an "overload" keyword in Delphi?

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.488 / Virus Database: 287 - Release Date: 2003-06-05

Jun 08 2003

Ilya Minkov <midiclub 8ung.at> writes:

Carlos Santander B. wrote:
 "Ilya Minkov" <midiclub 8ung.at> escribi=F3 en el mensaje
 news:bc0ccj$203u$1 digitaldaemon.com...
 |
 | Who found function overloading in Delphi? I believe it's not possible=

=2E
 |
=20
 Isn't there an "overload" keyword in Delphi?

"overload"? First time i hear. It's not in my Delphi 2.0 book.

=2E..wait... searching the net...

You were right.

Starting with Delphi 4.0 (which was a great step forward for various=20
reasons), Function/Method overloading and Default parameter values have=20
been added.

-i.

Jun 09 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
bc0ccj$203u$1 digitaldaemon.com
 I'm looking at the comparison on Helmut's WIKI:

 http://www.prowiki.org/wiki4d/wiki.cgi?LanguagesVersusD

 Who found function overloading in Delphi? I believe it's not possible.

function Divide(X, Y: Real): Real; overload;
begin
  Result := X/Y;
end;

function Divide(X, Y: Integer): Integer; overload;
begin
  Result := X div Y;
end;



-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 09 2003

Ilya Minkov <midiclub 8ung.at> writes:

DRS wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
Who found function overloading in Delphi? I believe it's not possible.


Yeah, yeah, i know already. It just wasn't yet there as i learned 
Delphi, and i have not made a step past 3.0 -- and this feature was 
added in 4.0.

-i.

Jun 09 2003

"DRS" <drs removethis.ihug.com.au> writes:

"Ilya Minkov" <midiclub 8ung.at> wrote in message
bc290l$ks1$1 digitaldaemon.com
 DRS wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
Who found function overloading in Delphi? I believe it's not possible.


 Yeah, yeah, i know already. It just wasn't yet there as i learned
 Delphi, and i have not made a step past 3.0 -- and this feature was
 added in 4.0.

D8 will be out around the end of the year.  You have a lot of catching up to
do!

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Jun 09 2003

jerlyn camina <jerlyn_member pathlink.com> writes:

In article <bc2bgf$nft$1 digitaldaemon.com>, DRS says...
"Ilya Minkov" <midiclub 8ung.at> wrote in message
bc290l$ks1$1 digitaldaemon.com
 DRS wrote:
 "Ilya Minkov" <midiclub 8ung.at> wrote in message
Who found function overloading in Delphi? I believe it's not possible.


 Yeah, yeah, i know already. It just wasn't yet there as i learned
 Delphi, and i have not made a step past 3.0 -- and this feature was
 added in 4.0.

D8 will be out around the end of the year.  You have a lot of catching up to
do!
hey waz up you are welling to have a friend.

-- 

 A: Top-posters.
 Q: What is the most annoying thing on Usenet?

Sep 05 2005

D Programming

C/C++ Programming

Other

D - D vs Other Languages