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
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 =
&an_array_of_10_integers;
int*[10] an_array_of_10_pointers_to_integers;
int*[10]* a_
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 ev
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?
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
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 str
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, b
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, a
IIRC, there is some way to hook in and use a custom unittest-runner. How
does one go about that?
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 tim
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 di
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 fur
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?
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?
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 app
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???+/) {
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.
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?
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 ref
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?
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 n
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 lin
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 s
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;
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 = 1<<0,
optionB = 1<<1,
opti
Minor fix to work right for "none" fields. Already worked fine on
combination fields liek "all".
-
enum Foo
{
none = 0,
optionA = 1<<0,
optionB = 1<<1,
optionC = 1<<2,
optionD = 1<<3,
all = optionA | optionB | optionC | optionD,
}
impo
On 05/07/2015 01:41 PM, Nick Sabalausky wrote:
Assuming a plain old bitfield-style enum like:
enum Foo {
optionA = 1<<0;
optionB = 1<<1;
optionC = 1<<2;
optionD = 1<<3;
optionE = 1<<4;
}
Does a function already exist somewhere to take an instance of Foo and
get a list o
Assuming a plain old bitfield-style enum like:
enum Foo {
optionA = 1<<0;
optionB = 1<<1;
optionC = 1<<2;
optionD = 1<<3;
optionE = 1<<4;
}
Does a function already exist somewhere to take an instance of Foo and
get a list of the switch names as strings?
Something kinda lik
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
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
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 o
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 situatio
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 sui
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
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)
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]);
}
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]);
}
37 matches
Mail list logo
