December 09, 2006
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
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
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
Thanks for this. But std.demangle seems to be broken now.
December 09, 2006
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
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
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
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
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
"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 :)