http://www.andromeda.com/people/ddyer/topten.html

"Frank de Groot" <nos...@nospam.com> wrote in message
news:3daf137e$1@newsgroups.borland.com...

2 and 8 (and maybe 12 and 13) apply to Delphi.

Oliver

No they don't

2. if (a := b) then c ?? and True < 5 will not compile either

8. if ... then ...; else ...; will not compile

12. Delphi warns for this (quite strictly)

13. Not really. Delphi doesn't have much of macro expansion :)

I agree about 8, but 2?

--
Eyal Post
----------------------------------------------

news:3dafe232@newsgroups.borland.com...

In article <3dafe...@newsgroups.borland.com>, Oliver Townshend says...

I can understand 8, 12 and 13, but how does 2 apply? In Delphi, booleans
are not just integers.
--
Rudy Velthuis (TeamB)

"Statistics are like a bikini. What they reveal is suggestive.
 What they conceal is vital."
 - Arthur Koestler

In article <3db08...@newsgroups.borland.com>, Oliver Townshend says...

Then I agree. <g>
--
Rudy Velthuis (TeamB)

"Statistics are like a bikini. What they reveal is suggestive.
 What they conceal is vital."
 - Arthur Koestler

On Thu, 17 Oct 2002 21:46:36 +0200, "Frank de Groot"

     Apparently the authors of the page got screwed by C--there are 16
items there.  Is the 10 perhaps in hex?

No, he wanted to be fair and not include the last 6, as they were "common
knowledge".

news:hb21ruoivu5m909nc1ik6alcb2m9rnjrlk@4ax.com...

"Frank de Groot" <nos...@nospam.com> wrote:

yeah, I read those. Speaking of cpp vs delphi,

i "just came from" cppbuilder.nontechnical forum,
where there is a discusion because

Borland wants to propose the ISO comitee to add new
language's extensions to cpp like method pointers
and a published section for classes,

(they exist in cppbuilder as non standards)
that are things that already WORK IN DELPHI.

i was surprise how much rejection the cpp guys
have against methods pointers, which is the most
valuable extension.

yeah i mean "TMyProc = procedure of object"

some of them just prefer to use templates,
libraries, pragmas, compiler/linker directives
("compiler magic" if you prefer) instead.

even microsoft get on the run with its c#
delegates...

what do you think DELPHI guys?

coyotebuddy

I think you misunderstood, as I don't think anyone in BCB NGs would
disagree with the proposal!  However, some people have had run-ins with
the Ansi committee before, and know that if your proposal can be
achieved within the language that exists, then such a 'syntactic sugar'
proposal is likely to be rejected.  They went on to demonstrate to
method pointers could be implemeneted today using some pretty ugly
template programming.

Most of us understand that when you need to go to such lengths to
achieve something, few people will bother no matter how useful.  Adding
core language support makes the feature available to many more people.
IMNSHO, it is important to future success of C++ that such a proposal is
accepted.

Oh, and I think the Delphi community should be mad as heck as borland
are trying to help C++ catch up with the lead Delphi has had for years
;? )

--
AlisdairM
Team Thai Kingdom

In article <3DB19BDC.367E2...@uk.renaultf1.com>, Alisdair Meredith
says...

That depends. If this functionality simply comes in the form of an
additional library, the user will not care how complex the code in that
library is, as long as it is easy to use.

I'm pretty sure that the IEC/ISO/ANSI (or what is it, currently)
committee will know that too. <g>
--
Rudy Velthuis (TeamB)

"Statistics are like a bikini. What they reveal is suggestive.
 What they conceal is vital."
 - Arthur Koestler

"Rudy Velthuis (TeamB)" <rvelth...@gmx.de> wrote:

im afraid youre wrong. Just because  a library already
supports a functionality doesnt meen we could work with
a better way to express the ideas.

Take the gotos vs structured sentences (for, while) by example.
why languages such as delphi & cpp recreate goto
functionality with "while", "for", "case" or "repeat-until",
why doesnt stay with plain "goto"...

because they allow to express the same funtionality to
common control flow structures, avoiding errors.

exactly, method pointers, allow easy functionality
versus templates...

personally, i hope the comitee see thats its time
for cpp to evolve, just as pascal (delphi) did...

"John Kaster (Borland)" <jkas...@borland.com> wrote in message
news:3DB24FAB.46945ADB@borland.com...

Why would this make Borland stronger? If it's a standard, everyone is going
(or at least allowed) to include it right?
So what's the advantage to Borland? Having made it up? Being the first to
implement it?
Or will there be a pattent, so that Borland can ask royalties to everyone
who uses it?

Do they? Then why is MS VC++ by far the most prominent and heavily-used
C++ compiler, despite the fact that it is also the least compliant (much
less so than Borland's offering)?

IMO the biggest reason for C++ites not flocking to BCB is the fact that
it depends heavily on a library written in Object Pascal. C++
programmers as a breed have a deep aversion to anything Pascal-related -
they regard those who work in Pascal as "quiche eaters" rather than real
programmers, and therefore treat any large body of code written in
Pascal with deep suspicion. Anybody who would choose to work in a baby
language like Pascal must thus be incapable of writing the sort of
tight, efficient, well-designed, and reliable code that C and C++
programmers produce (WindowsME, Microsoft Word, etc.), so you'd have to
use actual physical force to make a good many of them even look at a C++
environment that is based around the Object Pascal VCL, irrespective of
how compliant the compiler might or might not be.

The big thing that bugs me about all C-derived languages (including Java
and C#) is the stupid "keep it like PDP-7 assembly code" switch
statement, with its daft restriction of one value per case. Conditional
branches are the most commonly used programming construct next to
assignment, so why is it that C lovers have a mental block when it comes
to something as simple as sub-ranges, especially when the C-style "if"
statement is so clumsy, paranthesis-laden, long-winded, and error-prone?

This type of dinosaur might have made sense in the days when compilers
had to run on machines with 4K of RAM, but even people who write code
for electronic doorbell chimes don't use the host CPU for compiling, and
there's no way that anybody is going to run the JDK or Visual Studio.NET
on anything with less than several hundred megabytes of RAM. Is it not
therefore time to abandon this silly "in the beginning all was void, and
then K&R said "Let there be C"" worship of early 1970s data-processing,
and finally give these Goya-esque semantic horrors a few linguistic
features that actually enhance clarity and ease of coding instead of
doing everything possible to work against it?