(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.)

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

"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

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.

"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?

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

"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?

"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

Alisdair Meredith wrote:
>>No. He was referring to TObject and IInterface.
> 
> Yes, but what about them?!
> I'm guessing the Object in Java and the equivalent in C# do the same,
> 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.

"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