February 14, 2015
Foo:

> I'm regret that I tried to help, I will delete this repo as far as possible. :)

Language communities aren't perfect, but the success of a language comes from the help of many little hands :) Perhaps Rust will "win" over D in the end, but there's no reason to throw away your work just for a comment... be tolerant and be good.

Bye,
bearophile
February 14, 2015
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
> On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
>> This is something I've done recently.
>> Would be glad if my code will help you:
>> https://github.com/Dgame/m3
>> Especially the m3.d module could be useful for you.
>
> /* Class and Struct */
>
> emplace: You can't assume zero-initialization for structs.
> destruct: Is not memory-safe, and must not be marked @trusted.
>
> /* Array */
>
> make: You can't assume zero-initialization. T.sizeof is not the size of an element.
> reserve: Not safe (you're freeing the old memory), must not be @trusted.
> append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`.
> destruct: Not safe, must not be @trusted.

Low level memory management isn't easy.
Bugs like these wouldn't exist if D had decent smart pointer implementations in its standard library. You seem knowledgeable enough, care to lend a hand? ; )
February 14, 2015
On Fri, 13 Feb 2015 23:29:10 +0000, Foo wrote:

> Always the same in this newsgroup. You want to help as good as you can
> (even if it's not perfect) and all you get are subliminal messages... :)

code that you throwing at newcomer may not be perfect, but it at least should not be wrong. your code is obvious wrong, as anonymous said.

you may make your own question like "what is wrong with this code?". would you be glad to get the wrong answer?

anonymous is right: your code does more harm than good *as* *an* *answer*. but it seems that you don't care about the quality, "it works for me so it's good", yeah? 'cause if you *do* care, you're able to see why anonymous said what he's said.

February 14, 2015
On Sat, 14 Feb 2015 00:57:33 +0000, weaselcat wrote:

> On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
>> On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
>>> This is something I've done recently.
>>> Would be glad if my code will help you: https://github.com/Dgame/m3
>>> Especially the m3.d module could be useful for you.
>>
>> /* Class and Struct */
>>
>> emplace: You can't assume zero-initialization for structs. destruct: Is not memory-safe, and must not be marked @trusted.
>>
>> /* Array */
>>
>> make: You can't assume zero-initialization. T.sizeof is not the size of
>> an element.
>> reserve: Not safe (you're freeing the old memory), must not be
>> @trusted.
>> append: T.sizeof is not the size of an element. You're multiplying
>> twice with T.sizeof; in `append`, and also in `reserve`.
>> destruct: Not safe, must not be @trusted.
> 
> Low level memory management isn't easy.
> Bugs like these wouldn't exist if D had decent smart pointer
> implementations in its standard library. You seem knowledgeable enough,
> care to lend a hand? ; )

how "smart pointers" can help here? they don't magically hiding all the low-level mechanics.

February 14, 2015
On Saturday, 14 February 2015 at 06:38:19 UTC, ketmar wrote:
> On Sat, 14 Feb 2015 00:57:33 +0000, weaselcat wrote:
>
>> On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
>>> On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
>>>> This is something I've done recently.
>>>> Would be glad if my code will help you: https://github.com/Dgame/m3
>>>> Especially the m3.d module could be useful for you.
>>>
>>> /* Class and Struct */
>>>
>>> emplace: You can't assume zero-initialization for structs. destruct: Is
>>> not memory-safe, and must not be marked @trusted.
>>>
>>> /* Array */
>>>
>>> make: You can't assume zero-initialization. T.sizeof is not the size of
>>> an element.
>>> reserve: Not safe (you're freeing the old memory), must not be
>>> @trusted.
>>> append: T.sizeof is not the size of an element. You're multiplying
>>> twice with T.sizeof; in `append`, and also in `reserve`.
>>> destruct: Not safe, must not be @trusted.
>> 
>> Low level memory management isn't easy.
>> Bugs like these wouldn't exist if D had decent smart pointer
>> implementations in its standard library. You seem knowledgeable enough,
>> care to lend a hand? ; )
>
> how "smart pointers" can help here? they don't magically hiding all the
> low-level mechanics.

The file he was referring to was a smart pointer implementation.
February 14, 2015
On Sat, 14 Feb 2015 07:59:51 +0000, weaselcat wrote:

>> how "smart pointers" can help here? they don't magically hiding all the low-level mechanics.
> 
> The file he was referring to was a smart pointer implementation.

*one* of the files.

February 16, 2015
Hi,

you can also take a look at my implementation:

https://github.com/Ingrater/druntime/blob/master/src/core/allocator.d

Look at AllocatorNew and AllocatorDelete

Especially important is, that you correctly handle the constructor throwing an exception. You have to catch that exception in your new function, release the memory and rethrow.

Kind Regards
Benjamin Thaut
February 21, 2015
On Friday, 13 February 2015 at 22:55:27 UTC, anonymous wrote:
> On Thursday, 12 February 2015 at 23:52:41 UTC, Foo wrote:
>> This is something I've done recently.
>> Would be glad if my code will help you:
>> https://github.com/Dgame/m3
>> Especially the m3.d module could be useful for you.
>
> /* Class and Struct */
>
> emplace: You can't assume zero-initialization for structs.
> destruct: Is not memory-safe, and must not be marked @trusted.
>
> /* Array */
>
> make: You can't assume zero-initialization. T.sizeof is not the size of an element.
> reserve: Not safe (you're freeing the old memory), must not be @trusted.
> append: T.sizeof is not the size of an element. You're multiplying twice with T.sizeof; in `append`, and also in `reserve`.
> destruct: Not safe, must not be @trusted.

Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct?
February 21, 2015
On Saturday, 21 February 2015 at 13:41:41 UTC, Foo wrote:
> Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct?

Nice. I think you fixed everything I had pointed out.
February 21, 2015
On Saturday, 21 February 2015 at 14:39:47 UTC, anonymous wrote:
> On Saturday, 21 February 2015 at 13:41:41 UTC, Foo wrote:
>> Finally, I tried to take your criticism objectively and, as far as I can tell, I resolved the issues. Is there still any objections or misconduct?
>
> Nice. I think you fixed everything I had pointed out.

Yeah, I hope so too. Sorry for my annoyed behaviour, that wasn't my week and you where the the straw to break the camel's back. ;)

I hope I have the phrase translated correctly. :D
1 2
Next ›   Last »