View mode: basic / threaded / horizontal-split · Log in · Help
April 29, 2005
Re: Is D taking hold in the C++ world?
Ben Hinkle wrote:
>>>MATLAB uses "." independent of value/reference semantics and it works 
>>>fine. The difference between value/reference only shows up in assignment 
>>>behavior (which is the definition of value/reference anyway). But then 
>>>MATLAB also doesn't have pointers.
>>
>>IMHO, getting rid of -> and just using . was a good idea, but that is a 
>>different question.
>>
>>I, like the others (it's nice to know I'm not alone) don't like the 
>>current syntax.  I've stated before my beefs with it:
>>
>>1) Makes it hard to write a template that handles both struct pointers and 
>>object references correctly.
> 
> I'm not sure what you are referring to. Can you give a pointer to a post or 
> examples?

Say that you want to store a pointer to a type in a template struct.  Do 
you do this?
	struct RefTo(T) {
	  T reference;
	}
which works for classes, or this
	struct RefTo(T) {
	  T *pointer;
	}
which works for structs?  Sure, you can do specialized templates, but 
that's a kludge to work around the problem, IMHO.

>>2) Leads to a very common newbie error: segfault because he used an 
>>uninitialized class reference.  (If we had used C++ syntax, then Java 
>>programmers would have had a learning curve...but their error would be 
>>caught at build time, not as a runtime error, which, IMHO, is far 
>>superior)
> 
> IMO better segv than slicing objects passed by value. Any non-trivial class 
> hierarchy is destined to be manipulated by reference.

I half agree and half disagree.  I think that Walter made a very good 
point when he said that copy constructors are trouble; you are making a 
similar point by saying that we don't want to pass objects by value.

So why not just ban passing classes by value?  That is, the following 
code would be illegal:
	class Foo {};
	int myFunc(Foo pass_by_value) {...}
it would give an error:
	ERROR: Class objects cannot be passed by value.
	They must be passed by pointer instead.

Likewise, any code that required copying a class by value would be 
illegal.  Offhand, I can think of:
* Class values as function parameters
* Class values as function return values
* Direct object assignments

>>3) Made it so that class objects can't be on the stack.  Let's be honest, 
>>here, the whole reason that we have 'auto' is a kludge to get around the 
>>syntax problem.
> 
> I'm with Walter (and Java/C#) that class objects on the stack should be 
> rare. If there are issues with structs that require lots of auto classes 
> then structs need attention. Actually auto classes don't have anything to do 
> with being on the stack - they just force the dtor to be called on scope 
> exit. IMO I haven't seen a D class that should be auto (I've seen good uses 
> auto variables but declaring a class as auto forces all uses to be auto).

I agree that the vast majority of class objects should be on the heap. 
But why require it?

BTW, similar to this is the problem that you can't have a global class 
object without having to initialize it in an init() function.

>>4) Invited confusion over === and ==
> 
> Agreed - though the current design isn't unreasonable in the big picture. 

:)
April 29, 2005
Re: Is D taking hold in the C++ world?
>> I've read a couple of things recently that've indicated that D's not 
>> taken seriously by the C++ world.
>
>I'm not in the C++ plus world, nor are my professional colleagues, but I'm
>wondering if D's target audience is not the current C/C++/C#/Java crowd.
>Instead, might it be found in the Perl, Python, Ruby, Euphoria, and
>total-newbie groups that have not been exposed to the foibles of the 'C'
>legacy, and are looking for speed, power, and simplicity?

A Python programmer looking for simplicity should switch to D? Have you ever
looked at Python?
April 29, 2005
Re: Is D taking hold in the C++ world?
"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message 
news:d4tgj7$usv$1@digitaldaemon.com...
> Ben Hinkle wrote:
>>>>MATLAB uses "." independent of value/reference semantics and it works 
>>>>fine. The difference between value/reference only shows up in assignment 
>>>>behavior (which is the definition of value/reference anyway). But then 
>>>>MATLAB also doesn't have pointers.
>>>
>>>IMHO, getting rid of -> and just using . was a good idea, but that is a 
>>>different question.
>>>
>>>I, like the others (it's nice to know I'm not alone) don't like the 
>>>current syntax.  I've stated before my beefs with it:
>>>
>>>1) Makes it hard to write a template that handles both struct pointers 
>>>and object references correctly.
>>
>> I'm not sure what you are referring to. Can you give a pointer to a post 
>> or examples?
>
> Say that you want to store a pointer to a type in a template struct.  Do 
> you do this?
> struct RefTo(T) {
>   T reference;
> }
> which works for classes, or this
> struct RefTo(T) {
>   T *pointer;
> }
> which works for structs?  Sure, you can do specialized templates, but 
> that's a kludge to work around the problem, IMHO.

When you said "template that handles struct pointer and objects refs" I 
thought you meant
 struct RefTo(T) {
  T bar;
 }
 RefTo!(Object) blah;
 RefTo!(MyStruct*) blah2;
The same template RefTo should be usable by anything with reference 
semantics (which both struct ptrs and object refs have). I agree sometimes 
you have to write two templates if you want to use it both with a type with 
value semantics and with a type with reference semantics. But that's only 
logical. For the particular case of "RefTo" I'm not sure what the point is 
but I'd say leave it as one template and make users explicitly take a 
reference to the structs since that's how structs in D behave - trying to 
make D structs act like they have reference semantics will result in 
confusing and clunky code IMO.

>>>2) Leads to a very common newbie error: segfault because he used an 
>>>uninitialized class reference.  (If we had used C++ syntax, then Java 
>>>programmers would have had a learning curve...but their error would be 
>>>caught at build time, not as a runtime error, which, IMHO, is far 
>>>superior)
>>
>> IMO better segv than slicing objects passed by value. Any non-trivial 
>> class hierarchy is destined to be manipulated by reference.
>
> I half agree and half disagree.  I think that Walter made a very good 
> point when he said that copy constructors are trouble; you are making a 
> similar point by saying that we don't want to pass objects by value.
>
> So why not just ban passing classes by value?  That is, the following code 
> would be illegal:
> class Foo {};
> int myFunc(Foo pass_by_value) {...}
> it would give an error:
> ERROR: Class objects cannot be passed by value.
> They must be passed by pointer instead.
>
> Likewise, any code that required copying a class by value would be 
> illegal.  Offhand, I can think of:
> * Class values as function parameters
> * Class values as function return values
> * Direct object assignments

That is an option but I think it would be one of last resort. A type should 
be usable by itself - if taking pointers to something is required in order 
to make it useful then that should be built into the type. Also by building 
reference semantics into object you avoid silly typedefs like
typedef Window_t* Window;
I dislike C/C++ code that hides pointers behind typedefs. The typedef only 
becomes usable when it has some obvious naming convention like WindowRef and 
at that point WindowRef is pretty much the same as Window_t* so why bother.

>>>3) Made it so that class objects can't be on the stack.  Let's be honest, 
>>>here, the whole reason that we have 'auto' is a kludge to get around the 
>>>syntax problem.
>>
>> I'm with Walter (and Java/C#) that class objects on the stack should be 
>> rare. If there are issues with structs that require lots of auto classes 
>> then structs need attention. Actually auto classes don't have anything to 
>> do with being on the stack - they just force the dtor to be called on 
>> scope exit. IMO I haven't seen a D class that should be auto (I've seen 
>> good uses auto variables but declaring a class as auto forces all uses to 
>> be auto).
>
> I agree that the vast majority of class objects should be on the heap. But 
> why require it?

Make the most common use cases easy and the rest reasonable and you'll have 
happy users. Conceptual baggage from other languages is a concern but it can 
be handled through documentation and examples comparing one to the other.

> BTW, similar to this is the problem that you can't have a global class 
> object without having to initialize it in an init() function.
>
>>>4) Invited confusion over === and ==
>>
>> Agreed - though the current design isn't unreasonable in the big picture.
>
> :)
April 29, 2005
Re: Is D taking hold in the C++ world?
> Say that you want to store a pointer to a type in a template struct.  Do  
> you do this?
> 	struct RefTo(T) {
> 	  T reference;
> 	}
> which works for classes, or this
> 	struct RefTo(T) {
> 	  T *pointer;
> 	}
> which works for structs?  Sure, you can do specialized templates, but  
> that's a kludge to work around the problem, IMHO.

You declare this:

/// @brief Struct with reference.
///
/// Dear user. Please use only reference types
/// (objects or pointers) for T. Thank you.
///
struct RefTo(T)
{
  T reference;
}

And then this:

class Klasse { ... }
struct Struktur { ... }

RefTo!(Klasse) klasseRef;
RefTo!(Struktur*) strukturRef;

Does even have the same semantics:

klasseRef.store(new Klasse);
strukturRef.store(new Struktur);


Ciao
uwe
April 29, 2005
Re: Is D taking hold in the C++ world?
Ben Hinkle wrote:

> 
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message
> news:d4tgj7$usv$1@digitaldaemon.com...
>> Ben Hinkle wrote:
>>>>>MATLAB uses "." independent of value/reference semantics and it works
>>>>>fine. The difference between value/reference only shows up in
>>>>>assignment behavior (which is the definition of value/reference
>>>>>anyway). But then MATLAB also doesn't have pointers.
>>>>
>>>>IMHO, getting rid of -> and just using . was a good idea, but that is a
>>>>different question.
>>>>
>>>>I, like the others (it's nice to know I'm not alone) don't like the
>>>>current syntax.  I've stated before my beefs with it:
>>>>
>>>>1) Makes it hard to write a template that handles both struct pointers
>>>>and object references correctly.
>>>
>>> I'm not sure what you are referring to. Can you give a pointer to a post
>>> or examples?
>>
>> Say that you want to store a pointer to a type in a template struct.  Do
>> you do this?
>> struct RefTo(T) {
>>   T reference;
>> }
>> which works for classes, or this
>> struct RefTo(T) {
>>   T *pointer;
>> }
>> which works for structs?  Sure, you can do specialized templates, but
>> that's a kludge to work around the problem, IMHO.
> 
> When you said "template that handles struct pointer and objects refs" I
> thought you meant
>   struct RefTo(T) {
>    T bar;
>   }
>   RefTo!(Object) blah;
>   RefTo!(MyStruct*) blah2;
> The same template RefTo should be usable by anything with reference
> semantics (which both struct ptrs and object refs have). I agree sometimes
> you have to write two templates if you want to use it both with a type
> with value semantics and with a type with reference semantics. But that's
> only logical. For the particular case of "RefTo" I'm not sure what the
> point is but I'd say leave it as one template and make users explicitly
> take a reference to the structs since that's how structs in D behave -
> trying to make D structs act like they have reference semantics will
> result in confusing and clunky code IMO.
> 
>>>>2) Leads to a very common newbie error: segfault because he used an
>>>>uninitialized class reference.  (If we had used C++ syntax, then Java
>>>>programmers would have had a learning curve...but their error would be
>>>>caught at build time, not as a runtime error, which, IMHO, is far
>>>>superior)
>>>
>>> IMO better segv than slicing objects passed by value. Any non-trivial
>>> class hierarchy is destined to be manipulated by reference.
>>
>> I half agree and half disagree.  I think that Walter made a very good
>> point when he said that copy constructors are trouble; you are making a
>> similar point by saying that we don't want to pass objects by value.
>>
>> So why not just ban passing classes by value?  That is, the following
>> code would be illegal:
>> class Foo {};
>> int myFunc(Foo pass_by_value) {...}
>> it would give an error:
>> ERROR: Class objects cannot be passed by value.
>> They must be passed by pointer instead.
>>
>> Likewise, any code that required copying a class by value would be
>> illegal.  Offhand, I can think of:
>> * Class values as function parameters
>> * Class values as function return values
>> * Direct object assignments
> 
> That is an option but I think it would be one of last resort. A type
> should be usable by itself - if taking pointers to something is required
> in order to make it useful then that should be built into the type. Also
> by building reference semantics into object you avoid silly typedefs like
> typedef Window_t* Window;
> I dislike C/C++ code that hides pointers behind typedefs. The typedef only
> becomes usable when it has some obvious naming convention like WindowRef
> and at that point WindowRef is pretty much the same as Window_t* so why
> bother.
> 
>>>>3) Made it so that class objects can't be on the stack.  Let's be
>>>>honest, here, the whole reason that we have 'auto' is a kludge to get
>>>>around the syntax problem.
>>>
>>> I'm with Walter (and Java/C#) that class objects on the stack should be
>>> rare. If there are issues with structs that require lots of auto classes
>>> then structs need attention. Actually auto classes don't have anything
>>> to do with being on the stack - they just force the dtor to be called on
>>> scope exit. IMO I haven't seen a D class that should be auto (I've seen
>>> good uses auto variables but declaring a class as auto forces all uses
>>> to be auto).
>>
>> I agree that the vast majority of class objects should be on the heap.
>> But why require it?
> 
> Make the most common use cases easy and the rest reasonable and you'll 
> have happy users.
Right. But language also must avoid dangerous cases and possibilities to
make hard-to-find bugs. This is why constructions like if(x=y) does not
allowed in D. In my opinion reference/value ambiguous introduces such
cases.
One can use RefTo!(MyStruct) by mistake - compiler will say nothing.
One can try to pass class for template designed for value-types - compiler
will say nothing.
One can forget about COW technology - compiler will say nothing.
(BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
C++ this is easy).
Just imagine how many work must be done to convert existing struct into
class or vise versa. And compiler will never help here.

> Conceptual baggage from other languages is a concern but 
> it can be handled through documentation and examples comparing one to the
> other.
Absolutely agree.

> 
>> BTW, similar to this is the problem that you can't have a global class
>> object without having to initialize it in an init() function.
>>
>>>>4) Invited confusion over === and ==
>>>
>>> Agreed - though the current design isn't unreasonable in the big
>>> picture.
>>
>> :)

-- 
         Vladimir
April 29, 2005
Re: Is D taking hold in the C++ world?
>>> I agree that the vast majority of class objects should be on the heap.
>>> But why require it?
>>
>> Make the most common use cases easy and the rest reasonable and you'll
>> have happy users.
> Right. But language also must avoid dangerous cases and possibilities to
> make hard-to-find bugs. This is why constructions like if(x=y) does not
> allowed in D. In my opinion reference/value ambiguous introduces such
> cases.

Sure that's legit opinion to have, but one has to weigh the upsides vs the 
downsides and on Walter's balance the upsides outweigh the downsides. Other 
people will use different weights and considerations and have different 
conclusions.

> One can use RefTo!(MyStruct) by mistake - compiler will say nothing.
> One can try to pass class for template designed for value-types - compiler
> will say nothing.

It will say nothing if the template makes sense - it depends on the 
template. Some would say it's a feature to allow templates to take any type 
and as long as it compiles it is ok. Restricting template parameters allows 
more control if the template author wishes.

> One can forget about COW technology - compiler will say nothing.

It's a trade-off, that's true. Sometimes you want COW and sometimes you 
don't.

> (BTW, can one write a transparent COW wrapper for dynamic arrays in D ? In
> C++ this is easy).

I assume you are referring to the lack of overloadable assignment to keep 
track of reference counts, corrent? To me that's a slightly different issue 
than reference/value semantics. Besides with dynamic arrays sometimes one 
wants to explicitly not use COW (eg filling in a buffer supplied to a 
function). Will D someday get some sort of overloadable assignment? Who 
knows - I personally don't have a strong argument against it but then again 
I don't miss it.

> Just imagine how many work must be done to convert existing struct into
> class or vise versa. And compiler will never help here.

I'm not sure what you mean here. Do you mean convert an existing C++ 
struct/class to D? Or do you mean a D struct that later becomes a class? 
I've found it's very easy to replace things like MyStruct* with MyClass or 
vice versa. Anything that uses MyStruct with value semantics needs attention 
when converted to using reference semantics but that's to be expected since 
that's pretty much the whole points of structs vs classes.
April 29, 2005
Re: Is D taking hold in the C++ world?
"Kyle Furlong" <ky220@umail.ucsb.edu> wrote in message
news:d4sr93$1ik8$2@digitaldaemon.com...
> Are you willing to let someone redesign the D website, Walter?

If someone is willing to do a front page, I'm open minded about adopting it.
It needs to have the following characteristics, though:

1) no javascript, no flash, no ActiveX, no Java, no scripts, etc. The page
should work for those who have all that stuff turned off for security
reasons.
2) be search engine friendly
3) be accessible to those who use text-to-speech programs (this and (2) are
flip sides of the same coin)
4) not be fixed size - meaning it should work on small screens as well as
large ones
5) not use fixed font sizes. Visually impaired people should be able to make
the fonts bigger.
6) load fast. This means no large graphics files.
7) be hand-edittable.
April 29, 2005
Re: Is D taking hold in the C++ world?
"Uwe Salomon" <post@uwesalomon.de> wrote in message
news:op.spz368oi6yjbe6@sandmann.maerchenwald.net...
> You declare this:
>
> /// @brief Struct with reference.
> ///
> /// Dear user. Please use only reference types
> /// (objects or pointers) for T. Thank you.
> ///
> struct RefTo(T)
> {
>    T reference;
> }

You can build that restriction into the template!

struct RefTo(T:Object)
{
   T reference;
}

struct RefTo(T: T*)
{
   T* reference;
}

   RefTo!(int *) X;    // works
   RefTo!(int) Y;    // fails
April 29, 2005
Re: Is D taking hold in the C++ world?
Walter wrote:

> 
> "Vladimir" <kv11111@mail.ru> wrote in message
> news:d4qvmu$114p$2@digitaldaemon.com...
>> Matthias Becker wrote:
>>
>> > Bad library, not even the basic collections you find everywhere. So D
>> > is unusable in any kind of project.
>> >
>> >
>> > A few C++ programmers see things like built in hash-tables and ask why
> the
>> > languages is bloated with stuff like that, which could be done in the
>> > library and then don't even give it a try.
>> That was my first feeling after reading intro on digitalmars site.
> Benefits
>> described here seems not convincingly for me.
> 
> The text can always be improved. What would be a convincing intro be for
> you?


First informative link from front page is a link to comparation table. First
look at this table shows that D has more features than others. But more
detailed look shows that many of this features are not missing in other
languages but raser implemented as libraries. Reasons for doing it in
compiler are not described here.

It's not obvious that moving a big part of library into compiler is good.
Many people even convinced that this is evil, and have a reasons for it.
So, if doing so, *very* *good* description of it's benefits must be written
and placed just beside saying thad D has built-in dynamic and assosiative
arrays. Without it a lot of C/C++ programmers just stop reading here.

The most confusing section is about arrays. Reading page "D Strings vs C++
Strings" which is linked from here one can agree
that C++ STL library is far from ideal, and some changes to compiler (such
as adding overloadable ~ operator) are also helpful, but there is no reason
to built-in library into compiler.
As for me, more convincing points is possible optimizations, more standard
implementation (no more difference between STL string, QT QString, and many
others), reference semantics, but these all are at the bottom of the page.

Absence of "How Garbage Collection Works" part is also bad. For many C/C++
programmers GC is associated with java/C# and VMs which are slow. Section
"How Garbage Collection Works" is the only chance to be convinces that this
really can be not-so-slow (especially for those who does not belive
advertisements). May be adding this link:
http://www.iecc.com/gclist/GC-faq.html
and even this:
ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
would be helpful.


-- 
         Vladimir
April 29, 2005
Re: Is D taking hold in the C++ world?
Vladimir wrote:
> Walter wrote:
...

>>The text can always be improved. What would be a convincing intro be for
>>you?
> 
> 
> 
> First informative link from front page is a link to comparation table. First
> look at this table shows that D has more features than others. But more
> detailed look shows that many of this features are not missing in other
> languages but raser implemented as libraries. Reasons for doing it in
> compiler are not described here.

Listen, he admits in the first paragraph he's counting what's available 
in each language. Most people expect that the items in such a comparison 
list are going to be selected to favor the language being endorsed.

Also, if someone has to be told that it might be a lot cooler to have a 
feature built-in as opposed to hacked-in, they may not be a programmer.

I believe much of this has already been discussed to death back while 
Walter first released the comparison chart.

...

> The most confusing section is about arrays. Reading page "D Strings vs C++
> Strings" which is linked from here one can agree
> that C++ STL library is far from ideal, and some changes to compiler (such
> as adding overloadable ~ operator) are also helpful, but there is no reason
> to built-in library into compiler.
> As for me, more convincing points is possible optimizations, more standard
> implementation (no more difference between STL string, QT QString, and many
> others), reference semantics, but these all are at the bottom of the page.
> 


> Absence of "How Garbage Collection Works" part is also bad. For many C/C++

Ah, the " To be written..." section on the garbage collection page 
(http://www.digitalmars.com/d/garbage.html). You're right -- it should 
either be filled in or dropped. If I had seen that before I forgot about it.

> programmers GC is associated with java/C# and VMs which are slow. Section
> "How Garbage Collection Works" is the only chance to be convinces that this
> really can be not-so-slow (especially for those who does not belive
> advertisements). May be adding this link:
> http://www.iecc.com/gclist/GC-faq.html
> and even this:
> ftp://ftp.cs.utexas.edu/pub/garbage/gcsurvey.ps
> would be helpful.

I think part of the animosity against GC is religious in nature and the 
only solution for such a problem is prayer by those who are adherents of 
the "one true religion". At least Microsoft is on our side now with GC. 
Every time one of their acolytes extols the virtue of "managed code" 
they're endorsing D. Here's a new slogan for D: "Get the nearly the same 
memory leak protection without requiring users to download the large 
.NET  framework." ;)


-- 
jcc7
http://jcc_7.tripod.com/d/
2 3 4 5 6 7 8 9 10
Top | Discussion index | About this forum | D home