Re: Static if on release build
On Friday, 20 October 2017 at 02:36:37 UTC, Fra Mecca wrote:
I can't find any documentation regarding conditional
compilation in release and debug mode.
I have read the page regarding the topicon dlang.org but adding
the snippet below makes no difference when compiling with dub
-b release
{
version(full) {
//do something
} else {
//do something else
}
How can I produce a release version with different parameters
from debug using dub and static if's?
The most close compile condition is
version(assert)
{
// build for testing
}
else
{
// build for release
}
see https://dlang.org/spec/version.html#predefined-versions:
"assertChecks are being emitted for AssertExpressions"
And at the same time
https://dlang.org/dmd-linux.html#switch-release
"compile release version, which means not emitting run-time
checks for contracts and asserts. Array bounds checking is not
done for system and trusted functions, and assertion failures are
undefined behaviour."
Re: Static if on release build
On 20/10/2017 3:36 AM, Fra Mecca wrote:
I can't find any documentation regarding conditional compilation in
release and debug mode.
I have read the page regarding the topicon dlang.org but adding the
snippet below makes no difference when compiling with dub -b release
{
version(full) {
//do something
} else {
//do something else
}
How can I produce a release version with different parameters from debug
using dub and static if's?
Well yeah... full doesn't exist[0].
If debug is turned on:
debug {
} else {
}
That else isn't for 'release'. Release turns on optimizations in the
compiler and disables a few other things like asserts.
If you want to specify a version at the command line use
``-version=MyVersion``. For a debug identifier use ``--debug=MyDebug``
and yes, debug conditions can have identifiers like versions require.
For dub you can specify it via ``versions`` and ``debugVersions``.
[0] https://dlang.org/spec/version.html
[1] http://code.dlang.org/package-format?lang=json
Re: Static if on release build
On Friday, 20 October 2017 at 02:36:37 UTC, Fra Mecca wrote:
I can't find any documentation regarding conditional
compilation in release and debug mode.
I have read the page regarding the topicon dlang.org but adding
the snippet below makes no difference when compiling with dub
-b release
{
version(full) {
//do something
} else {
//do something else
}
How can I produce a release version with different parameters
from debug using dub and static if's?
Take a look at this:
https://dlang.org/spec/version.html#DebugCondition
Static if on release build
I can't find any documentation regarding conditional compilation
in release and debug mode.
I have read the page regarding the topicon dlang.org but adding
the snippet below makes no difference when compiling with dub -b
release
{
version(full) {
//do something
} else {
//do something else
}
How can I produce a release version with different parameters
from debug using dub and static if's?
Re: How do I convert a LPVOID (void*) to string?
On Monday, 16 October 2017 at 21:48:35 UTC, Nieto wrote:
How do I convert/create a D string from LPVOID (void*)?
string GetLastErrorMessage() {
LPVOID lpMsgBuf;
DWORD errorMessageID = GetLastError();
FormatMessageA(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
errorMessageID,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
cast(LPSTR) ,
0, NULL);
return ??
}
If you're using this solely for Windows error messages, the
std.windows.syserror module has a function, sysErrorString, which
wraps it up for you. It also provides a WindowsException you can
throw which, given an Windows error code, will contain a
formatted system error message.
https://dlang.org/phobos/std_windows_syserror.html
Re: How do I convert a LPVOID (void*) to string?
string GetLastErrorMessage() {
wchar* lpMsgBuf;
DWORD errorMessageID = GetLastError();
uint len=FormatMessageW(
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
errorMessageID,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
cast(LPWSTR) ,
0, NULL);
string msg=lpMsgBuf[0..len].to!string;
LocalFree(lpMsgBuf);
return msg;
}
Re: How do I convert a LPVOID (void*) to string?
On Monday, 16 October 2017 at 22:54:32 UTC, Adam D. Ruppe wrote: On Monday, 16 October 2017 at 21:48:35 UTC, Nieto wrote: How do I convert/create a D string from LPVOID (void*)? There is no one answer to this, but for the specific function are are looking at, the ALLOCATE_BUFFER argument means it puts the pointer in the pointer. So the way I'd do it is: char* lpMsgBuf; instead of LPVOID. You might as well keep some type info there; no need to call it VOID yet (it will implicitly cast to that when it is necessary). You still need to cast at the function call point, so the rest remains the same, but you should keep the return value of FormatMessageA. Then, you can do something like this: string s = lpMsgBuf[0 .. returned_value].idup; and it will copy it into the D string. You could also skip that ALLOCATE_BUFFER argument and pass it a buffer yourself, soemthing like: char[400] buffer; auto ret = FormatMessageA( FORMAT_MESSAGE_FROM_SYSTEM | FORMAT_MESSAGE_IGNORE_INSERTS, NULL, errorMessageID, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), buffer.ptr, buffer.length, NULL); return buffer[0 .. ret].idup; would also work. If you will not use this buffer in any other way but as an immutable string slightly better way is to: import std.exception : assumeUnique; return assumeUnique(buffer[0..ret]); This will not allocate another buffer only to copy data to it as immutable.
Re: Containers and arrays with custom memory allocators
On Thursday, 19 October 2017 at 08:47:09 UTC, Per Nordlöw wrote: These are all very performant containers, but currently lack support for std.experimental.allocator. Support for std.experimental.allocator is planned but currently not a priority. EMSI-containers have an elegant integration and will be an inspiration in the process.
Re: Containers and arrays with custom memory allocators
On Thursday, 19 October 2017 at 08:47:09 UTC, Per Nordlöw wrote: explicit via .dup member and when you want to copy or pass by should be: explicit via .dup member and when you want to _move_ from one l-value to another l-value or pass by move
Re: Containers and arrays with custom memory allocators
On Thursday, 19 October 2017 at 08:47:09 UTC, Per Nordlöw wrote: The file hashmap.d provides both a HashSet and HashMap implementation in one go using D's compile-time-code-branching-mechanism `static if`. Correction: I've now broken it up into - https://github.com/nordlow/phobos-next/blob/master/src/hashmap_or_hashset.d - https://github.com/nordlow/phobos-next/blob/master/src/hashset.d - https://github.com/nordlow/phobos-next/blob/master/src/hashmap.d
Re: Containers and arrays with custom memory allocators
On Tuesday, 17 October 2017 at 14:14:19 UTC, Ivan wrote: Hi, I am a C/C++ programmer interested in using D as a replacement for C/C++. I do care a lot about performance and memory management, so I want to use my own (or from std.experimental) memory allocators. Are there any good tutorials or examples about how to use custom memory allocators for arrays and existing containers? Or should I just go ahead and write my own containers that are allocator aware? Thanks. I'm currently working on a set of containers as part of my very general repo https://github.com/nordlow/phobos-next/tree/master/src For instance: - https://github.com/nordlow/phobos-next/blob/master/src/basic_array.d - https://github.com/nordlow/phobos-next/blob/master/src/bitarray.d - https://github.com/nordlow/phobos-next/blob/master/src/static_bitarray.d - https://github.com/nordlow/phobos-next/blob/master/src/fixed_array.d - https://github.com/nordlow/phobos-next/blob/master/src/soa.d - https://github.com/nordlow/phobos-next/blob/master/src/hashmap.d and a lightweight polymorphic container at - https://github.com/nordlow/phobos-next/blob/master/src/variant_arrays.d and a very experimental radix-tree (trie) implementation at - https://github.com/nordlow/phobos-next/blob/master/src/trie.d These are all very performant containers, but currently lack support for std.experimental.allocator. Instead they use C-style allocation (via qualified C-memory management in qcmeman.c). Further they use Rust-like semantics via disabling of copy-construction; `@disable this(this);`. Instead copying (like for EMSI-containers and many others) is forced to be explicit via .dup member and when you want to copy or pass by move use, for instance, import std.algorithm.mutation : move; import basic_array : A = BasicArray; Ai = A!int; auto s = Ai.withLength(10); Ai src, dst; move(src, dst); someFunctionTakingArrayByValue(move(s)); // pass by move The file hashmap.d provides both a HashSet and HashMap implementation in one go using D's compile-time-code-branching-mechanism `static if`. If you want reference semantics (via reference counting) each container can be wrapper in a `std.typecons.RefCounted` for instance as import basic_array : A = BasicArray; alias Ai = A!int; import std.typecons : RefCounted; RefCounted!A x; used here https://github.com/nordlow/phobos-next/blob/master/src/basic_array.d#L1288 Further note that my work has focused heavily on making things `@safe pure nothrow @nogc` via DIP-25/DIP-1000 when possible which is not the case with most other D container libraries I've tried. In some cases I might have made a mistake with my @trusted taggings. Please correct me if that is the case. Also note that DIP-1000 scope analysis doesn't currently kick in correctly in templated containers because of a bug in the compiler. The bug has been filed at bugzilla and my guess is that it will soon be fixed, as making scope analysis more complete is a high priority, at least for Walter Bright. ~master currently builds with both dmd (debug mode only) and ldc2 (both debug and release mode). I'm currently searching for some part of trie.d that currently makes dmd segfault when compiled in release mode with inlining enabled. I think DMD's inlining is the root of the problem so be careful when using trie.d. My preliminary benchmark at https://github.com/nordlow/phobos-next/blob/master/benchmarks/source/app.d compiled with LDC and inlining enabled shows that `HashMap!(uint/ulong, uint/ulong)`'s `insert()` and `contains()` with FNV64 hash is at least 10 times as fast as D's builtin associative arrays on my Intel Haswell laptop.
Re: Containers and arrays with custom memory allocators
On Tuesday, 17 October 2017 at 14:14:19 UTC, Ivan wrote: Hi, I am a C/C++ programmer interested in using D as a replacement for C/C++. I do care a lot about performance and memory management, so I want to use my own (or from std.experimental) memory allocators. Are there any good tutorials or examples about how to use custom memory allocators for arrays and existing containers? Or should I just go ahead and write my own containers that are allocator aware? Thanks. I am still working on it, but given your case it may be useful. https://github.com/FraMecca/D_Libraries_Registry
