On Saturday, 21 February 2015 at 07:01:12 UTC, Baz wrote:
---
class S
{
private SomeType cache;
public const(SomeType) SomeProp() @property
{
if (cache is null)
cache = SomeExpensiveOperation();
return cache;
}
}
---
the result of the getter will be read-o
---
class S
{
private SomeType cache;
public const(SomeType) SomeProp() @property
{
if (cache is null)
cache = SomeExpensiveOperation();
return cache;
}
}
---
the result of the getter will be read-only
Often I'm using the following code pattern:
class S
{
private SomeType cache;
public SomeType SomeProp() @property
{
if (cache is null)
cache = SomeExpensiveOperation();
return cache;
}
}
Is there any way to mark SomeProp() as const? Because I want to
call somew
On Fri, 20 Feb 2015 22:51:21 +, Vlad Levenfeld wrote:
> On Friday, 20 February 2015 at 22:44:35 UTC, ketmar wrote:
>> can you go with `relationImpl` and mixin/template that generates
>> `relation` with contract then? something like:
>>
>> @reflexive @transitive bool relationImpl (T)(T a, T b
On 02/20/2015 02:32 PM, Vlad Levenfeld wrote:
I'd like to do something like this:
@reflexive @transitive bool relation (T)(T a, T b)
out (result) {
mixin(property_verification!result);
}
body {
...
}
which becomes
out (result) {
// generated from @reflexive
Is there a complete list of DMD compiler intrinsics?
I searched the compiler source code but they seem scattered
around. I discovered some of them (strlen, memcpy, strcmp, etc)
but I suppose there is a list somewhere.
On Friday, 20 February 2015 at 22:44:35 UTC, ketmar wrote:
can you go with `relationImpl` and mixin/template that generates
`relation` with contract then? something like:
@reflexive @transitive bool relationImpl (T)(T a, T b) { ... }
alias relation = buildWithContracts!relationImpl;
then yo
On Fri, 20 Feb 2015 22:29:04 +, Ola Fosheim Grøstad wrote:
> This robust philosophy somehow got lost in the quest for bleeding edge.
i still missing it. sure, we can write our code in this style today, but
with all that libraries that can create threads without you knowing about
it (heh, h
On Fri, 20 Feb 2015 22:32:53 +, Vlad Levenfeld wrote:
> I'd like to do something like this:
>
>@reflexive @transitive bool relation (T)(T a, T b)
>out (result) {
> mixin(property_verification!result);
>}
>body {
> ...
>}
>
> which becomes
>
>out (result) {
I'd like to do something like this:
@reflexive @transitive bool relation (T)(T a, T b)
out (result) {
mixin(property_verification!result);
}
body {
...
}
which becomes
out (result) {
// generated from @reflexive
assert (result == skip_contract!relation (b,a));
On 02/20/2015 12:30 PM, Steven Schveighoffer wrote:
> On 2/20/15 1:05 PM, Nick Treleaven wrote:
>> It works correctly if I use destroy(*p), but the above code could
>> perhaps be statically rejected by object.destroy to help prevent bugs.
> I'm beginning to think this is the right thing to do.
On Friday, 20 February 2015 at 22:07:56 UTC, Kagamin wrote:
AFAIK, in early days of unix there were no threads, processes
were single-threaded, fork was the way to concurrency and exec
was the most efficient way to run a program in
memory-constrained conditions of 70s (kbytes of RAM!). Plain
u
Implementations can have bugs, probably COFF support wasn't
stress tested.
https://issues.dlang.org/show_bug.cgi?id=13172
On Friday, 20 February 2015 at 14:33:31 UTC, Ola Fosheim Grøstad
wrote:
Yeah, either use plain C or avoid 3rd party libraries... I
guess that includes phobos ;)
AFAIK, in early days of unix there were no threads, processes
were single-threaded, fork was the way to concurrency and exec
was the
What's the policy on using GC or not in std.container.* ?
- std.container.Array uses malloc for its allocation but
- RedBlackTree.allocate() returns a: new RBNode!Elem*
Is this because RBNode* should be reachable outside of
RedBlackTree or is this a todo?
On 2/20/15 1:05 PM, Nick Treleaven wrote:
Hi,
The following code is supposed to destroy the struct instance:
import std.stdio;
struct S{
~this(){"destruct".writeln;}
}
auto p = new S;
destroy(p);
"end".writeln;
It works correctly if I use destroy(*p),
On Friday, 20 February 2015 at 17:28:48 UTC, Nicholas Wilson
wrote:
On Friday, 20 February 2015 at 06:19:29 UTC, Gan wrote:
On Friday, 20 February 2015 at 06:10:51 UTC, Nicholas Wilson
wrote:
On Friday, 20 February 2015 at 03:26:47 UTC, Gan wrote:
Also I can't get my application to load images
Hi,
The following code is supposed to destroy the struct instance:
import std.stdio;
struct S{
~this(){"destruct".writeln;}
}
auto p = new S;
destroy(p);
"end".writeln;
It works correctly if I use destroy(*p), but the above code could
perhaps be statically r
On Friday, 20 February 2015 at 06:19:29 UTC, Gan wrote:
On Friday, 20 February 2015 at 06:10:51 UTC, Nicholas Wilson
wrote:
On Friday, 20 February 2015 at 03:26:47 UTC, Gan wrote:
Also I can't get my application to load images that I place
in the Resources folder(or any folder in the bundle for
On Friday, 20 February 2015 at 06:19:29 UTC, Gan wrote:
On Friday, 20 February 2015 at 06:10:51 UTC, Nicholas Wilson
wrote:
On Friday, 20 February 2015 at 03:26:47 UTC, Gan wrote:
Also I can't get my application to load images that I place
in the Resources folder(or any folder in the bundle for
On Friday, 20 February 2015 at 15:17:22 UTC, Martin Nowak wrote:
Might want to try using libasync without multiple threads.
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
Or you temporarily disable the GC before forking and enable it
again afterwards.
On 02/18/2015 09:35 PM, Byron Heads wrote:
I am in the daemonize library
https://github.com/NCrashed/daemonize
Might want to try using libasync without multiple threads.
http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-using-them
On Fri, 20 Feb 2015 14:33:29 +, Ola Fosheim Grøstad wrote:
> On Friday, 20 February 2015 at 12:47:58 UTC, ketmar wrote:
>> 3rd party library that already initialized something, or... you got the
>> idea. ;-)
>
> Yeah, either use plain C or avoid 3rd party libraries... I guess that
> includes
On Friday, 20 February 2015 at 04:48:09 UTC, Charles wrote:
They're installer versions, dub is 0.9.22 Nov 22 I want to say,
and DMD is 2.066.1
Same ones I tried.
With --force dmd seems to fail but there is not output.
Can you run only the link command with a -v to get verbose dmd
output?
dm
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote:
System:
DMD 2.066.1
Can you also try the latest beta please, maybe we already fixed
something.
http://forum.dlang.org/post/54e49e2d.2010...@dawg.eu
On Friday, 20 February 2015 at 12:47:58 UTC, ketmar wrote:
3rd party library that already initialized something, or... you
got the idea. ;-)
Yeah, either use plain C or avoid 3rd party libraries... I guess
that includes phobos ;)
On Wednesday, 18 February 2015 at 20:41:12 UTC, Dicebot wrote:
Any chance you are using gdm-3.12.x?
I was so mad when I have encountered this:
https://issues.dlang.org/show_bug.cgi?id=4890
Indeed, maybe
http://dlang.org/phobos-prerelease/core_thread.html#.thread_setGCSignals
might help.
We s
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote:
I have a medium size daemon application that uses several
threads, libasync, and daemonize. On windows it runs correctly
with GC enabled, but on linux the GC causes a deadlock while
allocating memory.
Can you reliably reproduce
On Wednesday, 18 February 2015 at 20:27:08 UTC, Byron Heads wrote:
Adding core.memory.GC.disable; to main causes the application to
work correctly (and quickly till it runs out of memory :D )
GC.disable shouldn't run OOM, BTW.
http://dlang.org/phobos/core_memory.html#.GC.disable
On Friday, 20 February 2015 at 13:00:39 UTC, John Colvin wrote:
I agree. Wrap it in a mixin / mixin template?
Why do you need this? Presumably it'll be hidden in the depths
of some library / bindings where beauty is somewhat optional?
Using the .mangleof from an extern(D) function should mean
On Fri, 20 Feb 2015 12:58:01 +, rumbu wrote:
> A simple cast will always permit to destroy the type system entirely:
`cast` is the thing programmer does explicitly. it's assumed that
programmer is know what he is doing, and he takes full responsibility for
that.
hidden type system breakage
On Friday, 20 February 2015 at 12:23:31 UTC, Benjamin Thaut wrote:
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin
wrote:
I would duplicate the declaration, once without extern(C++),
once with, the use the .mangleof from the 1st to set the
mangle of the 2nd with pragma(mangle
Yes
On Friday, 20 February 2015 at 10:41:04 UTC, Jonathan M Davis
wrote:
class Super {}
class Sub : Super {}
class Sub2 : Super {}
Sub[] subArr = createSubArr();
Super[] superArr = subArr;
superArr[2] = new Sub2;
Now, all of a sudden, subArr[2] is a Sub2, when a Sub2 is not a
Sub. So, you
would h
On Fri, 20 Feb 2015 09:04:29 +, Ola Fosheim Grøstad wrote:
> If you fork early in the process'
> lifespan, before acquiring resources, then it is much easier...
and even if `fork()` is the first line of code in `main()`, there cannot
be any guarantees. there can be module constructor doing
On Fri, 20 Feb 2015 08:03:00 +, Kagamin wrote:
> I think, it's better to diagnose, what problem the program encounters,
> than to explain, what happens in kernel and glibc.
> The first step is to see, where it hangs and get a stacktrace.
this way of thinking is exactly why i recommend to avoi
On Thursday, 19 February 2015 at 21:34:57 UTC, John Colvin wrote:
I would duplicate the declaration, once without extern(C++),
once with, the use the .mangleof from the 1st to set the mangle
of the 2nd with pragma(mangle
Yes that would work. But using pragma(mangle) feels so hacky...
On Friday, February 20, 2015 08:25:48 rumbu via Digitalmars-d-learn wrote:
> On Friday, 20 February 2015 at 07:57:17 UTC, Tobias Pankrath
> wrote:
> > What's the reason behind this design?
> >
> > class Super {}
> > class Sub : Super {}
> >
> > void foo(Super[] sup) {}
> >
> > void main() {
> >
On Thursday, 19 February 2015 at 22:12:03 UTC, Steven
Schveighoffer wrote:
I'm not sure what the issue here is, but I don't think forking
is as unstable as you seem to think, or maybe I'm reading this
wrong. I can agree there are many gotchas with forking.
You need to very carefully configure
On Friday, 20 February 2015 at 08:25:49 UTC, rumbu wrote:
On Friday, 20 February 2015 at 07:57:17 UTC, Tobias Pankrath
wrote:
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call f
On Friday, 20 February 2015 at 07:57:17 UTC, Tobias Pankrath
wrote:
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call foo(Super[]) with
arguments (Sub[])
}
Just make the su
I think, it's better to diagnose, what problem the program
encounters, than to explain, what happens in kernel and glibc.
The first step is to see, where it hangs and get a stacktrace.
What's the reason behind this design?
class Super {}
class Sub : Super {}
void foo(Super[] sup) {}
void main() {
Sub[] array;
foo(array); // error, cannot call foo(Super[]) with arguments
(Sub[])
}
43 matches
Mail list logo
