On Monday, 21 March 2016 at 23:31:06 UTC, ref2401 wrote:
I have got a plenty of structs in my project. Their size varies
from 12 bytes to 128 bytes.
Is there a rule of thumb that states which structs I pass by
value and which I should pass by reference due to their size?
Thanks.
Not really.
So I was recently trying to optimise a string substitution
function by reserving capacity. however this was being used at
compile time (mixin) and the body of arr.reserve(n) was not
available causing a bug that was easy to observe but very
difficult to determine why. As a result code was
On Tuesday, 22 March 2016 at 00:18:54 UTC, Steven Schveighoffer
wrote:
On 3/21/16 7:43 PM, tsbockman wrote:
The false positive rate would certainly be *much* lower than
your
outlandish 10,000 : 1 estimate, given a good compiler
implementation.
I wouldn't say it's outlandish given my
On 3/21/16 7:43 PM, tsbockman wrote:
On Monday, 21 March 2016 at 22:29:46 UTC, Steven Schveighoffer wrote:
It depends on the situation. foo may know that x is going to be short
enough to fit in an int.
The question becomes, if 99% of cases the user knows that he was
converting to a signed
On Monday, 21 March 2016 at 22:29:46 UTC, Steven Schveighoffer
wrote:
It depends on the situation. foo may know that x is going to be
short enough to fit in an int.
The question becomes, if 99% of cases the user knows that he
was converting to a signed value intentionally, and in the
I have got a plenty of structs in my project. Their size varies
from 12 bytes to 128 bytes.
Is there a rule of thumb that states which structs I pass by
value and which I should pass by reference due to their size?
Thanks.
On 3/21/16 4:27 PM, tsbockman wrote:
On Monday, 21 March 2016 at 17:38:35 UTC, Steven Schveighoffer wrote:
Your definition of when "implicit casting is really a bad idea" is
almost certainly going to include cases where it really isn't a bad idea.
This logic can be applied to pretty much any
On Sunday, 20 March 2016 at 07:49:17 UTC, stunaep wrote:
The gc throws invalid memory errors if I use Arrays from
std.container.
...
Not sure what to do here
I don't know what your larger goal is, but maybe
std.array.Appender would be a better fit?
On Monday, 21 March 2016 at 17:38:35 UTC, Steven Schveighoffer
wrote:
Your definition of when "implicit casting is really a bad idea"
is almost certainly going to include cases where it really
isn't a bad idea.
This logic can be applied to pretty much any warning condition or
On Monday, 21 March 2016 at 17:26:09 UTC, Karabuta wrote:
I am new to this kind of multimedia stuff and all this is
currently theoretical. Will this work and is it the right
approach used by video convertor front-ends?
Eh, it is how I did it before, it works and is pretty easy to do.
On 3/19/16 2:36 PM, ric maicle wrote:
I got an error message with the following code saying:
Error: no property 'length' for type 'int[string]'
Shouldn't the error message say 'length()'?
No, it should say length is a property, not a function. a.length should
work.
Note the error
On 3/18/16 7:48 PM, tsbockman wrote:
On Friday, 18 March 2016 at 14:51:34 UTC, Steven Schveighoffer wrote:
Note, I have made these mistakes myself, and I understand what you are
asking for and why you are asking for it. But these are bugs. The user
is telling the compiler to do one thing, and
Hi all,
I'm trying to convert an array of video filenames to another
format using spawnProcess() from std.process. I want to convert
all files in sequence with the command "ffmpeg -i filename.mp4 -o
outputfile.webm" where process will be run one process after the
other.
I am new to this
On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote:
This is because my project has grown beyond 30klines of code
and at that scale not even D's speed is enough for getting fast
incremental builds through dmd.
Note that lines of code isn't really important to build time...
$ time dmd -c
On Monday, 21 March 2016 at 15:15:41 UTC, Nordlöw wrote:
I don't see any other solution for really large projects.
Except implementing memoized execution of unittests into dmd.
Which I have discussed previously :)
On Monday, 21 March 2016 at 15:11:31 UTC, Nordlöw wrote:
On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote:
This is quite annoying I feel.
There probably should be an option for the -unittest flag to
only compile unittests for the source files I'm passing in,
and not any of the tests
On Monday, 21 March 2016 at 11:36:10 UTC, wobbles wrote:
This is quite annoying I feel.
There probably should be an option for the -unittest flag to
only compile unittests for the source files I'm passing in, and
not any of the tests in the -I import paths.
I very much agree.
On Monday, 27 July 2015 at 20:12:10 UTC, John Colvin wrote:
Yes, but then core.sync.semaphore doesn't support being shared,
so...
I don't really understand how
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/semaphore.d#L356 is managing to avoid this
Since
On Monday, 21 March 2016 at 10:37:31 UTC, ZombineDev wrote:
On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote:
I want to enable unittests only at the top-level of a module
compilation.
If I have a module
top.d
that imports
dep1.d
dep2.d
...
which all contain
On Monday, 21 March 2016 at 10:46:27 UTC, ag0aep6g wrote:
On 21.03.2016 11:19, ZombineDev wrote:
DFLAGS=-I~/dev/repos/dlang/druntime/import
-I~/dev/repos/dlang/phobos
-L-L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64
[...]
Linking...
...
/usr/bin/ld {other stuff...}
On 21.03.2016 11:19, ZombineDev wrote:
DFLAGS=-I~/dev/repos/dlang/druntime/import -I~/dev/repos/dlang/phobos
-L-L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64
[...]
Linking...
...
/usr/bin/ld {other stuff...}
-L/home/zombinedev/dev/repos/dlang/phobos/generated/*/release/64
On Monday, 21 March 2016 at 10:29:36 UTC, Nordlöw wrote:
I want to enable unittests only at the top-level of a module
compilation.
If I have a module
top.d
that imports
dep1.d
dep2.d
...
which all contain unittests, how do I compile top.d with only
the unittests for top.d
I want to enable unittests only at the top-level of a module
compilation.
If I have a module
top.d
that imports
dep1.d
dep2.d
...
which all contain unittests, how do I compile top.d with only the
unittests for top.d enabled?
I'm manually building dmd, druntime and phobos like so:
$ cd ~/dev/repos/dlang
$ git clone https://github.com/D-Programming-Language/dmd
$ git clone https://github.com/D-Programming-Language/druntime
$ git clone https://github.com/D-Programming-Language/phobos
$ cd dmd && make -f make -f
On Sunday, 20 March 2016 at 07:49:17 UTC, stunaep wrote:
The gc throws invalid memory errors if I use Arrays from
std.container.
Those arrays are for RAII-style deterministic memory release,
they shouldn't be freely mixed with GC-allocated things. What
happens here is while initializing
25 matches
Mail list logo