View mode: basic / threaded / horizontal-split · Log in · Help
December 09, 2006
Re: DMD 0.177 release
"JohnC" <johnch_atms@hotmail.com> wrote in message 
news:elef3s$30jn$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote in message 
> news:ele2k9$2hr5$1@digitaldaemon.com...
>> More ABI changes, and implicit [] => * no longer allowed.
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>> http://ftp.digitalmars.com/dmd.175.zip
>
> opAssign is new as well, but it throws an AV - unless I'm not using it 
> right?
>
> class Test {
>
>  int value;
>
>  void opAssign(int value) {
>    this.value = value;
>  }
>
> }
>
> void main() {
>  Test t = 10;
> }


Take that back. Actually, it does work:

Test t = new Test;
t = 10;

Sadly it doesn't like a struct as the lvalue. There are no examples in the 
docs, so how it's supposed to be used is anyone's guess...
December 09, 2006
Re: DMD 0.177 release
JohnC wrote:
 > opAssign is new as well, but it throws an AV - unless I'm not using it
> right?
> 
> class Test {
> 
>   int value;
> 
>   void opAssign(int value) {
>     this.value = value;
>   }
> 
> }
> 
> void main() {
>   Test t = 10;
> } 
> 

This works:

void main() {
   Test t = new Test;
   t = 10;
}

I'm surprised this overload is in, as I thought it was considered 
dangerous. Not that I'm complaining btw!
December 09, 2006
Re: DMD 0.177 release
== Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
> "# Casting a value v to a struct S is now rewritten as S(v).
> # Initializing a struct S from a value v is now rewritten as S(v)."
> It took me a moment to realise what you meant by this.

Can you please enlighten the rest of us too?
December 09, 2006
Re: DMD 0.177 release
Boris Kolar wrote:

> == Quote from Stewart Gordon (smjg_1998@yahoo.com)'s article
>> "# Casting a value v to a struct S is now rewritten as S(v).
>> # Initializing a struct S from a value v is now rewritten as S(v)."
>> It took me a moment to realise what you meant by this.
> 
> Can you please enlighten the rest of us too?

S(v) ==> S.opCall(v), that is calling the static opCall of struct S with v
as an argument.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
December 09, 2006
Re: DMD 0.177 release
Pretty cool stuff.

Suggestion:

Allow static opAssign to return an instance of the class that will be  
assigned to the lvalue:
   class MyClass
   {
      this(int x) { }
      static MyClass opAssign(int x)
      {
         return new MyClass(x);
      }
   }
   // ...
   MyClass mc;
   mc = 3; // keeps mc null.

It seems logical to implement this proposal because to get the desired  
effect right now you could do:
   mc = mc = 3;
December 09, 2006
Re: DMD 0.177 release
char* p = new char[32];

Error: cannot implicitly convert expression (new char[](32)) of type  
char[] to char*

Should this be a special case? Currently it needs  (new char[32]).ptr
December 09, 2006
Re: DMD 0.177 release
- Casting a value v to a struct S is now rewritten as S(v).

I'm 100% against this. This is what C++ does, and it conflates 
construction and casting; with some VERY simple examples (such as the 
first one we think of when we think of additional types, bignums), 
there's an ambiguous conflict because one of the constructors should 
have a count of how many digits you want - and one of the casters takes 
an integer for a value to initialise to. My solution at the time was to 
add a dummy argument to the constructor so that the compiler didn't try 
to match them, which is absurd.

I don't know why C++ was designed like this when its error was so 
blatant, but D doesn't need to replicate its mistake. "S.opCastFrom (v)" 
please, except that it shouldn't be static either.
December 09, 2006
Re: DMD 0.177 release
char *newCharz( uint size ) {
	return (new char [size]).ptr;
}

char *p = newCharz(32);

:P

I like the explicity.

Chris Miller wrote:
> 
> char* p = new char[32];
> 
> Error: cannot implicitly convert expression (new char[](32)) of type 
> char[] to char*
> 
> Should this be a special case? Currently it needs  (new char[32]).ptr
December 09, 2006
Re: DMD 0.177 release
On Sat, 09 Dec 2006 11:33:17 -0500, Alexander Panek  
<a.panek@brainsware.org> wrote:

> char *newCharz( uint size ) {
> 	return (new char [size]).ptr;
> }
>
> char *p = newCharz(32);
>
> :P
>
> I like the explicity.

Well, I'm not sure what it should be, but you already made a mistake: it  
should be size_t instead of uint ;)

Plus, I never said it was a zero-terminated string.

>
> Chris Miller wrote:
>>  char* p = new char[32];
>>  Error: cannot implicitly convert expression (new char[](32)) of type  
>> char[] to char*
>>  Should this be a special case? Currently it needs  (new char[32]).ptr
December 09, 2006
Re: DMD 0.177 release
Chris Miller wrote:
> On Sat, 09 Dec 2006 11:33:17 -0500, Alexander Panek 
> <a.panek@brainsware.org> wrote:
> 
>> char *newCharz( uint size ) {
>>     return (new char [size]).ptr;
>> }
>>
>> char *p = newCharz(32);
>>
>> :P
>>
>> I like the explicity.
> 
> Well, I'm not sure what it should be, but you already made a mistake: it 
> should be size_t instead of uint ;)
> 
> Plus, I never said it was a zero-terminated string.

Oi. Sorry:

char * toChars( size_t size ) {
	return (new char[size]).ptr;
}

char * toCharz( size_t size ) {
	return (new char[size + 1]).ptr;
}

Better? :P
> 
>>
>> Chris Miller wrote:
>>>  char* p = new char[32];
>>>  Error: cannot implicitly convert expression (new char[](32)) of type 
>>> char[] to char*
>>>  Should this be a special case? Currently it needs  (new char[32]).ptr
>
1 2 3 4 5 6
Top | Discussion index | About this forum | D home