View mode: basic / threaded / horizontal-split · Log in · Help
December 09, 2006
Re: DMD 0.177 release
Those are newCharz and newChars, of course.

Apart from that, this might be interesting, too:

// alias thingie array;

template Ptr (T) {
	// Create a simple thingie
	T *newPtrs ( size_t size ) {
		return (new T[size]).ptr;
	}

	// Create null-terminated thingie
	T *newPtrz ( size_t size ) {
		T *p = (new T[size + 1]).ptr
		p[$ - 1] = '\0';

		return p;
	}
}

alias Ptr!(char).newPtrs newChars;
alias Ptr!(char).newPtrz newCharz;

Not tested, but this might be useful for someone.

Alexander Panek wrote:
> 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
>>
December 09, 2006
Re: DMD 0.177 release
On Sat, 09 Dec 2006 11:53:07 -0500, Alexander Panek  
<a.panek@brainsware.org> wrote:

> Those are newCharz and newChars, of course.
>
> Apart from that, this might be interesting, too:
>
> // alias thingie array;
>
> template Ptr (T) {
> 	// Create a simple thingie
> 	T *newPtrs ( size_t size ) {
> 		return (new T[size]).ptr;
> 	}
>
> 	// Create null-terminated thingie
> 	T *newPtrz ( size_t size ) {
> 		T *p = (new T[size + 1]).ptr
> 		p[$ - 1] = '\0';
>
> 		return p;
> 	}
> }
>
> alias Ptr!(char).newPtrs newChars;
> alias Ptr!(char).newPtrz newCharz;
>
> Not tested, but this might be useful for someone.
>

Not bad, perhaps needs better names though. newChars still sounds like new  
char[] (array). Maybe allocptr/ptrAlloc/ptralloc/palloc to have a similar  
name as malloc since they have similarities (working with pointers).   
*shrug*
December 09, 2006
Re: DMD 0.177 release
On Sat, 09 Dec 2006 02:20:00 -0800, Walter Bright  
<newshound@digitalmars.com> wrote:

> More ABI changes, and implicit [] => * no longer allowed.
>
> http://www.digitalmars.com/d/changelog.html
>
> http://ftp.digitalmars.com/dmd.175.zip


um... but this is the link for dmd.175.zip again, not 177.


-JJR
December 09, 2006
Re: DMD 0.177 release
Thanks for this. But std.demangle seems to be broken now.
December 09, 2006
Re: DMD 0.177 release
Walter in dmd v0.176 you improved name mangling, but I've found one very 
confusing change...is it your intension to reuse the "b" which used to mean 
"bit," to now mean a "bool" instead of "x?"

For example, one function "real vdb(real, real, real, real, real, real, bool 
= false)" used in my financial D dll,
before dmd v0.148 was released when the "bool" data type was added 
(replacing the "bit" data type) the function's mangled name was 
"D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the "bit" 
data type become an alias to bool and all the "b" (for "bit") were replaced 
with "x" (for "bool"), thus the funtion's mangled name changed to become 
"D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has been 
replaced by "b," is this a mistake on your part, or have you decided to use 
a "b" as meaning a "bool" (discarding "x")?

So currently the "vdb()" funtion under dmd v0.177 has returned to the old 
mangled name "D13financial_dll3vdbFeeeeeebZe," as if a "bool" has become a 
"bit" again.

Thanks again for all the great work you've been putting into D year after 
year!

David L.
-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"
-------------------------------------------------------------------

MKoD: http://spottedtiger.tripod.com/D_Language/D_Main_XP.html
"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
December 09, 2006
Re: DMD 0.177 release
Burton Radons wrote:
> - 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.

Essentially agreed.  I'm not entirely fond of the "silent" new opAssign either, because of 
the visual ambiguity it can lead to.  (Its worth noting that, even though '='->opAssign is 
listed in the spec, the bottom of the same page still lists '=' among the operators which 
will not be given overloads.  Hm.)

-- Chris Nicholson-Sauls
December 09, 2006
Re: DMD 0.177 release
Chris Miller wrote:
> Allow static opAssign to return an instance of the class that will be 
> assigned to the lvalue:

This wasn't done because there are several use cases where you wouldn't 
want to erase all previous contents of the struct being assigned to.
December 09, 2006
Re: DMD 0.177 release
On Sat, 09 Dec 2006 13:59:24 -0500, Walter Bright  
<newshound@digitalmars.com> wrote:

> Chris Miller wrote:
>> Allow static opAssign to return an instance of the class that will be  
>> assigned to the lvalue:
>
> This wasn't done because there are several use cases where you wouldn't  
> want to erase all previous contents of the struct being assigned to.

But if it's optional it's up to the struct writer to use void as the  
return or not.
December 09, 2006
Re: DMD 0.177 release
David L. Davis wrote:
> Walter in dmd v0.176 you improved name mangling, but I've found one very 
> confusing change...is it your intension to reuse the "b" which used to mean 
> "bit," to now mean a "bool" instead of "x?"

That's what people asked for.

> For example, one function "real vdb(real, real, real, real, real, real, bool 
> = false)" used in my financial D dll,
> before dmd v0.148 was released when the "bool" data type was added 
> (replacing the "bit" data type) the function's mangled name was 
> "D13financial_dll3vdbFeeeeeebZe". And with dmd v0.148 and later, the "bit" 
> data type become an alias to bool and all the "b" (for "bit") were replaced 
> with "x" (for "bool"), thus the funtion's mangled name changed to become 
> "D13financial_dll3vdbFeeeeeexZe". But now it looks like "x" has been 
> replaced by "b," is this a mistake on your part, or have you decided to use 
> a "b" as meaning a "bool" (discarding "x")?

That's correct.

> So currently the "vdb()" funtion under dmd v0.177 has returned to the old 
> mangled name "D13financial_dll3vdbFeeeeeebZe," as if a "bool" has become a 
> "bit" again.

Yes. There's no going back to bit.

> Thanks again for all the great work you've been putting into D year after 
> year!

You're most welcome.
December 09, 2006
Re: DMD 0.177 release
"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

No offense, but would it honestly kill you to allow ctors in structs?  We've 
been using static opCall as a _workaround_ for the lack of struct ctors, and 
making it part of the language doesn't really seem to be addressing the 
problem.  That, and it doesn't make any sense that classes use "this()" and 
structs use "static S opCall()".  We're starting to get into "overloading 
indexing in C++" territory.

That, and which would be more efficient?  The static opCall needs to return 
an instance of the struct on the stack, which could be very inefficient for 
large structs.  With a true ctor, the struct is passed by reference to the 
ctor and has its fields set directly.

And I also can't figure out how to make the implicit opCall work with more 
than one parameter.  :P

I'm also a little wary about opAssign.  Not that I don't find it useful, 
just that you've been vehemently opposed to overloading it in D for how many 
years, and three weeks before 1.0 you reverse your opinion.  What does that 
mean?

But complaints aside, thanks for removing the []=>* implicit cast and the 
bugfixes.  Man, this last month has been an exciting time for D :)
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home