Re: Erasing passwords from ram?
On Tuesday, 30 April 2019 at 08:15:15 UTC, Dukc wrote: I am currently programming a server. So I got the idea that after I've generated all the hashes I need from a password, I want to erase it from RAM before discarding it, just to be sure it won't float around if the server memory is exposed to spyware by some buffer overflow. Is this wise caution, or just being too paranoid? I've seen this done, and regardless of likelihoods, it doesn't hurt as a precaution. The memutils lib offers a tool for this, 'SecureMem': http://code.dlang.org/packages/memutils In addition to memory-zeroing, it can also prevent it from getting "dumped to disk on a crash or during OS sleep/hibernation."
Re: D's type declarations seem to read right to left.
On Wednesday, 21 March 2018 at 20:07:09 UTC, tipdbmp wrote: D's type declarations seem to read right to left. int an_integer; int[10] an_array_of_10_integers; int[10]* a_pointer_to_an_array_of_10_integers = _array_of_10_integers; int*[10] an_array_of_10_pointers_to_integers; int*[10]* a_pointer_to_an_array_of_10_pointers_to_integers = _array_of_10_pointers_to_integers; int[3][2] an_array_of_2_arrays_of_3_integers; int[string] a_hashtable_with_string_keys_and_integer_values; int[3][string][2] an_array_of_2_hashtables_with_string_keys_and_array_of_3_integers_values; int function(float) a_pointer_to_a_function_that_takes_a_float_and_returns_an_integer; int function(float)[10] an_array_of_10_functions_that_take_floats_and_return_integers; I think this is a big improvement over C's "spiral" way of reading types: http://www.unixwiz.net/techtips/reading-cdecl.html I guess it could've been left to right, but... it's okay. The way I see it, English "of" flips its operands backwards compared to English's [adjective][noun] syntax: int an_integer; int* an_integer_pointer; int[] an_integer_array; int[3]* an_integer_array(length 3)_pointer; But granted, in English, "of" is more scalable than [adjective][noun].
Partial arrays reclaimed?
Suppose an array is being used like a FIFO: --- T[] slice; // Add: slice ~= T(); // Remove: slice = slice[1..$]; --- Assuming of course there's no other references to the memory, as this gets used, does the any of the memory from the removed elements ever get GC'd? Also, if this is a long-running process, isn't there a potential danger in the array just marching through the address space and running out of room? (ie either running out of of continuous space, or hitting 0xFFF)
Reflection: Order of fields guaranteed?
When using reflection to obtain the fields of a class/struct, is there any guarantee that the order is the same as the order the fields are defined?
Escaping ref to stack mem sometimes allowed in @safe?
This compiles. Is it supposed to?
@safe ubyte[] foo()
{
ubyte[512] buf;
auto slice = buf[0..$];
// Escaping reference to stack memory, right?
return slice;
}
Or is the escaping reference detection not intended to be 100%? Or
something else I'm missing?
Should I file @ bugzilla?
Re: Phobos func for string -> enum member?
On 10/13/2016 07:14 PM, H. S. Teoh via Digitalmars-d-learn wrote:
On Thu, Oct 13, 2016 at 07:11:15PM -0400, Nick Sabalausky via
Digitalmars-d-learn wrote:
I'm sure it'd be easy enough to write, but does phobos have a simple
way to convert the name of an enum member from a runtime string to the
enum type?
Ie, something like:
enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");
I'm not finding anything like it in the docs, but I'm wondering if I
just missed it somewhere.
import std.conv : to;
Foobar a = "foo".to!Foobar;
:-)
T
Ah. Right. ;)
Thanks all.
Phobos func for string -> enum member?
I'm sure it'd be easy enough to write, but does phobos have a simple way
to convert the name of an enum member from a runtime string to the enum
type?
Ie, something like:
enum Foobar { foo=1, bar }
Foobar a = doesThisExistInPhobos!Foobar("foo");
I'm not finding anything like it in the docs, but I'm wondering if I
just missed it somewhere.
Re: Custom test runner
On 09/21/2016 02:26 AM, Jacob Carlborg wrote: On 2016-09-21 07:51, Nick Sabalausky wrote: IIRC, there is some way to hook in and use a custom unittest-runner. How does one go about that? http://dlang.org/phobos/core_runtime.html#.Runtime.moduleUnitTester Cool, thanks. I got that to work, and FWIW submitted a PR to add an example to the docs for that: https://github.com/dlang/druntime/pull/1656
Re: Fully-qualified symbol disambiguation is deprecated???
On 09/09/2016 12:35 PM, pineapple wrote: On Friday, 9 September 2016 at 11:54:42 UTC, Steven Schveighoffer wrote: Can you demonstrate the issue? I have never heard of this. imports should work when done inside a function. -Steve Tried and failed to reproduce with a simple example, but any time I've tried doing it in the code I'm working on I get Symbol Undefined errors which I had to fix by moving imports out of struct/class methods. Are those maybe linker errors you're getting? It sounds like maybe the build system you're using, rather than the compiler, for some reason is rudimentary and isn't using the compiler itself to find dependencies. What build tool are you using?
Re: Fully-qualified symbol disambiguation is deprecated???
On 09/08/2016 06:22 PM, Nick Sabalausky wrote:
On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:
On 9/8/16 6:02 PM, Nick Sabalausky wrote:
I'm getting deprecation messages ("Package...not accessible here,
perhaps add static import") when simply trying to use fully-qualified
symbol names to disambiguate a symbol. Is this really intended?
Yes.
It's difficult to attribute the message without context, though.
Yea, unfortunately I don't have it narrowed down to a test case, atm.
And
there are still some straggling bugs which cause this message to be
erroneously printed.
I'm pretty sure I've hit one of those :( Can't be certain though until I
examine my specific case further.
Turns out I didn't hit one of those bugs, but one of the problems I was
hitting was the old problem where package.d completely fucks any and all
attempts at using a FQN. Worked around with local selective renamed imports.
FQN used to be a real killer feature of D: To deal with name collisions,
you could *ALWAYS* replace a visible symbol with it's FQN and it would
*just work*. But now with package.d, UFCS, and 2.071's selective import
behavior, that benefit's pretty much been shot to hell.
Re: Fully-qualified symbol disambiguation is deprecated???
On 09/08/2016 06:22 PM, Nick Sabalausky wrote: On 09/08/2016 06:13 PM, Steven Schveighoffer wrote: And there are still some straggling bugs which cause this message to be erroneously printed. I'm pretty sure I've hit one of those :( Can't be certain though until I examine my specific case further. Oh, although the whole "selective imports don't import the FQN" is a big surprise to me. I think at least some of the messages I hit were from that. (Can't say I'm a big fan of that particular one, but meh, whatever...)
Re: Fully-qualified symbol disambiguation is deprecated???
On 09/08/2016 06:13 PM, Steven Schveighoffer wrote:
On 9/8/16 6:02 PM, Nick Sabalausky wrote:
I'm getting deprecation messages ("Package...not accessible here,
perhaps add static import") when simply trying to use fully-qualified
symbol names to disambiguate a symbol. Is this really intended?
Yes.
It's difficult to attribute the message without context, though.
Yea, unfortunately I don't have it narrowed down to a test case, atm.
And
there are still some straggling bugs which cause this message to be
erroneously printed.
I'm pretty sure I've hit one of those :( Can't be certain though until I
examine my specific case further.
Fully-qualified symbol disambiguation is deprecated???
I'm getting deprecation messages ("Package...not accessible here,
perhaps add static import") when simply trying to use fully-qualified
symbol names to disambiguate a symbol. Is this really intended?
Get third part of front-end version number
These days, DMD/DMDFE version numbers are three parts, ex: 2.070.1. I can get the first two via std.compiler.version_major and std.compiler.version_minor. Is there a way to get the third part? I know I can "dmd --help | grep DMD", but that only works for DMD. GDC's "gdc --version" doesn't appear to show the DMDFE version, and I have no idea about LDC. Or is the third part of the DMDFE version completely irrelevant to LDC/GDC?
Varargs and default arguments
Ok, D-style varargs can accept a parameter length of zero:
---
void foo(T...)(T args) {
//...
}
foo();
foo(t1, t2);
---
Is there any way to stick a param with a default value before that?
---
void foo(T...)(string str=null, T args=/+what goes here???+/) {
//...
}
foo();
foo(str);
foo(str, t1, t2);
---
Obviously this can be worked around easily enough by splitting it into
two overloads ("foo(string str=null)" and "foo(string str, T args)"),
but is there a way to do it in one?
const-correct structs, best practices?
Is there a good posting somewhere that summarizes the current best practices for making const-correct (ie works for all of mutable/const/immutable) structs?
Re: const-correct structs, best practices?
On 08/21/2015 12:22 PM, Dicebot wrote: On Friday, 21 August 2015 at 15:00:04 UTC, Nick Sabalausky wrote: Is there a good posting somewhere that summarizes the current best practices for making const-correct (ie works for all of mutable/const/immutable) structs? - mark methods const - avoid reference type fields ;) What about inout? I have a struct that supports operator overloading, returning the struct's own type. After fiddling with that, I got a good laugh out of Meta's comment, and I think he may be right!
Appender at CTFE?
Not at a pc, so can't test right now, but does Appender work at compile time? If not, does ~= still blow up CTFE memory usage like it used to? Any other best practice / trick for building strings in CTFE?
Re: Appender at CTFE?
Thanks! I wouldn't have expected that about the memory. But I wonder how much of that memory usage with Appender was just all the template instantiations. I'll have to look into that when I get back.
Bitfield-style enum to strings?
Assuming a plain old bitfield-style enum like:
enum Foo {
optionA = 10;
optionB = 11;
optionC = 12;
optionD = 13;
optionE = 14;
}
Does a function already exist somewhere to take an instance of Foo and
get a list of the switch names as strings?
Something kinda like:
Foo fooVar = Foo.optionB | Foo.optionD;
assert(
DOES_THIS_FUNC_EXIST(fooVar)
.equals([optionB, optionD])
);
Seems entirely feasible, although my traits-fu is a bit rusty.
Re: Moving from Python to D
I'm not really sure exactly what parts are the issue, but I'll point out
what I can:
On 05/07/2015 11:24 PM, avarisclari wrote:
Hello,
Sorry to bother you with something trivial, but I am having trouble
translating a block of code I wrote in Python over to D. Everything else
I've figured out so far. Could someone help me understand how to get
this right?
Here's the python:
scene = scenes[title]
It looks like scenes is a dictionary that stores dictionaries of
strings? If so, then in D, scenes would be declared like this:
string[string][string] scenes;
Then the above line would be:
auto scene = scenes[title]
while 1 == 1:
In D, while(true) is probably prefered, but that's just a matter of
style. 1==1 will work too.
next_choice = None
paths = scene[paths]
description = scene[description]
lines = string.split(\n)
Phobos (D's standard library) has a split:
http://dlang.org/phobos/std_array.html#split
Also one specifically for splitting lines:
http://dlang.org/phobos/std_string.html#splitLines
They're easier to use than it looks:
auto lines = description.split(\n);
or better yet (also handles mac and win-style properly):
auto lines = description.splitLines();
for line in lines:
Standard foreach:
for(ref line; lines) {
if len(line 55):
w = textwrap.TextWrapper(width=45, break_long_words=False)
Exists in Phobos:
http://dlang.org/phobos/std_string.html#wrap
I've never actually used it myself though.
line = '\n'.join(w.wrap(line))
Join is easy:
http://dlang.org/phobos/std_array.html#join
result = (whatever array or range you want to join).join(\n)
But really, I don't think you'll need this entire loop at all, though. I
would just strip all the newlines and feed the result to Phobos's
wrap(). Probably something like:
auto description =
scene[description].replace(\n, ).wrap(45);
That should be all you need for the word wrapping.
decription += line +\n
D uses ~ to concatenate strings instead of +. In D, + is just for
mathematical addition.
print description
writeln(description);
#Shows the choices
for i in range(0, len(paths)):
foreach(i; 0..paths.length) {
path = paths[i]
menu_item = i + 1
print \t, menu_item, path[phrase]
writeln(\t, menu_item, path[phrase]);
print \t(0 Quit)
#Get user selection
// Get user selection
prompt = Make a selection ( 0 - %i): \n % len(paths)
This is in phobos's std.conv: http://dlang.org/phobos/std_conv.html
So, either:
auto prompt = Make a selection ( 0 - ~
paths.length.to!string() ~ ): \n;
or:
auto prompt = text(Make a selection ( 0 - ,
paths.length, ~ ): \n)
while next_choice == None:
try:
choice = raw_input(prompt)
The basic equivalent to raw_input would be readln():
http://dlang.org/phobos/std_stdio.html#readln
But, the library Scriptlike would make this super easy, thanks to a
contributer:
https://github.com/Abscissa/scriptlike
Pardon the complete lack of styling in the docs (my fault):
http://semitwist.com/scriptlike/interact.html
So, it'd be:
import scriptlike.interact;
auto choice = userInput!int(prompt);
menu_selection = int(choice)
if menu_selection == 0:
next_choice = quit
else:
index = menu_selection - 1
next_choice = paths[ index ]
except(IndexError, ValueError):
print choice, is not a valid selection
if next_choice == quit:
print Thanks for playing.
sys.exit()
I forget the function to exist a program, but if this is in your main()
function, then you can just:
return;
else:
scene = scenes[ next_choice[go_to] ]
print You decided to:, next_choice[phrase], \n
if sys.platform == 'win32':
os.system(cls)
else:
os.system(clear)
I've got the very last piece set up, using consoleD to use
clearScreen(), but The rest I'm not sure how to translate. Sorry for my
incompetence in advance.
Re: Moving from Python to D
On 05/08/2015 12:06 AM, Nick Sabalausky wrote: On 05/07/2015 11:24 PM, avarisclari wrote: scene = scenes[title] It looks like scenes is a dictionary that stores dictionaries of strings? If so, then in D, scenes would be declared like this: string[string][string] scenes; Then the above line would be: auto scene = scenes[title] BTW, D calls them Associative Arrays or AA, instead of dictionary. I *think* dictionary is what Python calls them, but I could be wrong.
Re: Bitfield-style enum to strings?
On 05/07/2015 09:17 PM, Meta wrote: On Thursday, 7 May 2015 at 21:41:06 UTC, Nick Sabalausky wrote: On 05/07/2015 05:19 PM, Justin Whear wrote: T[] members = [ EnumMembers!T ]; Doh! Yup, that works. Still, I would think there should be a way to do it without allocating an array. But it's not a huge deal right now though. You could also do `TypeTuple!(EnumMembers!T))` I believe. filter doesn't seem to like that.
Re: Bitfield-style enum to strings?
Gah, missed some imports that time:
On 05/07/2015 05:04 PM, Nick Sabalausky wrote:
Minor fix to work right for none fields. Already worked fine on
combination fields liek all.
-
enum Foo
{
none = 0,
optionA = 10,
optionB = 11,
optionC = 12,
optionD = 13,
all = optionA | optionB | optionC | optionD,
}
import std.traits : isIntegral;
auto bitFieldValues(T)(T value) if(is(T==enum) isIntegral!T)
{
import std.algorithm : filter, map;
import std.conv : to;
import std.traits : EnumMembers;
// There's gotta be a better way to convert EnumMembers!T
// to a range, right? But std.range.only() didn't work,
// due to a template instantiation error.
T[] members;
foreach(m; EnumMembers!(T))
members ~= m;
return members
.filter!(member = member==0? value==0 : (valuemember)==member)
.map!(member = to!string(member));
}
void main()
{
import std.range : join;
import std.stdio : writeln;
Foo fooVar = Foo.optionB | Foo.optionD;
// Output:
// optionB | optionD
// none
// optionA | optionB | optionC | optionD | all
writeln(bitFieldValues(Foo.optionB | Foo.optionD).join( | ));
writeln(bitFieldValues(Foo.none).join( | ));
writeln(bitFieldValues(Foo.all).join( | ));
}
-
Re: Bitfield-style enum to strings?
On 05/07/2015 01:41 PM, Nick Sabalausky wrote:
Assuming a plain old bitfield-style enum like:
enum Foo {
optionA = 10;
optionB = 11;
optionC = 12;
optionD = 13;
optionE = 14;
}
Does a function already exist somewhere to take an instance of Foo and
get a list of the switch names as strings?
Something kinda like:
Foo fooVar = Foo.optionB | Foo.optionD;
assert(
DOES_THIS_FUNC_EXIST(fooVar)
.equals([optionB, optionD])
);
Seems entirely feasible, although my traits-fu is a bit rusty.
Wow, D's seriously awesome, that was actually way easier than I expected:
import std.traits : isIntegral;
auto bitFieldValues(T)(T value) if(is(T==enum) isIntegral!T)
{
import std.algorithm : filter, map;
import std.conv : to;
import std.traits : EnumMembers;
// There's gotta be a better way to convert EnumMembers!T
// to a range, right? But std.range.only() didn't work,
// due to a template instantiation error.
T[] members;
foreach(m; EnumMembers!(T))
members ~= m;
return members
.filter!(member = (value member) == member)
.map!(member = to!string(member));
}
Sample code to use it:
enum Foo
{
optionA = 10,
optionB = 11,
optionC = 12,
optionD = 13,
optionE = 14,
}
void main()
{
import std.range : join;
import std.stdio : writeln;
Foo fooVar = Foo.optionB | Foo.optionD;
// Output: optionB | optionD
writeln(bitFieldValues(fooVar).join( | ));
}
Re: Bitfield-style enum to strings?
On 05/07/2015 05:19 PM, Justin Whear wrote: On Thu, 07 May 2015 16:55:42 -0400, Nick Sabalausky wrote: // There's gotta be a better way to convert EnumMembers!T // to a range, right? But std.range.only() didn't work, // due to a template instantiation error. T[] members; foreach(m; EnumMembers!(T)) members ~= m; T[] members = [ EnumMembers!T ]; Doh! Yup, that works. Still, I would think there should be a way to do it without allocating an array. But it's not a huge deal right now though.
Re: Bitfield-style enum to strings?
Minor fix to work right for none fields. Already worked fine on
combination fields liek all.
-
enum Foo
{
none = 0,
optionA = 10,
optionB = 11,
optionC = 12,
optionD = 13,
all = optionA | optionB | optionC | optionD,
}
import std.traits : isIntegral;
auto bitFieldValues(T)(T value) if(is(T==enum) isIntegral!T)
{
// There's gotta be a better way to convert EnumMembers!T
// to a range, right? But std.range.only() didn't work,
// due to a template instantiation error.
T[] members;
foreach(m; EnumMembers!(T))
members ~= m;
return members
.filter!(member = member==0? value==0 : (valuemember)==member)
.map!(member = to!string(member));
}
void main()
{
import std.range : join;
import std.stdio : writeln;
Foo fooVar = Foo.optionB | Foo.optionD;
// Output:
// optionB | optionD
// none
// optionA | optionB | optionC | optionD | all
writeln(bitFieldValues(Foo.optionB | Foo.optionD).join( | ));
writeln(bitFieldValues(Foo.none).join( | ));
writeln(bitFieldValues(Foo.all).join( | ));
}
-
line numbers in linux stack traces?
I know this keeps getting asked every year or so, but I couldn't find recent info. Are line numbers in linux stack traces supposed to be working at this point? Because I'm not getting any with 2.066.0 with either -g or -gc even when running under gdb. Kind of a pain, esp. compared to D dev on windows.
Re: Installing LDC on Windows
On 9/6/2014 11:09 AM, Kagamin wrote: SEH was patented, so llvm doesn't support it. Seriously, if they're worried about infringing a software patent, they have no business writing any code at all. Avoiding things covered by patents *and* writing code that actually does anything useful is NOT REALISTICALLY POSSIBLE. The SEH patent is just a red herring here.
Good/Bad? @disable postblit for struct InputRange
One issue with struct-based input ranges: Saving the state of an input range is not supported (by definition of input range), and yet, you can trivially and accidentally do so with a simple assignment or passing into a function. The results may or may not blow up depending on the exact situation. And if the input range happens to hit a poorly-implemented algorithm which *should* be statically requiring a ForwardRange and using .save() to duplicate state, but instead accepts any range and (accidentally?) saves state by simple struct copy...which will work fine for most struct-based forward ranges and therefore could go completely unnoticed...Then once again, your input range touches it and BOOM. This *could* be addressed by making the input range a class, but that seems a bit overkill in many cases. So I'm tempted to give my struct-bassed input ranges a @disable'd postblit. That would solve the problem, right? Would there be any reason NOT to do this?
Re: Good/Bad? @disable postblit for struct InputRange
On 9/5/2014 6:14 PM, monarch_dodra wrote: Ref semantics is one option, yes. Either by class, or by struct. For example, most IO ranges implemented ref-counted reference semantics. IMO, disabling postblit is overkill, as almost anything that does anything with ranges will pass them by value at one point or another. [...] *Ideally*, these functions would do a move-return, and you'd pass-by-move, so you'd be able to effectively disable postblit, but still pass by move-value. Unfortunately, we aren't quite there yet... I see. Good points, thanks.
Re: Curl Exception
On 5/10/2014 9:02 AM, Jack wrote: First off a rant: I use the Code::Blocks IDE and at times it has been proven to a double-edged source because of various issueslike this one: http://forum.dlang.org/thread/ndeyzrifseipuebvy...@forum.dlang.org) and am now itching to search for other IDEs to suit my needs. I switched from C::B to Programmer's Notepad 2 several years ago, and I've been happy with it: http://www.pnotepad.org/ It's good if you're looking for a light editor rather than a heavy-duty IDE. Otherwise, there's VisualD and Mono-D which I hear are good. Now on to the question: Anyway, I was using std.net.curl to implement an auto updater for my program. Sorry, I haven't really used the curl stuff yet, so I can't be a bigger help, but a couple notes below: Function code is this: http://pastebin.com/i6WnwJF5(links removed due to it having private content. Original host is https://dropbox.com) And the overall function was working fine in the IDE except for an Access Violation that I thought would work itself out when it's (run by administrator). Access Violation, despite its wording, isn't usually about user permissions. It's the Windows version of a segfault. Usually means a null pointer was dereferenced, or a freed pointer was used, or an otherwise bad pointer or buffer overflow, etc. If you're really unlucky those can be a result of memory corruption, but that's usually not the case. So I Exported it to a folder with all necessary files, including the cacert.pem file and run it. Well this little error popped out : http://pastebin.com/8MmPLg2Q If you recompile with -g (enable debugging symbols), then those annoyingly meaningless addresses will change into a proper stack trace. (Or try -gc if -g doesn't work.) Is that the same error you get if you try to give it a pem file you *know* doesn't exist? If so, then maybe it's not looking in the directory you expect. Try giving it a full absolute path to the pem file. If that works, then it's probably looking in the directory you're running from instead of the directory where it actually exists. If so, you can use std.file.thisExePath() and build your path relative to that (or just stick with an absolute path). You can also try opening your pem file directly: auto pemFile = File(cacert.pem); See what happens if you do that. It won't fix the problem, but seeing what it does it should help give you a better idea of what's going on. Though in the Code:: Blocks IDE there was the object.Error Access Violation error And in the actual program(.exe) this : http://pastebin.com/8MmPLg2Q Though I'm also up for not verifying the link but I still can't figure out how. Anyway, can anyone give me an idea what went wrong?
Re: Implicit static-dynamic arr and modifying
On 5/6/2014 6:46 PM, Rene Zwanenburg wrote:
On Tuesday, 6 May 2014 at 02:17:06 UTC, Nick Sabalausky wrote:
So all is well, and deliberately so. Pardon the noise.
IMO it's not. I once had a particularly nasty bug because of this:
struct S
{
@safe:
string str;
this(string data)
{
import std.digest.md;
str = md5Of(data).toHexString(); // Oops...
}
}
That must be a terribly subtle one, I'm not seeing the problem at all.
I get that md5Of returns a static array, and then a slice of it gets
passed to toHexString, but AIUI toHexString finishes (and returns a
newly allocated string) before the temporary static array leaves scope.
Re: [Rosettacode] D code line length limit
On 5/7/2014 9:25 AM, bearophile wrote: So far in Rosettacode D entries I've kept a line length limit of 72 or 73 chars. But now a little larger monitors are common, D UFCS chains are common, and we also have longer function signatures with pure nothrow @safe @nogc (that usually I put on a new line), so keeping that line length limit is becoming a little pain. So probably I'll increase the maximum line length. Rosettacode rules forbids too much long lines, and while in my code I use a limit of about 90-100 in my code, this is too much for online wiki pages. So I'll do some tests, and I think for Rosettacode D entries I'll increase the limit to about 80 chars. Bye, bearophile 72-73 chars would indeed be a pain. In my own code I like to use a soft limit of 80, FWIW. I do find I need to break up lines in D more than I would in other languages, especially function signatures.
Implicit static-dynamic arr and modifying
Is this kinds stuff a sane thing to do, or does it just work by accident?:
void modify(ubyte[] dynamicArr)
{
dynamicArr[$-1] = 5;
}
void main()
{
ubyte[4] staticArr = [1,1,1,1];
modify(staticArr);
assert(staticArr == [1,1,1,5]);
}
Re: Implicit static-dynamic arr and modifying
On 5/5/2014 10:11 PM, Nick Sabalausky wrote:
Is this kinds stuff a sane thing to do, or does it just work by accident?:
void modify(ubyte[] dynamicArr)
{
dynamicArr[$-1] = 5;
}
void main()
{
ubyte[4] staticArr = [1,1,1,1];
modify(staticArr);
assert(staticArr == [1,1,1,5]);
}
Duh, it's just using a normal slice of the static array...
// Roughly:
dynamicArr.ptr = staticArr;
dynamicArr.length = typeof(staticArr).sizeof;
So all is well, and deliberately so. Pardon the noise.
