Jump to page: 1 26  
Page
Thread overview
(OT) Slashdot on the future of C++
Jul 11, 2005
Nick
Jul 11, 2005
Andrew Fedoniouk
Jul 11, 2005
AJG
Jul 11, 2005
Andrew Fedoniouk
Jul 12, 2005
Walter
Jul 12, 2005
Andrew Fedoniouk
Jul 14, 2005
Walter
Jul 14, 2005
Andrew Fedoniouk
Jul 15, 2005
Walter
Jul 12, 2005
Walter
Jul 12, 2005
Andrew Fedoniouk
Jul 13, 2005
Charles Hixson
Jul 13, 2005
Andrew Fedoniouk
Jul 13, 2005
Brad Beveridge
Jul 13, 2005
Brad Beveridge
Jul 13, 2005
Brad Beveridge
Jul 14, 2005
brad beveridge
Jul 14, 2005
Andrew Fedoniouk
Jul 14, 2005
Brad Beveridge
Jul 14, 2005
Andrew Fedoniouk
Jul 14, 2005
Brad Beveridge
Jul 14, 2005
Andrew Fedoniouk
Jul 13, 2005
Regan Heath
Jul 13, 2005
Regan Heath
Jul 14, 2005
Regan Heath
Jul 14, 2005
Regan Heath
Jul 14, 2005
Andrew Fedoniouk
Jul 14, 2005
Andrew Fedoniouk
Jul 14, 2005
Hasan Aljudy
Jul 11, 2005
Dejan Lekic
Jul 11, 2005
Regan Heath
Jul 12, 2005
Dejan Lekic
Jul 13, 2005
Charles Hixson
Jul 13, 2005
llothar
Jul 13, 2005
Mike Capp
Jul 14, 2005
Walter
Jul 14, 2005
Mike Capp
Jul 15, 2005
Ben Hinkle
Jul 15, 2005
AJG
Jul 15, 2005
Uwe Salomon
Jul 15, 2005
Ben Hinkle
Jul 15, 2005
Mike Capp
Jul 12, 2005
M
July 11, 2005
Slashdot just ran a discussion on the future of C++: http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

Naturally a lot of people came out to vent their misgivings about the language. Here's some of the stuff I found complaints about:

- No garbage collection
- Member function pointers (ie. no delegates)
- Lack of "abstract" and "typeof" keywords
- No modules, and the namespace system is a hack to try to fix this
- Memory safety and language safety in general
- Too many complicated and unecessary language rules

I think I might know a language that fixes, or improves on, all these :D

Nick


July 11, 2005
"Nick" <Nick_member@pathlink.com> wrote in message news:daug61$1tn6$1@digitaldaemon.com...
> Slashdot just ran a discussion on the future of C++: http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8
>
> Naturally a lot of people came out to vent their misgivings about the
> language.
> Here's some of the stuff I found complaints about:
>
> - No garbage collection
> - Member function pointers (ie. no delegates)
> - Lack of "abstract" and "typeof" keywords
> - No modules, and the namespace system is a hack to try to fix this
> - Memory safety and language safety in general
> - Too many complicated and unecessary language rules
>
> I think I might know a language that fixes, or improves on, all these :D
>

Just to be precise: this set of features describes Java/C# and not D. E.g. memory safety is available only in managed environments so far.

Andrew.


July 11, 2005
Also for the record, in C# it is inherently possible to:
1) Call native, unsafe code directly (P/Invoke && DllImport).
2) Use raw pointers and arithmetic (IntPtr).

So it doesn't have complete memory safety either. I don't know about Java. There's probably a per-platform way of doing that too, if you really wanted to.

I think it's "safe" to say that D has relatively safe memory management, in most cases. Granted, it's still possible to blow your whole leg off, but you can do that everywhere, if you set your mind to it ;)

--AJG.

>"Nick" <Nick_member@pathlink.com> wrote in message news:daug61$1tn6$1@digitaldaemon.com...
>> Slashdot just ran a discussion on the future of C++: http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8
>>
>> Naturally a lot of people came out to vent their misgivings about the
>> language.
>> Here's some of the stuff I found complaints about:
>>
>> - No garbage collection
>> - Member function pointers (ie. no delegates)
>> - Lack of "abstract" and "typeof" keywords
>> - No modules, and the namespace system is a hack to try to fix this
>> - Memory safety and language safety in general
>> - Too many complicated and unecessary language rules
>>
>> I think I might know a language that fixes, or improves on, all these :D
>>
>
>Just to be precise: this set of features describes Java/C# and not D. E.g. memory safety is available only in managed environments so far.
>
>Andrew.
>
>


July 11, 2005
Nick wrote:

> Slashdot just ran a discussion on the future of C++:
> http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8

Actually they linked to an article of Bjarne about the future "C++0x"...
(http://www.research.att.com/~bs/rules.pdf)

I think there was a major difference between C++ and D almost at once, he wants to use the standard library while Walter wants to build it in:

See "Rationale for Builtins" http://www.digitalmars.com/d/builtin.html

--anders

PS.
I must confess I stopped reading somewhere at
"C++0x will be almost 100-percent compatible
with the existing Standard C++."... Same old ?

July 11, 2005
Nick wrote:

> - No garbage collection
> - Member function pointers (ie. no delegates)
> - Lack of "abstract" and "typeof" keywords
> - No modules, and the namespace system is a hack to try to fix this
> - Memory safety and language safety in general
> - Too many complicated and unecessary language rules

As "many years C++ developer" I can say:

1) IMHO it is a good choice not to give garbage collection to the core language - this way people can use variety of GC implementations, for different purposes...

2) Same as previous - there are thousands of excellent delegate-like libraries, some type-safe, some not - again for all tastes.

3) We (C++) developers do not need an abstract keyword to know that our
class is an abstract class. Secondly - there is typeof keyword!

4) If one (developer) writes safe code, follows C++ priciples, basically -
disciplined C++ programmer, he'll write more safe program than (IMHO the
safest) Modula-3 or ADA programers.

5) Again, You do not need to follow them all - it is UP YOU! :)

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

July 11, 2005
On Tue, 12 Jul 2005 00:18:01 +0200, Dejan Lekic <leka@entropy.tmok.com> wrote:
> Nick wrote:
>
>> - No garbage collection
>> - Member function pointers (ie. no delegates)
>> - Lack of "abstract" and "typeof" keywords
>> - No modules, and the namespace system is a hack to try to fix this
>> - Memory safety and language safety in general
>> - Too many complicated and unecessary language rules

This is not an attack on C++, nor your defence of it.

> As "many years C++ developer" I can say:
>
> 1) IMHO it is a good choice not to give garbage collection to the core
> language - this way people can use variety of GC implementations, for
> different purposes...

If any GC can be plugged in, or completely disabled you've achieved the same end, in a better way.

> 2) Same as previous - there are thousands of excellent delegate-like
> libraries, some type-safe, some not - again for all tastes.

Are any as easy to use as a built in solution can be? How many different ways are there to do delegates?

I recall recently someone wanting to copy the stack, ideally any difference in goal like this would be customizable with a built in solution.

Ideally the language should be powerful enough to allow you to write a library delegate to achieve any goal not already supported by the built in solution.

> 3) We (C++) developers do not need an abstract keyword to know that our
> class is an abstract class. Secondly - there is typeof keyword!

Having a keyword is useful, it clearly states the programmers intent - allowing the compiler to verify that intent and it documents to the next developer the intent, again allowing verification. This is a general statement not specific to any particular keyword.

> 4) If one (developer) writes safe code, follows C++ priciples, basically -
> disciplined C++ programmer, he'll write more safe program than (IMHO the
> safest) Modula-3 or ADA programers.

I smell a language war brewing.

You could remove the word "C++" from the above, change the part which begins "(IMHO.." to read "otherwise" and it would be a much truer statement IMO, eg.

"If one (developer) writes safe code, follows priciples, basically disciplined programmer, he'll write more safe program than otherwise"

Sure, each language provides more or less in the way of safety but in the end it's the individual developer that matters.

> 5) Again, You do not need to follow them all - it is UP YOU! :)

I assume the word "to" is missing from that last statement? ;)

Regan
July 11, 2005
"AJG" <AJG_member@pathlink.com> wrote in message news:daum5v$22uh$1@digitaldaemon.com...
> Also for the record, in C# it is inherently possible to:
> 1) Call native, unsafe code directly (P/Invoke && DllImport).
> 2) Use raw pointers and arithmetic (IntPtr).
>
> So it doesn't have complete memory safety either. I don't know about Java. There's probably a per-platform way of doing that too, if you really wanted to.
>
> I think it's "safe" to say that D has relatively safe memory management,
> in most
> cases. Granted, it's still possible to blow your whole leg off, but you
> can do
> that everywhere, if you set your mind to it ;)
>

Your answer just proves that

Java/C# has builtin memory safety
but in some exceptional cases like:

> 1) Call native, unsafe code directly (P/Invoke && DllImport).
> 2) Use raw pointers and arithmetic (IntPtr).

(or using JNI calls in Java)

you can break that builtin memory safety rules.

I am not against D. I am just trying to be impartial.

Any memory safety has its own price. Pretty frequently
(at least in my cases) this mandatory price is not acceptable.
That's it.

> --AJG.
>
>>"Nick" <Nick_member@pathlink.com> wrote in message news:daug61$1tn6$1@digitaldaemon.com...
>>> Slashdot just ran a discussion on the future of C++: http://developers.slashdot.org/article.pl?sid=05/07/11/1134203&tid=156&tid=8
>>>
>>> Naturally a lot of people came out to vent their misgivings about the
>>> language.
>>> Here's some of the stuff I found complaints about:
>>>
>>> - No garbage collection
>>> - Member function pointers (ie. no delegates)
>>> - Lack of "abstract" and "typeof" keywords
>>> - No modules, and the namespace system is a hack to try to fix this
>>> - Memory safety and language safety in general
>>> - Too many complicated and unecessary language rules
>>>
>>> I think I might know a language that fixes, or improves on, all these :D
>>>
>>
>>Just to be precise: this set of features describes Java/C# and not D. E.g. memory safety is available only in managed environments so far.
>>
>>Andrew.
>>
>>
>
> 


July 12, 2005
No, I do not defend C++ - If I was so deeply in love in it I would not use other languages, notably Modula-3, D or C# (i've excluded some scripting languages from the list)... I just dislike common anti-c++ articles, even if they make sense, because we, developers, use what we are familiar with, and what "does the job" (TM). :)

-- 
...........
Dejan Lekic
  http://dejan.lekic.org

July 12, 2005
typeof keyword is not in C++ standard (as far as I know), it is add on in some compilers like gnu c and gnu c++.

In article <dauqod$27hl$1@digitaldaemon.com>, Dejan Lekic says...
>
>Nick wrote:
>
>> - No garbage collection
>> - Member function pointers (ie. no delegates)
>> - Lack of "abstract" and "typeof" keywords
>> - No modules, and the namespace system is a hack to try to fix this
>> - Memory safety and language safety in general
>> - Too many complicated and unecessary language rules
>
>As "many years C++ developer" I can say:
>
>1) IMHO it is a good choice not to give garbage collection to the core language - this way people can use variety of GC implementations, for different purposes...
>
>2) Same as previous - there are thousands of excellent delegate-like libraries, some type-safe, some not - again for all tastes.
>
>3) We (C++) developers do not need an abstract keyword to know that our
>class is an abstract class. Secondly - there is typeof keyword!
>
>4) If one (developer) writes safe code, follows C++ priciples, basically -
>disciplined C++ programmer, he'll write more safe program than (IMHO the
>safest) Modula-3 or ADA programers.
>
>5) Again, You do not need to follow them all - it is UP YOU! :)
>
>Kind regards
>
>Dejan
>
>-- 
>...........
>Dejan Lekic
>  http://dejan.lekic.org
> 


July 12, 2005
"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:dauv5e$2b1f$1@digitaldaemon.com...
> Any memory safety has its own price. Pretty frequently
> (at least in my cases) this mandatory price is not acceptable.
> That's it.

True. D doesn't eliminate the potential for memory corruption. What it does try to do, however, is reduce the probability of them by 1) providing less error-prone ways to get the functionality, such as using out and inout parameters rather than pointers and 2) adding runtime checks such as array bounds overflow checking and contract programming.


« First   ‹ Prev
1 2 3 4 5 6