Re: how to determine of a module or any other symbol is visible?
On Monday, 18 June 2018 at 09:28:00 UTC, rikki cattermole wrote:
On 18/06/2018 9:24 PM, Mr.Bingo wrote:
On Monday, 18 June 2018 at 09:10:59 UTC, rikki cattermole
wrote:
This doesn't work with depreciation warnings.
There won't be a way to check for those (I think).
Easier to not worry about them until it turns into errors.
you can try the -de flag:
// foo.d:
deprecated void foo() {}
pragma(msg, __traits(compiles, foo()));
---
dmd foo.d
-> true
dmd -de foo.d
-> false
---
couldn't think of any examples of deprecated visibility to try
though
Re: scope(success) lowered to try-catch ?
On Monday, 18 June 2018 at 03:58:47 UTC, Neia Neutuladh wrote:
...
yeah, at an AST level it makes sense why it was implemented like
this.
it's unfortunate that there's no straightforward way to express
'finally(success) {'.
Re: scope(success) lowered to try-catch ?
On Sunday, 17 June 2018 at 12:10:33 UTC, Nicholas Wilson wrote: I suspect scope(success) is lowered because scope(exit) and scope(failure) are, and that would result in a simpler (compiler) implementation of it. does adding nothrow to main fix it? For dcompute I specifically allow scope(exit|success) because there will never be any exceptions _at all_. If not, please do submit an issue. Also a better error message should be given. nothrow unfortunately doesn't help; i guess I'll file an issue. thanks for your input
scope(success) lowered to try-catch ?
Hello,
I'm not sure whether I'm missing something obvious here, but is
there a reason for scope(success) being lowered to a try-catch
statement?
I would have expected only scope(exit) and scope(failure) to
actually interact with exception handling, while scope(success)
simply places code on the path of normal control flow.
Example (windows x32):
---
// main.d
void main() {
scope(success) {}
}
dmd -betterC main.d
Error: Cannot use try-catch statements with -betterC
---
Regardless of whether -betterC is used, you can see in the
disassembly that having a scope(success) anywhere in the function
causes the SEH prologue to be emitted in the code.
Is there a reason scope(success) needs to set up for exception
handling?
Or is this a bug / potential enhancement ?
Re: Debugging on Windows
On Thursday, 8 February 2018 at 21:09:33 UTC, JN wrote: Hi, is there any way to debug binaries on Windows? I'd at least like to know which line of code made it crash. If it's D code, I get a call trace usually, but if it's a call to a C library, I get a crash and that's it. I am using VSCode and I'd prefer to debug in it if possible, but using other IDEs is a possibility for me if that will help. Other options: I use x64dbg, x32dbg and ollydbg with D. When PDB files are loaded you should get symbol names and line-by-line source file mapping. Currently they don't do much memory analysis though — like getting names of variables on the stack or fields of objects on the heap. With -m64 the linker should already be emitting PDB files that x64dbg will find automatically. With 32-bit OPTLINKed code you need to use cv2pdb on the .exe/.dll to get the PDB file, then olly/x32dbg should find it. WinDBG should work too — which is probably your only choice if you're writing a driver.
Re: Hash table element existence check
On Saturday, 3 September 2016 at 12:33:26 UTC, Illuminati wrote:
On Saturday, 3 September 2016 at 07:44:28 UTC, Cauterite wrote:
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote:
I am trying to create a hash table and would like an
efficient way to be able to know if an element exists to test
for collisions.
Just do a regular lookup on the hash? It's an O(1) operation,
like 4 instructions.
Huh? One can look up fine, but how does one know if the result
is valid or not?
Okay I think I misinterpreted the question. I believe when I did
this my solution was to have an additional template parameter
specifying null key values, so the template was like this:
struct HashTbl(
K, /* key type */
V, /* value type */
K NullKey, /* key placeholder value */
alias hash_key, /* hash function */
alias keys_eq /* equality function */
) {...
I guess this doesn't really solve the problem, but makes it the
user's problem.
I could keep a bitarray, but wasting around 12% space.
That assumes your (K,V) tuples are 1 byte total, right?
Re: Hash table element existence check
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. Just do a regular lookup on the hash? It's an O(1) operation, like 4 instructions.
Re: Equivalent of FirstOrDefault with ranges
On Friday, 2 September 2016 at 06:56:07 UTC, Lutger wrote:
You could do:
names.find("bob").chain(only(``)).front;
It's not very expressive though.
testing for deprecation
How does one test whether a symbol is deprecated? I would have
expected something like: __traits(isDeprecated, foo).
In the compiler we have Dsymbol.isDeprecated, is that not
accessible in any way from code?
The only solution I can think of is compiling with -de and using
__traits(compiles, {alias x = foo;})
which actually does seem to work. Pretty lousy though.
Re: Debug prints in @nogc
On Wednesday, 31 August 2016 at 16:17:51 UTC, Yuxuan Shui wrote: No. When you use assumeUnique, you know something the compiler does know, and have to use assumeUnique to tell the compiler that (at least when you use it correctly). But when you use assumeNogc, it's always because you want to bypass compiler checks. assumeNogc works the same way, you're telling the compiler something it doesn't know — that the function should be treated as @nogc. Using assumeNogc on a function that calls the GC is as unsafe as using assumeUnique on a reference that is not unique.
Re: Multi-threading how-to
On Wednesday, 31 August 2016 at 17:37:25 UTC, solidstate1991 wrote: I decided to add a functionality that if multiple programs use the same instance of the library on the same computer, the messages will be passed directly instead of via networking. What you're describing here is not actually multi-threading, it's multi-process…ing. The keyword you're looking for is "inter-process communication". You have a huge range of possible options for implementing this. Your decision would depend on your operating system, your existing implementation with sockets, and desired performance. My suggestion: try just using sockets between processes on the same PC. You might not even need to add any new code to support this method, and it might be faster than you'd expect.
Re: Debug prints in @nogc
On Wednesday, 31 August 2016 at 15:10:11 UTC, Seb wrote: AssumeNogc is potentially dangerous, so I don't know whether it can make it directly, but only if you try you know ;-) So is assumeUnique
Re: D to C++
On Wednesday, 31 August 2016 at 11:43:12 UTC, Nick wrote: That's quite nice, but not what I'm looking for. What Calypso does, as far as I can see, is to make it possible to compile C++ and D together. I'm looking for a compiler that takes in D code and spits out either C or C++ code. Your best option would be to use LDC with a C backend: https://www.google.com/search?q=llvm++c+backend No idea how well supported this is, I've never used LLVM myself.
Re: Debug prints in @nogc
On Tuesday, 30 August 2016 at 14:38:47 UTC, Nordlöw wrote: Just being able to print a string is not good enough. I want the variadic part writeln so I can debug-print values in my buggy code. Do you have a similar solution? Take a look at the example here: http://dlang.org/phobos/std_traits#SetFunctionAttributes You could make a `assumeNogc` template similar to the example `assumePure`. Oh yeah, here's one I prepared earlier: https://dpaste.dzfl.pl/254a5c2697a7
Re: Does D have anything like the generators of Python and some other languages?
On Monday, 29 August 2016 at 21:24:52 UTC, A D dev wrote: Hi group, Does D have anything like the generators of Python and some other languages? Thanks. Ranges serve some of the purposes that generators are often used for: http://dlang.org/phobos/std_range.html But you can of course make true coroutine-based generators with fibres: http://dlang.org/phobos/core_thread.html#.Fiber "fibre" is basically a synonym of "coroutine".
Re: Unicode function name? ∩
On Monday, 29 August 2016 at 12:53:26 UTC, Jesper Tholstrup wrote:
Personally, I would prefer 'intersect' as a function name over
'∩' anytime.
Which benifits does the symbols add?
Sounds like you'd love Java.
x = new BigDecimal("0.1")
x.negate().divide(y).compareTo(z)
who needs symbols? >_>
Re: Unicode function name? ∩
On Sunday, 28 August 2016 at 05:21:03 UTC, Tofu Ninja wrote: Are unicode function names not supported in dmd? Here's a few ANSI characters you can use (and can type with alt-codes): ª º · Ø ø µ ƒ I use º pretty often, it makes a nice sigil.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Saturday, 27 August 2016 at 01:06:53 UTC, Illuminati wrote: Surely one of the many intelligent people on this forum should be able to implement some of the basic structures fairly quickly? Most of these people are happy to use the GC, so @nogc structures are not a priority.
Re: Proper concurrent nearly lock free efficient nogc storage structures?
On Friday, 26 August 2016 at 23:38:02 UTC, Illuminati wrote: Does D have any such thing? I'm having to recreate the wheel here and it isn't fun ;/ Getting in the way of real work ;/ @nogc is such a new language feature that you can't expect a lot of support yet from e.g. the standard library. But in any case, Phobos is a very minimal library when it comes to data structures, for better or for worse. I personally hate to say it. However if you don't have your eye on Phobos, disregard my response, it was hard to tell from your question.
Re: Does D have any construct like Python's with keyword?
On Friday, 26 August 2016 at 23:28:27 UTC, pineapple wrote:
I've grown to very much appreciate how context initialization
and teardown can be very conveniently handled using `with` in
Python. Is there any clean way to imitate this syntax in D?
Yep, scope guards.
auto p = OpenProcess(...);
scope(exit) {CloseHandle(p);};
Re: using .init reliably
On Friday, 26 August 2016 at 15:14:42 UTC, Steven Schveighoffer wrote: FYI, you cannot make this patch until we fully deprecate the use of TypeInfo.init: https://github.com/dlang/druntime/blob/master/src/object.d#L294 So at least until 2.075. -Steve Ah yes, good thinking. I'll keep that in mind.
Re: using .init reliably
On Friday, 26 August 2016 at 09:48:00 UTC, Jonathan M Davis wrote: And I expect that it will become an error at some point in the future to define an init member for a user-defined type, at which point, there won't be any choice about fixing it. I might take a crack at this patch. Sounds pretty trivial.
using .init reliably
How can I get the initial value of an arbitrary type? Since any
struct can override it, .init is not reliable:
struct Z {
enum init = 6;
string val = `asdf`;
};
assert(Z.init == 6);
assert(typeof(Z()).init == 6);
I know I could use
*(cast(Z*) typeid(Z).initializer.ptr)
but that doesn't work in CTFE (because the typeinfo doesn't exist
yet).
Z() is obviously not reliable either since it can override static
opCall.
Re: nested enum
On Thursday, 25 August 2016 at 10:36:21 UTC, Daniel Kozak wrote: Btw, tehre is no need for extra semicolon (`;`) after enum and struct definition Thanks. This forum insists on reminding me every time I write code here.
Re: nested enum
On Wednesday, 24 August 2016 at 23:04:25 UTC, Illuminati wrote:
Well those other answers aren't wrong, but I envisioned that
you'd have multiple categories within your sub-enums and whatnot,
so you'd need something more like this:
struct A {
enum X {
one,
two,
three,
};
enum Y {
four = X.max + 1,
five,
six,
};
enum Z {
seven = Y.max + 1,
eight,
nine,
};
};
Continuing each enumeration from the end of the previous ensures
you won't get any fields with the same values.
Re: Float values are wrong in union
On Monday, 22 August 2016 at 04:37:50 UTC, stunaep wrote: I made a union to convert between int bits and floats, but the values are coming out wrong sometimes. I can already tell what this is going to be... The problem is almost certainly nothing to do with your union, it's this line: float t2 = t.f; This will load 0x7fb0 into ST(0), which instantly converts it to 7FF0 because it's a signalling NaN, then store ST(0) in your float `t2`. Signalling NaNs are an ongoing problem in D's codegen. See Don's remarks at this page: https://issues.dlang.org/show_bug.cgi?id=16105#c2 The reason it works in other languages is because they don't place floats in the floating point registers for non-arithmetic operations. I've been trying to patch DMD's backend to behave this way too, but it's much harder than I expected (difficult codebase to understand/navigate).
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 18:31:26 UTC, Zane wrote: I see - That makes sense, but is there no way to "pause/stop" the GC, but still be able to use the 'new' syntax? Oh you can use `new` when the GC is disabled, no problem. All the GC's functionality is still available. But be careful about what I said with `new` not returning the base of the allocation. It might not be safe to explicitly `free()` memory allocated by `new` if there could be multiple objects in the same memory block. I honestly don't know the facts about this. You can always `GC.free()` memory you've allocated yourself with `GC.malloc()`, so malloc+emplace is an option. You could define a template to give more convenient syntax. Also I think you can overload the `new` operator. I've never tried it. Regarding the marking, I guess my question is: what must be done to ensure something allocated with 'new' will be a candidate for auto-collection later (when GC is enabled)? I don't think it's possible with a conservative garbage collector, because anything that looks like a pointer to your object can prevent it from being collected. However, if there are no actual live pointers to it, the chances that it will be collected are very high, especially on 64-bit systems. So for now, your best bet is to make sure your object is not accessible (set all live pointers to it to null). It will only stay in memory if you're very unlucky. Once we have a precise garbage collector (should be soon) you can be sure an object will get collected if it is not accessible from any live pointers. -- By the way, when I say "live pointer", I mean a pointer which is accessible (through any number of indirections) from the memory roots. e.g. If you have a linked list on the heap, with each node pointing to the next, but no other pointers to any of the nodes (e.g. from the stack) those pointers are not live. The list as a whole is not accessible.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 1) If using the GC, but for whatever reason, I need to free something _right now_, is core.GC.free() the proper way to do this? The main problem is that `new` does not necessarily give you a pointer to the start of an allocation, and `GC.free()` does not work if you give it a pointer to the interior of an allocated block. You could use `GC.addrOf()` to get the base address from an interior pointer, but I don't know whether there could be other objects/arrays sharing the same memory block. If you explicitly allocated the memory block yourself with `GC.malloc()` then you have full control over what is placed in it and can safely `GC.free()` the memory using the base address. Keep in mind, `GC.free()` does not call finalisers.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 5) Is there a way to do simple heap allocation with 'new' while ensuring the GC doesn't deallocate until I want it to? While my earlier suggestion of using malloc/emplace is one option, another is to use `GC.addRoot(objPtr)`. It ensures the object is never deallocated until you call `GC.removeRoot(objPtr)`.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 2) Does calling object.destroy() mean that the object is marked for future collection? If not, how can I ensure it is properly marked. Because the GC is not of the incremental type, it can't perform any marking outside of a stop-the-world mark/sweep cycle. Instead, what `destroy()` does is finalise an object: that is, runs any destructors and puts it in an invalid state — in particular, all pointers contained within the object are nullified, so it doesn't reference any other objects. When I say 'object' I mean anything; class instance, structure, array, primitive, whatever.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 6) If the GC is off, how is allocation/deallocation handled? Can I still use new for example (and how do I dealloc)? All the allocation/deallocation functionality is the same as normal, except the GC won't start a collection cycle unless it's out of memory. You can still use `free()` to deallocate, and it will free memory straight away.
Re: Mem Mgmt: With & Without the GC
On Sunday, 21 August 2016 at 16:14:53 UTC, Zane wrote: 5) Is there a way to do simple heap allocation with 'new' while ensuring the GC doesn't deallocate until I want it to? I can answer this at least, If you don't want the GC to ever collect the object itself, here's the best way: Allocate the object with a non-GC allocator (such as std.c.malloc ), then use `emplace` to construct the object in that memory ( http://dlang.org/phobos/std_conv.html#.emplace ).
Re: MurmurHash3 behaviour
On Friday, 19 August 2016 at 21:03:22 UTC, Seb wrote: http://dlang.org/phobos-prerelease/std_digest_murmurhash.html Ah great, I just finished writing my own murmurhash digest module ( https://github.com/Cauterite/phobos/blob/murmur/std/digest/murmur.d ), and now I discover someone's already done it. Glad I wasted the last 3 hours of my life ;_;
MurmurHash3 behaviour
Regarding the MurmurHash3 implementation in core.internal.hash, it is my understanding that: // assuming a and b are uints bytesHash([a, b], 0) == bytesHash([b], bytesHash([a], 0)) Is this correct? I'm just not quite certain of this property when I try to read the code myself, and I don't know much about hash algorithms.
Re: having a trivial anonymous function call in template prevents compilation?
On Wednesday, 17 August 2016 at 13:33:26 UTC, Steven Schveighoffer wrote: I think the OP's case is a bug. Please file. Thanks, I've filed it. Just wanted to get a second opinion before concluding that it's a bug.
Re: having a trivial anonymous function call in template prevents compilation?
On Wednesday, 17 August 2016 at 13:18:06 UTC, Adam D. Ruppe wrote:
Best you can do is use them in an alias argument directly, but
you cannot use them in an enum argument.
I think you missed the point; it works perfectly fine without
having this `({return 0;})()` in the template body (which, as far
as I can see, doesn't appear to interact at all with the template
argument).
having a trivial anonymous function call in template prevents compilation?
// -- Example: --
template A(alias Arg) {
enum A = Arg;
enum Unrelated = ({return 0;})(); // this line prevent
compilation
};
void main() {
enum FnPtr =
enum _ = A!FnPtr;
};
void asdf() {};
// ( https://dpaste.dzfl.pl/79301f12e5fc )
Just by having a random `({return 0;})()` in the template body,
suddenly the template rejects its arguments. I'm so confused, is
this a bug? Or am I missing something?
Re: When does take modify the underlying iterator?
On Tuesday, 16 August 2016 at 21:01:14 UTC, cy wrote: This has also been annoying me lately, so I came up with this workaround: InputRange!T X = inputRangeObject(Src); X.take(6); // remove+return items 0 to 5 X.take(3); // remove+return items 6 to 8
Re: Passing Structs to function like in C
On Sunday, 14 August 2016 at 16:21:58 UTC, D.Rex wrote: so '();' works the same as 'foo.bar();'? with pointers, D automatically rewrites expressions like this: f.fooMethod() to this: (*f).fooMethod() which is why you're able to index an object-pointer-pointer (Foo*) the same way as an object-pointer (Foo). Most built-in D types have value semantics, so it's understandable that you wouldn't expect classes to be reference types. Associative arrays are also reference types, FYI. Structs on the other hand are value types; if you're new to the language make sure you familiarise yourself with the differences between structs and classes.
Re: if static member then call
On Saturday, 13 August 2016 at 18:34:43 UTC, Engine Machine wrote: static if (hasStaticMember!(T, "foo")) Here I suspect you're looking for this: __traits(isStaticFunction, __traits(getMember, T, "foo"))
Re: if static member then call
On Saturday, 13 August 2016 at 18:34:43 UTC, Engine Machine wrote:
auto ref foo(T, Args...)(args)
{
static if (hasStaticMember!(T, "foo"))
return T.foo!(T)(args);
}
Basically I want to forward the *static* call to T if
possible(if foo exists in T). The main problem is actually
calling T.foo as the syntax here doesn't work. I also need to
be able to check to see if a method is static, since I have no
object.
you're probably gonna want something like, if i understand your
question correctly:
return __traits(getMember, T, "foo")(args);
Re: Passing Structs to function like in C
On Saturday, 13 August 2016 at 15:47:51 UTC, D.Rex wrote:
/* memory.d file */
module memory;
import include.linux.sched;/* contains task_struct
definition */
void free_page_tables(task_struct* tsk) {
/* do something with */
}
And to use the method from somewhere else
/* use method.d */
module usemethod;
import include.linux.sched;
import mm.memory;
void some method() {
free_page_tables(*pointer to task_struct*);
}
I hope my explanation is not rambling nonsense.
Cheers.
Yes, you're right. Passing structure pointers to functions is an
extremely common practice in C, because there aren't really any
other compelling options. In D we have things like methods,
classes, 'const ref' params, return-type inference, etc., so
there's usually a better way to achieve the same result.
Re: 'importing' threads — i.e. thread_attachThis()
On Friday, 12 August 2016 at 18:59:35 UTC, Guillaume Piolat wrote: On Friday, 12 August 2016 at 10:45:22 UTC, Cauterite wrote: Thanks, this is very helpful. I already feel much more confident about the idea. My use is definitely the 'whole-lifetime' case, so I might be able to get away with ignoring the `_beginthreadex` business since at this stage I won't be using CRT functions anyway. The only reason I can't run through _beginthreadex normally is because I'm allocating the thread stack myself, which requires use of NtCreateThread.
Re: Passing Structs to function like in C
Thanks colon-nazis, I'll take that into consideration ¬_¬
Re: Passing Structs to function like in C
On Friday, 12 August 2016 at 16:50:43 UTC, ag0aep6g wrote: On 08/12/2016 05:23 PM, Cauterite wrote: No semicolon there, please. Why would I not terminate a declaration with a semi-colon? Why should a declaration not end in a semi-colon just because the last token is a brace? Why should I not tell the lexer precisely where my declaration ends instead of relying on whatever other tokens floating around it not interfering? Why must every thread in this forum contain more posts regarding some irrelevant tangent than posts responding to the original topic?
Re: Passing Structs to function like in C
On Friday, 12 August 2016 at 15:21:22 UTC, D.Rex wrote:
extern unsigned long free_page_tables(struct task_struct * tsk);
extern(C) ulong free_page_tables(task_struct* tsk);
void main() {
task_struct tsk = …… ;
free_page_tables();
};
That should be what you're after?
'importing' threads — i.e. thread_attachThis()
I'm planning on 'importing' a thread into the D runtime using thread_attachThis(), and was just wondering about the potential pitfalls of this process. For example: - Would having an entry function other than core.thread.thread_entryPoint() pose problems? What about during stack unwinding? Should I try to replicate the exception handling code of thread_entryPoint() in my own entry function? - I'm aware of having to invoke rt_moduleTlsCtor() explicitly, but what about rt_moduleTlsDtor() ? Should I again follow thread_entryPoint()'s behaviour here? - How important is it to run the thread though _beginthreadex() ? I know the Microsoft CRT uses _beginthreadex()/_threadstartex() to set up the thread's '_tiddata' object, but since D uses the Digital Mars _beginthreadex (which I don't have source for) I'm not entirely sure what goes on in there. It *appears* to be messing around with a global '__thdtbl' object. - Do I need to call thread_detachThis() when the thread terminates, or can I just wait until the corresponding Thread object gets destroyed by the GC? I'm using DMD on Windows x32 by the way. Thanks for your help.
Re: method static-ness has no effect on the type?
On Monday, 8 August 2016 at 10:21:47 UTC, ag0aep6g wrote: Also thanks for submitting the bug for me.
Re: method static-ness has no effect on the type?
On Monday, 8 August 2016 at 10:05:58 UTC, ag0aep6g wrote:
The first assert compares the return types of f1 and f2. They
both return `void`, so everything's fine there.
I think you're mistaken about this. typeof(S.f1) definitely gives
the type of the function, not of the return. Try it out:
struct S {
void f1(int, string, float) {};
};
static assert(typeof(S.f1).stringof == "void(int, string,
float)");
( https://dpaste.dzfl.pl/cda66002120a )
Re: Tracking memory usage
On Sunday, 7 August 2016 at 00:28:40 UTC, Alfred Pincher wrote:
this is a very nice feature. I hope D has something similar?
If you want to implement that kind of allocation tracking you'll
probably want to use gc_getProxy()+gc_setProxy(). They're global
C functions you can access by declaring:
extern(C) gc.gcinterface.GC gc_getProxy() nothrow;
extern(C) void gc_setProxy(gc.gcinterface.GC);
First call gc_getProxy() to get the real GC instance and save it
somewhere.
Then call gc_setProxy() with your object implementing the GC
interface functions, and in each function forward to the
corresponding function of the real GC instance, after any
statistic-gathering code you want run.
Something like this:
__gshared GC RealGcInstance = gc_getProxy();
__gshared GC MyProxy = new class GC {
// ...
extern(C) void gc_free(void* Ptr) nothrow {
printf("freeing pointer %x\n", Ptr); // or whatever
return RealGcInstance.free(Ptr);
};
// ... etc.
};
gc_setProxy(MyProxy);
I haven't tested this method myself, but it will probably work.
Refer to
https://github.com/dlang/druntime/blob/master/src/gc/proxy.d and
https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d
Also remember that you can't invoke the GC from inside the proxy
functions. Using helper functions marked @nogc might make it
easier to avoid.
method static-ness has no effect on the type?
See: https://dpaste.dzfl.pl/2ec6780d4b25 We have two methods defined, f1 and f2, where f2 is static but they have otherwise identical signatures. We can see from the disassembly that f1 receives a `this` pointer while f2 does not. Yet, typeof() == typeof(). This makes no sense, how can the compiler even know whether to pass a `this` pointer when both methods have same type?
Re: Cannot distinguish between template function wtih 0 args and 1 arg
On Monday, 8 August 2016 at 02:36:24 UTC, Engine Machine wrote: Error: template Mem cannot deduce function from argument types !(cast(eException)1280L, "main.d", 38u, "main.WinMain")(int), candidates are: Mem(T, B = eX, string file = __FILE__, uint line = __LINE__, string func = __FUNCTION__)(size_t bytes) Mem(T, B = eX, string file = __FILE__, uint line = __LINE__, string func = __FUNCTION__)() From this error message it looks like the `B = eX` parameter is not getting matched up against the value `cast(eException)1280L` as you are hoping for. Probably because `1280L` is a value and it's expecting a type. Try replacing it with something like `alias B = eX` or `enum B = eX`.
Re: assert or throw in range members?
On Friday, 5 August 2016 at 10:25:42 UTC, Nordlöw wrote: Should range members front() and back() assert() or throw() on emptyness? I'm pretty sure it's assert() here. The contract is that the caller is responsible for checking emptiness beforehand, and the whole of Phobos is coded around that contract. I think. If it should assert() doesn't that lead to unsafer code in release mode? That's the point of release mode. Omitting superfluous checks based on the assumption that your code is correct (e.g. assumption that the emptiness contract is respected).
Re: Does D have object wrappers for primitives?
On Saturday, 30 July 2016 at 04:12:45 UTC, stunaep wrote: Thank you. This is just what I needed. I am curious though as to why this doesn't work with strings. It would work if I removed immutable from the Boxed constructor but I thought strings were immutable. I get a compiler error 'not callable using a mutable object'. Even marking a string with the immutable keyword has the same result. auto s = new immutable(Boxed!string)(`foo`); what it's saying is that the box itself needs to be immutable. Honestly I don't know why it was even possible to make a mutable box in the first place, when the only constructor is marked `immutable`.
Re: Does D have object wrappers for primitives?
On Friday, 29 July 2016 at 20:26:47 UTC, Ali Çehreli wrote: I was going to suggest Algebraic because it allows arrays of mixed primitive types (wrapped in Algebraic): https://dlang.org/phobos/std_variant.html#.Algebraic Ali It could work, but keep in mind Algebraic is a structure, not an object.
Re: Does D have object wrappers for primitives?
On Friday, 29 July 2016 at 20:13:34 UTC, stunaep wrote:
I have some java code I need to convert and at one point it
uses an Object[] array to store various ints, longs, and
strings. Java has built in Integer and Long classes that wrap
the primitives in an object and strings are already objects.
No, but with a template you could easily make your own:
class Boxed(T) {
T _v;
alias _v this;
this(in T v) immutable {_v = v;};
};
auto i = new Boxed!int(6);
Re: When I should to call destroy?
On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote: But I can't understand if D have GC it should remove objects when their life is finished. When I should to call `destroy`? What would be if I will not call it? `destroy` is mainly about running destructors deterministically. From the source comments: "It's used to destroy an object so that any cleanup which its destructor or finalizer does is done and so that it no longer references any other objects." For example, your object might allocate a large amount of manually-managed memory, and you don't want that allocation laying around until the next GC cycle, so you can use `destroy` to finalise your object as early as possible to release that manually-managed allocation. If you really want to deallocate the object's own memory, you can check out core.memory.GC.query() / core.memory.GC.free().
Re: question about conditional operator (?:)
On Tuesday, 26 July 2016 at 13:09:28 UTC, Richard wrote: Hello all, try using some parentheses: (n%p==0) ? (n/=p) : (p+=1) ;
Re: Static ternary if
On Tuesday, 26 July 2016 at 00:54:59 UTC, Michael Coulombe wrote: If that's ok, then try out std.traits.Select or std.traits.select: https://dlang.org/phobos/std_traits.html#Select Damn, I looked real hard for that template, I knew it existed. I expected it to be in std.meta though.
Re: Static ternary if
On Monday, 25 July 2016 at 02:15:12 UTC, Gorge Jingale wrote:
Is there a static ternary if?
(A == B) ? C : D;
for compile type that works like static if.
You can pretty easily make your own;
template staticIf(bool cond, alias a, alias b) {
static if (cond) {
alias staticIf = a;
} else {
alias staticIf = b;
};
};
The drawback is that there's no 'short-circuiting'; a and b are
both evaluated.
Re: Trouble checking for null-ness
On Monday, 25 July 2016 at 12:47:25 UTC, Cauterite wrote: (!__traits(compiles, r is null) || r !is null) && !r.empty Ah, whoops that's wrong, looks like ketmar had the right idea.
Re: Trouble checking for null-ness
On Monday, 25 July 2016 at 12:37:18 UTC, Bahman Movaqar wrote: But I'm curious; how can I check for a `null` in this case? Well, if you're happy with assertion failure by access violation, you may not even need to check for null, because generally if you try to call .empty on a null pointer you'll get an access violation (killing two birds with one stone). Otherwise you could try (!__traits(compiles, r is null) || r !is null) && !r.empty
Re: debug public release private
On Monday, 25 July 2016 at 04:58:55 UTC, Gorge Jingale wrote:
debug mixin("public"); else mixin("private");
Perhaps you could build a patched DMD which ignores 'private'.
Then when you want to compile with -debug, use this custom DMD,
and use the standard DMD the rest of the time.
I imagine it'd be a pretty simple patch, but I'm not certain.
Re: why does this error out?
Here's the output I get (DMD v2.068.2): [1, 3, 10, 12, 21, 30, 100, 102, 111, 120, 201, 210] core.exception.AssertError@std\range\package.d(4603): Assertion failure
Re: dpaste.dzfl.pl is blocked
On Saturday, 7 November 2015 at 11:25:39 UTC, drug wrote: What are alternatives for it? Thanks. Right here: http://wiki.dlang.org/Online_compilers dpaste.dzfl.pl is the best one though :/
Re: Why my app require MSVCR120.dll?
On Friday, 6 November 2015 at 13:16:46 UTC, Suliman wrote: On Windows 7 it's work fine. On Windows 10 (clean install) it's do not start and require MSVCR120.dll D doesn't make particularly heavy use of the C runtime, so there's a good chance you can link against a different C runtime DLL — preferably one that's always available by default like msvcrt.dll. However I'd start by determining why it works fine on 7 and not on 10. It could be that MSVCR120.dll is in your library search path on your Win7 system for some reason, or perhaps the compiler is somehow choosing to link against a different runtime when compiling on Windows 7. If you don't already have tools to inspect this stuff, PeStudio ( https://www.winitor.com/ ) will be helpful — it can tell you all the load-time dynamic linkage for a given executable (among other things).
Re: D bindings for Bonjour
On Wednesday, 28 October 2015 at 16:04:52 UTC, Vincent R wrote: Hi, I am starting my first project in D and I would like to do a Bonjour(Zeroconf) browser app. My first task is to write a binding to the dns_sd library but I have an issue with the following macro: #define kDNSServiceOutputFlags (kDNSServiceFlagsValidate | kDNSServiceFlagsValidateOptional | kDNSServiceFlagsMoreComing | kDNSServiceFlagsAdd | kDNSServiceFlagsDefault) It justs takes some enum (defined above but not shown here) and do a OR operation on it. How can I express that in D ? Do I need to use a template as shown here http://wiki.dlang.org/D_binding_for_C or a varg function ? Thanks enum kDNSServiceOutputFlags = (kDNSServiceFlagsValidate | kDNSServiceFlagsValidateOptional | kDNSServiceFlagsMoreComing | kDNSServiceFlagsAdd | kDNSServiceFlagsDefault); Good luck :)
Re: How to get DMD to stop littering my source dir with .o files?
The problem is that the compiler and linker are separate programs; the compiler has to generate input for the linker in the form of a file. RDMD automatically cleans up all the .obj garbage, so one solution is to run rdmd --build-only asdf.d Also, the -of flag is a little more readable if you use quotes dmd -of"asdf.exe" asdf.d Yeah, it's totally inconsistent with other flag syntax like -deps=filename On Monday, 26 October 2015 at 11:55:48 UTC, Shriramana Sharma wrote: The subject line says it all. Every time I compile a D file to an executable I get an unwanted .o file and have to manually clean up things.
Re: Does D's GC release memory back to the OS?
On Sunday, 25 October 2015 at 08:56:52 UTC, Jonathan M Davis wrote: It is my understanding that the GC does not normally ever return memory to the OS It seems that it does now. In smallAlloc() and bigAlloc(), if allocation fails it collects garbage and then: if (lowMem) minimize(); On Windows, lowMem is calculated with GlobalMemoryStatus(), and is true if "Less than 5 % of virtual address space available" This is hardly ideal, but better than nothing I guess.
Re: Does D's GC release memory back to the OS?
Correction: you said "the GC does not normally ever return memory" and you're right, because applications do not "normally" consume >95% of their address space.
Re: `clear`ing a dynamic array
I'm afraid what you're asking for is impossible. Because 'a' and
'b' are both slices, they each have their own 'length' field.
When you do 'a = []', you're effectively doing 'a.length = 0'.
There's no way to change 'b.length' through 'a'. To get that
effect, you'd have to do something like this:
int[] a = [1,2,3,4,5];
int[]* b =
a = [];
assert(*b == [] && b.length == 0);
On Saturday, 24 October 2015 at 13:18:26 UTC, Shriramana Sharma
wrote:
Hello. I had first expected that dynamic arrays (slices) would
provide a `.clear()` method but they don't seem to. Obviously I
can always effectively clear an array by assigning an empty
array to it, but this has unwanted consequences that `[]`
actually seems to allocate a new dynamic array and any other
identifiers initially pointing to the same array will still
show the old contents and thus it would no longer test true for
`is` with this array. See the following code:
import std.stdio;
void main()
{
int a[] = [1,2,3,4,5];
int b[] = a;
writeln(a);
writeln(b);
//a.clear();
a = [];
writeln(a);
writeln(b);
}
which outputs:
[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[1, 2, 3, 4, 5]
How to make it so that after clearing `a`, `b` will also point
to the same empty array? IOW the desired output is:
[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]
[]
[]
... and any further items added to `a` should also reflect in
`b`.
Re: What's wrong in this templatized operator overload ?
On Thursday, 22 October 2015 at 04:25:01 UTC, MobPassenger wrote:
On Thursday, 22 October 2015 at 04:01:16 UTC, Mike Parker wrote:
On Thursday, 22 October 2015 at 03:19:49 UTC, MobPassenger
wrote:
code:
---
struct Foo
{
bool opIn_r(T)(T t){return false;}
}
This needs to be marked with const:
struct Foo
{
bool opIn_r(T)(T t) const {return false;}
}
what's the rationale ? what's guaranteed by the qualifier
that's not already true without const ?
`const` just means the function won't mutate the object. `const`
functions can be safely called on mutable, const and immutable
objects. Non-`const` functions can only be called on mutable
objects.
Re: enum to flags
On Tuesday, 29 September 2015 at 03:31:44 UTC, Nicholas Wilson
wrote:
so I have a bunch of enums (0 .. n) that i also want to
represent as flags ( 1 << n foreach n ). Is there anyway to do
this other than a string mixin?
You could cheat with operator overloading:
enum blah {
foo,
bar,
baz,
};
struct EnumToFlags(alias E) {
template opDispatch(string Name) {
enum opDispatch = 1 << __traits(getMember, E, Name);
};
};
alias blahFlags = EnumToFlags!blah;
static assert(blahFlags.foo == (1 << blah.foo));
static assert(blahFlags.bar == (1 << blah.bar));
static assert(blahFlags.baz == (1 << blah.baz));
