eao197 wrote:
>  From my expirience this is a problem of C++ beginners.

I was talking to a person who is a C++ developer for a major game company just today. He told me that it is very difficult to find experienced C++ developers, hire them, or even recognize them in a job interview. When you are able to hire them, they cost plenty.

It's true that every problem with C++ can be solved by getting more advanced C++ programmers. The problem is getting those C++ programmers. And even the best ones have bad days and make mistakes <g>.

Defining a problem out of existence is preferable, cheaper, and more reliable than depending on convention or more training.

If I was paying top dollar for a programming expert, I'd rather he focused his energies on something more productive than dodging C++'s potholes.

If I was in charge of writing software that absolutely, positively must work correctly, I'll prefer a language guarantee over reliance that my programmers, no matter how good they are, didn't overlook something.

Bill Baxter wrote:
> Jason House wrote:
>> I was thinking recently of an interesting syntax twist...  Always require & when trying to get to an address, and use the raw variable name and "." to refer to whatever is pointed to.  Obtaining an address would require &.
>>
>> It's an interesting change, but would likely be too confusing to switch over.  Somehow I bet even suggesting the idea will mark me as a crack pot :)
> 
> Well realistically none of this is likely to change anyway, so you're free to suggest anything you want.  :-)
> I was thinking about something like that as well, though.  But couldn't really think how to make it useful.
> 
> My thinking was that in D we have classes sort of "shifted" by one from structs
> 
>         pointer-to-pointer   pointer   value
> struct    &(&p)                &p        p
> struct*    &p                   p       *p
> class      &p                   p       N/A
> 
> So instead of that make structs default to pointers too, to shift everything back to be the same:
> 
>         pointer-to-pointer   pointer   value
> struct#       &(&p)            &p        p
> struct        &p                p       *p
> class         &p                p       N/A

I was thinking of something more consistent.

        pointer-to-pointer   pointer   value
struct         N/A             &p        p
struct*        &&p             &p        p
class          &&p             &p        p
T              ???             &p        p


simply doing p will always give the value and &p will always give a pointer.  How many &'s allowed would be specific to the circumstance/implementation.  In my naive view, the last valid pointer (&p for struct, &&p for struct*, etc...) would have to be const.  T above is supposed to be some kind of templated type

On Thu, 16 Aug 2007 13:20:28 +0400, Walter Bright <newshound1@digitalmars.com> wrote:

>>  From my expirience this is a problem of C++ beginners.
>
> I was talking to a person who is a C++ developer for a major game company just today. He told me that it is very difficult to find experienced C++ developers, hire them, or even recognize them in a job interview. When you are able to hire them, they cost plenty.
>
> It's true that every problem with C++ can be solved by getting more advanced C++ programmers. The problem is getting those C++ programmers. And even the best ones have bad days and make mistakes <g>.

I know.
But I know that getting experienced programmer is very hard for _any_ language. And they cost plenty.

> Defining a problem out of existence is preferable, cheaper, and more reliable than depending on convention or more training.
>
> If I was paying top dollar for a programming expert, I'd rather he focused his energies on something more productive than dodging C++'s potholes.
>
> If I was in charge of writing software that absolutely, positively must work correctly, I'll prefer a language guarantee over reliance that my programmers, no matter how good they are, didn't overlook something.

I'm totaly agree with you. This is why I'm interested in D, not in C++.
But in the case with value type/reference type separation there are some benefits and drawbacks in the current D version. So I think that 'slicing' is not an important argument in defense of such separation.

Because value/reference separation it is a fundamental feature of D so it is better to concentrate to minimization of value/reference/pointer conceptions. For example, what's about removing 'reference' at all? Lets D has only values and pointers:

int i; // value.
int * pi; // pointer to value.
struct S { ... }
S s; // value.
S * ps; // pointer to value.
class C { ... }
C c; // Error! Value type cannot be used as value.
C * c; // OK. Pointer to reference type.

void f( int i, S s, S * s, C * c ) { ... }

-- 
Regards,
Yauheni Akhotnikau

Walter Bright wrote:
> 
> I was talking to a person who is a C++ developer for a major game company just today. He told me that it is very difficult to find experienced C++ developers, hire them, or even recognize them in a job interview. When you are able to hire them, they cost plenty.

I can second this.

I'm a game developer, and I also happen to do most of the interviewing and hiring for my group.

C++ and entry-level (i.e. fresh out of college) is almost non-existent.   There's quite a bit of "java syndrome" going on out there. Experienced C++ game devs are indeed expensive.

And also, *'s suck.  Please don't infect D with this.

--Steve

On Thu, 16 Aug 2007 21:04:23 +0400, eao197 <eao197@intervale.ru> wrote:

> class C { ... }
> C c; // Error! Value type cannot be used as value.
> C * c; // OK. Pointer to reference type.

Oops! Typo :((
Should be:

C c; // Error! Reference type cannot be used as value.

-- 
Regards,
Yauheni Akhotnikau

Jason House wrote:
> Bill Baxter wrote:
>> Jason House wrote:
>>> I was thinking recently of an interesting syntax twist...  Always require & when trying to get to an address, and use the raw variable name and "." to refer to whatever is pointed to.  Obtaining an address would require &.
>>>
>>> It's an interesting change, but would likely be too confusing to switch over.  Somehow I bet even suggesting the idea will mark me as a crack pot :)
>>
>> Well realistically none of this is likely to change anyway, so you're free to suggest anything you want.  :-)
>> I was thinking about something like that as well, though.  But couldn't really think how to make it useful.
>>
>> My thinking was that in D we have classes sort of "shifted" by one from structs
>>
>>         pointer-to-pointer   pointer   value
>> struct    &(&p)                &p        p
>> struct*    &p                   p       *p
>> class      &p                   p       N/A
>>
>> So instead of that make structs default to pointers too, to shift everything back to be the same:
>>
>>         pointer-to-pointer   pointer   value
>> struct#       &(&p)            &p        p
>> struct        &p                p       *p
>> class         &p                p       N/A
> 
> I was thinking of something more consistent.
> 
>         pointer-to-pointer   pointer   value
> struct         N/A             &p        p
> struct*        &&p             &p        p
> class          &&p             &p        p
> T              ???             &p        p

Oh, I see.  So you mean that no matter what, the compiler would figure out what dereferencing was necessary, and you always have to explicitly say whether you want a pointer or not.  Interesting.

So pointer math becomes pretty tedious for one.  Maybe that's ok.
And then what happens when you're given some T (which could be pointer to pointer to int, say) and you want dereference it one level further? And what about aliases?  If I have
alias int* intp;
alias int** intpp;
intp x;

Then x can simultaneously be described as int**, intp*, or intpp.

But why is struct pointer-to-pointer N/A.  Shouldn't the N/A be under 'value' for class?

--bb

Stephen Waits wrote:
> Walter Bright wrote:
>>
>> I was talking to a person who is a C++ developer for a major game company just today. He told me that it is very difficult to find experienced C++ developers, hire them, or even recognize them in a job interview. When you are able to hire them, they cost plenty.
> 
> I can second this.
> 
> I'm a game developer, and I also happen to do most of the interviewing and hiring for my group.
> 
> C++ and entry-level (i.e. fresh out of college) is almost non-existent.   There's quite a bit of "java syndrome" going on out there. Experienced C++ game devs are indeed expensive.

Right. One of the goals of D is to enable regular programmers to get better results. Programming ordinary apps shouldn't require the top tier programmers.

One reason Java, Ruby and VB are so popular is because this is true for them.


> And also, *'s suck.  Please don't infect D with this.

I'm happy to debate this as I feel it is important to explain why this design is the way it is, but don't worry, I feel very strongly that D's behavior here is the right thing.

eao197 wrote:
> I'm totaly agree with you. This is why I'm interested in D, not in C++.
> But in the case with value type/reference type separation there are some benefits and drawbacks in the current D version. So I think that 'slicing' is not an important argument in defense of such separation.
> 
> Because value/reference separation it is a fundamental feature of D so it is better to concentrate to minimization of value/reference/pointer conceptions. For example, what's about removing 'reference' at all? Lets D has only values and pointers:
> 
> int i; // value.
> int * pi; // pointer to value.
> struct S { ... }
> S s; // value.
> S * ps; // pointer to value.
> class C { ... }
> C c; // Error! Value type cannot be used as value.
> C * c; // OK. Pointer to reference type.
> 
> void f( int i, S s, S * s, C * c ) { ... }

But I think if one pulls on that string, one eventually winds up with how C++ does it, with all of the problems.

Walter Bright wrote:
> Stephen Waits wrote:
>> Walter Bright wrote:
>>>
>>> I was talking to a person who is a C++ developer for a major game company just today. He told me that it is very difficult to find experienced C++ developers, hire them, or even recognize them in a job interview. When you are able to hire them, they cost plenty.
>>
>> I can second this.
>>
>> I'm a game developer, and I also happen to do most of the interviewing and hiring for my group.
>>
>> C++ and entry-level (i.e. fresh out of college) is almost non-existent.   There's quite a bit of "java syndrome" going on out there. Experienced C++ game devs are indeed expensive.
> 
> Right. One of the goals of D is to enable regular programmers to get better results. Programming ordinary apps shouldn't require the top tier programmers.
> 
> One reason Java, Ruby and VB are so popular is because this is true for them.

amen

On Thu, 16 Aug 2007 22:36:53 +0400, Walter Bright <newshound1@digitalmars.com> wrote:

> eao197 wrote:
>> I'm totaly agree with you. This is why I'm interested in D, not in C++.
>> But in the case with value type/reference type separation there are some benefits and drawbacks in the current D version. So I think that 'slicing' is not an important argument in defense of such separation.
>>  Because value/reference separation it is a fundamental feature of D so it is better to concentrate to minimization of value/reference/pointer conceptions. For example, what's about removing 'reference' at all? Lets D has only values and pointers:
>>  int i; // value.
>> int * pi; // pointer to value.
>> struct S { ... }
>> S s; // value.
>> S * ps; // pointer to value.
>> class C { ... }
>> C c; // Error! Value type cannot be used as value.
>> C * c; // OK. Pointer to reference type.
>>  void f( int i, S s, S * s, C * c ) { ... }
>
> But I think if one pulls on that string, one eventually winds up with how C++ does it, with all of the problems.

(excuse me, but my poor English didn't allow me fully understand that. I could understand that you fear that such approach is too C++ish and it would lead to repeating typical C++ errors in D code)

I think such fear is a little strange for the language that already has pointer arithmetics and facilities like malloc/free/delete (and targeting to the same niches as C++).

But let to return to your goal: "Defining a problem out of existence is preferable, cheaper, and more reliable than depending on convention or more training." How about eluminating such problem as null pointers (I think it is much more common and dangerous problem than object slicing).

Some languages (Nice [1], Eiffel (in ECMA standard) [2], Spec# [3]) targeted this problem by 'non-null' references (pointers). For example, in Nice there are two kinds of reference declarations:

class C {}
C non_null = ...; // Can't be null.
C? nullable = ...; // Can be null.

void f( C non_null_arg ) { ... } // non_null_arg can't be null.

non_null = nullable; // Error! Checked by compiler.
f( nullable ); // Error! Checked by compiler.
nullable = non_null; // Ok.
f( non_null ); // Ok.
if( null != nullable )
  f( nullable ); // Ok. In this branch nullable is not null.

I think if there was only one reference/pointer type in D than it would be easier to add such non-null references into the language. For example, it is possible to use another symbol for pointers:

class C {};
C # non_null = ...; // Can't be null.
C * nullable = ...; // Can be null.

void f( C # non_null_arg ) { ... } // non_null_arg can't be null.

non_null = nullable; // Error! Checked by compiler.
f( nullable ); // Error! Checked by compiler.
nullable = non_null; // Ok.
f( non_null ); // Ok.
if( nullable !is null )
  f( nullable ); // Ok. In this branch nullable is not null.

It would be much cleaner (imho) than something like:

C nullable_ref = ...; // Reference, can be null.
C# non_null_ref = ...; // Non-null reference.
C * nullable_ptr = ...; // Pointer, can be null.
C# * non_null_ptr = ...; // Non-null pointer.


[1] http://nice.sf.net
[2] http://se.ethz.ch/~meyer/publications/lncs/attached.pdf
[3] http://research.microsoft.com/specsharp/papers/krml136.pdf

-- 
Regards,
Yauheni Akhotnikau