10-Apr-2014 16:22, Daniel Murphy пишет:
> "Dmitry Olshansky"  wrote in message news:li5lfd$203s$1@digitalmars.com...
>> Pros:
>>
>> 1. No extra scuffolding for CTFE.
>> 2. Type-safe
>> 3. Optional (non-release, etc.) bounds-checking.
>> 4. Less error prone interface, e.g. memset is a known source of bugs
>> in C, even for tried and true code bases.
>> 5. More flexible, see e.g. memchr as an example.
>>
>> Cons:
>> A set of primitives to learn.
>
> I don't know why you'd ever use memcpy/memset when you have:
>
> arr[] = 0;

Calls postblit/dtor etc.? What I if I need bitwise assignment? (which is what memcpy is all about)
Yes, and with CTFE please.
See even std.algo.move and std.algo.swap...

> foreach(ref v; arr)
>     v = 0;

Same but also sucks performance-wise.
There is a reason Phobos is littered with carefully laid out special cases around C-runtime stuff.



-- 
Dmitry Olshansky

On Thu, 10 Apr 2014 16:13:31 -0400, Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:

> 10-Apr-2014 16:22, Daniel Murphy пишет:
>> "Dmitry Olshansky"  wrote in message news:li5lfd$203s$1@digitalmars.com...
>>> Pros:
>>>
>>> 1. No extra scuffolding for CTFE.
>>> 2. Type-safe
>>> 3. Optional (non-release, etc.) bounds-checking.
>>> 4. Less error prone interface, e.g. memset is a known source of bugs
>>> in C, even for tried and true code bases.
>>> 5. More flexible, see e.g. memchr as an example.
>>>
>>> Cons:
>>> A set of primitives to learn.
>>
>> I don't know why you'd ever use memcpy/memset when you have:
>>
>> arr[] = 0;
>
> Calls postblit/dtor etc.? What I if I need bitwise assignment? (which is what memcpy is all about)
> Yes, and with CTFE please.
> See even std.algo.move and std.algo.swap...
>
>> foreach(ref v; arr)
>>     v = 0;
>
> Same but also sucks performance-wise.
> There is a reason Phobos is littered with carefully laid out special cases around C-runtime stuff.

I think a simple set of functions would be sufficient. It wouldn't even be that complex.

core.memops

-Steve

On Wednesday, 9 April 2014 at 12:38:20 UTC, monarch_dodra wrote:
> On Wednesday, 9 April 2014 at 12:12:35 UTC, Mike wrote:
>> On Wednesday, 9 April 2014 at 11:50:13 UTC, Daniel Murphy wrote:
>>> "Mike"  wrote in message news:iflykgpsrmdbfhuwzqtp@forum.dlang.org...
>>>
>>>> So, my question remains:  If I'm porting D to a platform that has no C library, shouldn't a public, supported function that copies memory be added in the D Runtime?
>>>
>>> What platform doesn't have a C library?  And you can always cast arrays to ubyte[] before assigning to avoid postblit.
>>
>> My custom, bare-metal, D-only platform has no C library, nor will it ever.  And, Yes, I know I can cast, but should I?
>>
>> memcpy is used quite often in Phobos.  Here's a small sample from std.array:
>>
>> void trustedMemcopy(T[] dest, T[] src) @trusted
>> {
>>    assert(src.length == dest.length);
>>    if (!__ctfe)
>>        memcpy(dest.ptr, src.ptr, src.length * T.sizeof);
>>    else
>>    {
>>        dest[] = src[];
>>    }
>> }
>>
>> You could ask the same question there, "Why isn't a cast used instead?" and remove the dependency on the C library.
>>
>> So far, it seems D has only been used on one subset of computer systems that happen to have a C library, but some of us our trying to break some new ground with D.  I'm challenging the "D is only useful on PCs with a C library" bias and looking to see if D has the will to stand on its own two feet instead of leaning on C.
>
> I think arguably, there should be D equivalents of the C runtime functions, if only for the added safety of slices (for example, memchr could be 100% certifiably safe), and to avoid the rampant deduplication of things as in the above, because of CTFE.
>
> These may or may not use the C-runtime library. But at that point, it would become a "druntime implementation detail", rather than rampant usage throughout phobos.

This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation:

http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist

On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote:
> This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation:
>
> http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist

Oops, broken link.

http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx

On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote:
> This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation:
>
> http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist

I just wrote this as a rough draft. I'll make "formal" announcement for it sometime soon, if initial feedback is positive.

http://wiki.dlang.org/DIP59

On Friday, 11 April 2014 at 20:25:21 UTC, monarch_dodra wrote:
> On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote:
>> This list of secure alternatives to C functions Microsoft has would probably be a good source of inspiration when deciding what functions should be considered for reimplementation:
>>
>> http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist
>
> I just wrote this as a rough draft. I'll make "formal" announcement for it sometime soon, if initial feedback is positive.
>
> http://wiki.dlang.org/DIP59

I know :). We #d IRC users see all! (Vladimir Panteleev's DFeed bot announces basically everything going on everywhere in D).

12-Apr-2014 00:25, monarch_dodra пишет:
> On Friday, 11 April 2014 at 20:17:35 UTC, Brad Anderson wrote:
>> This list of secure alternatives to C functions Microsoft has would
>> probably be a good source of inspiration when deciding what functions
>> should be considered for reimplementation:
>>
>> http://msdn.microsoft.com/en-us/library/wd3wzwts.aspx%7C%7Clist
>
> I just wrote this as a rough draft. I'll make "formal" announcement for
> it sometime soon, if initial feedback is positive.
>
> http://wiki.dlang.org/DIP59

Some thoughts.

Provide only bitwise comparison, search etc. It's the only case that can reliably benefit from SIMD or hand-written ASM, has problem with CTFE support, etc. Then requiring that T be a POD or built-in type is fine IMHO.

Maybe go for copy ---> rawCopy, find --> rawFind (i.e. model after std.algorithm) rather then mimicking C functions. This way we are open to a superset of C-runtime ;)



-- 
Dmitry Olshansky