I didn't know exactly how unit tests are performed for private
functions, so in the end I decided to not make any for them (though
I would). Contribution is public domain to be included in the
lib. Tell me if it will go in or no, or you want to make changes.

I couldn't persuade ddoc to generate two examples. Putting the dashed line between the two seems to be understood as "end of examples", which discards the second example as preformatted and highlighted text.  It would be better for html formatting with CSS if the separator could be specified between both, since each example could be boxed individually.

With this function now it would be possible to use -Dd~/something and have it work as expected.

Grzegorz Adam Hankiewicz wrote:
> I didn't know exactly how unit tests are performed for private
> functions, so in the end I decided to not make any for them (though
> I would). Contribution is public domain to be included in the
> lib. Tell me if it will go in or no, or you want to make changes.
> 
> I couldn't persuade ddoc to generate two examples. Putting the
> dashed line between the two seems to be understood as "end of
> examples", which discards the second example as preformatted and
> highlighted text.  It would be better for html formatting with
> CSS if the separator could be specified between both, since each
> example could be boxed individually.
> 
> With this function now it would be possible to use -Dd~/something
> and have it work as expected.

certainly no offense intended, but wouldn't it be easier to eliminate the extra step and just attach the revised file? instead of posting diffs (and whatever the other one is.. CVS diff I think). as a user I'd just like to see the code you wrote.

Chris

The Mon, 09 Jan 2006 12:21:01 -0700, Chris Lajoie wrote:
> certainly no offense intended, but wouldn't it be easier to eliminate the extra step and just attach the revised file?

Diffs are to make Walter's job easier. Besides, I've just seen the new .143 release, and it's there so you can try now yourself.

Walter, I would like you to explain the change you did to combineCPathWithDPath. There you have:

    // Create our own copy, as lifetime of c_path is undocumented
    char[] cp = c_path[0 .. end].dup;

    // Do we append something from path?
    if (char_pos < path.length)
        cp ~= path[char_pos .. length];

    return cp;

I don't understand your comment about the lifetime of c_path. Is it because it's a char instead of const char?  AFAICS, in both cases the char comes from memory which won't go away, or will it?

And then, there's not much lifetime either for combineCPathWithDPath. Wouldn't it be the same to rewrite that block as:

    // Do we append something from path?
    if (char_pos < path.length)
        return c_path[0 .. end] ~ path[char_pos .. length];
    else
        return c_path[0 .. end].dup;

Is (should be?) any of the blocks more optimal in terms of internal memory copies? Will the compiler optimise the second block better because the duplication of c_path happens in the same statement where the appending of path?

What would be the best way to find out with the compiler? How would
I find out what asm is being produced? Even if I don't know asm,
I would expect the optimal block to be shorter, right?

"Grzegorz Adam Hankiewicz" <gradhafakedontuse@ya.com> wrote in message news:pan.2006.01.15.13.26.57.290795@ya.com...
> Walter, I would like you to explain the change you did to combineCPathWithDPath. There you have:
>
>    // Create our own copy, as lifetime of c_path is undocumented
>    char[] cp = c_path[0 .. end].dup;
>
>    // Do we append something from path?
>    if (char_pos < path.length)
>        cp ~= path[char_pos .. length];
>
>    return cp;
>
> I don't understand your comment about the lifetime of c_path. Is it because it's a char instead of const char?  AFAICS, in both cases the char comes from memory which won't go away, or will it?

As I recall, in one case it was a pointer to memory returned from getenv(), which doesn't document the lifetime of it. For the other case c_path was potentially a pointer to memory that was later explicitly free'd by the function.

> And then, there's not much lifetime either for combineCPathWithDPath. Wouldn't it be the same to rewrite that block as:
>
>    // Do we append something from path?
>    if (char_pos < path.length)
>        return c_path[0 .. end] ~ path[char_pos .. length];
>    else
>        return c_path[0 .. end].dup;

No, because if char_pos==length, then c_path[0..end] is possibly returned, and no copy is made, although the current implementation of internal/gc/gc._d_arraycat() will always dup it. To future proof the code, it shouldn'd assume that ~ will always make a copy.

> Is (should be?) any of the blocks more optimal in terms of internal memory copies? Will the compiler optimise the second block better because the duplication of c_path happens in the same statement where the appending of path?
>
> What would be the best way to find out with the compiler? How would
> I find out what asm is being produced? Even if I don't know asm,
> I would expect the optimal block to be shorter, right?

The compiler doesn't control allocations, the runtime library does. Check out the routines in internal/gc/gc.d