On 11/20/2016 12:41 PM, ag0aep6g via Digitalmars-d-learn wrote:
On 11/20/2016 09:09 PM, Charles Hixson via Digitalmars-d-learn wrote:
Thinking it over a bit more, the item returned would need to be a
struct, but the struct wouldn't contain the array, it would just contain
a reference to the
On 11/20/2016 09:09 PM, Charles Hixson via Digitalmars-d-learn wrote:
Thinking it over a bit more, the item returned would need to be a
struct, but the struct wouldn't contain the array, it would just contain
a reference to the array and a start and end offset. The array would
need to live
On 11/20/2016 03:42 AM, ag0aep6g via Digitalmars-d-learn wrote:
On 11/20/2016 04:34 AM, Charles Hixson via Digitalmars-d-learn wrote:
Whether you would call the change "break things for your code" might be
dubious. It would be effectively broken, even if technically my code
was doing the
On 11/20/2016 08:30 PM, Charles Hixson via Digitalmars-d-learn wrote:
Well, that precise approach wouldn't work. (The traits aren't a part of
the sturct, e.g.),
What do you mean by "traits"?
On 11/20/2016 03:42 AM, ag0aep6g via Digitalmars-d-learn wrote:
On 11/20/2016 04:34 AM, Charles Hixson via Digitalmars-d-learn wrote:
Whether you would call the change "break things for your code" might be
dubious. It would be effectively broken, even if technically my code
was doing the
On 11/20/2016 04:34 AM, Charles Hixson via Digitalmars-d-learn wrote:
Whether you would call the change "break things for your code" might be
dubious. It would be effectively broken, even if technically my code
was doing the correct thing. But my code wouldn't be storing the data
that needed
On 11/19/2016 05:52 PM, ag0aep6g via Digitalmars-d-learn wrote:
On 11/20/2016 01:33 AM, Charles Hixson via Digitalmars-d-learn wrote:
Yes. I was hoping someone would pop up with some syntax making the
array, but not its contents, const or immutable, which I couldn't figure
out how to do, and
On 11/20/2016 01:33 AM, Charles Hixson via Digitalmars-d-learn wrote:
Yes. I was hoping someone would pop up with some syntax making the
array, but not its contents, const or immutable, which I couldn't figure
out how to do, and which is what I really hoped would be the answer, but
it appears
On 11/19/2016 01:50 PM, ag0aep6g via Digitalmars-d-learn wrote:
On 11/19/2016 10:26 PM, Charles Hixson via Digitalmars-d-learn wrote:
It's worse than that, if they modify the length the array may be
reallocated in RAM so that the pointers held by the containing class do
not point to the changed
On 11/19/2016 10:26 PM, Charles Hixson via Digitalmars-d-learn wrote:
It's worse than that, if they modify the length the array may be
reallocated in RAM so that the pointers held by the containing class do
not point to the changed values. (Read the header comments...it's not
nice at all.)
On 11/19/2016 11:10 AM, Nicolas Gurrola via Digitalmars-d-learn wrote:
On Saturday, 19 November 2016 at 18:51:05 UTC, Charles Hixson wrote:
ubyte[]header()@property {return fHead[4..$];}
This method should do what you want. You are only returning a slice of
the fHead
On Saturday, 19 November 2016 at 18:51:05 UTC, Charles Hixson
wrote:
ubyte[]header()@property{return
fHead[4..$];}
This method should do what you want. You are only returning a
slice of the fHead array, so if the caller modifies the length it
will only affect of the
I have a piece of code that looks thus:
/**Returns an editable file header missing the header length and data
* length portions. Those cannot be edited by a routine outside this
class.
* Access to them is available via the lenHead and lenRec functions.
* Warning: Do NOT change the
13 matches
Mail list logo
