Re: How do I convert a LPVOID (void*) to string?
Thanks for all answers guys. 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 Yep, I was using solely for Windows error messages. In fact, I was trying to reinvent the wheel of wenforce(). Thanks for point out this. I should have asked if there was a native function for this rather go on and write one myself...
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?
Note thatwith D compilers -debug and -release are not opposed to
each other. A program can have both flags, or none.
Re: is(this : myClass)
But with the current compiler you would never write
is(typeOf(myC) : typeof(c))
if in your mind "c" is actually a class "C" because if that is
in your mind you would just write
is(typeof(myC) : c)
which would get you the error. You only need typeof(variable)
to get to the type, there is no point in doing typeof(type),
you just write type and C is a type. Right?
But what value is evaluating a class type to a primitive type? It
will never be true? There has to be a reasonable chance for the
evaulation to be true for the 'is' operator to provide value. The
compiler should reject this 'is' statement or at minimum issue a
warning of incompatible types. This is nonsense creep of unusable
code (being able to write code that has no meaning and value).
This is equivalent to writing code like the following. It is just
more obfuscated:
if(false)
{
...
}
else
{
...
}
Patrick
Re: is(this : myClass)
On Friday, 20 October 2017 at 23:24:17 UTC, Patrick wrote:
On Friday, 20 October 2017 at 23:01:25 UTC, Steven
Schveighoffer wrote:
On 10/20/17 6:23 PM, Patrick wrote:
On Friday, 20 October 2017 at 22:15:36 UTC, Steven
Schveighoffer wrote:
On 10/20/17 5:55 PM, Patrick wrote:
Due to the very specific nature of the 'is' operator, why
wouldn't the compiler know to implicitly query the class
types? Why must it be explicitly written, typeof(this)?
The compiler generally doesn't "fix" errors for you, it
tells you there is a problem, and then you have to fix it.
You have to be clear and unambiguous to the compiler.
Otherwise debugging would be hell.
Not asking the compiler to fix my errors.
When would
is(this, myClass) not mean: is(typeof(this) :
typeof(myClass))?
class C
{
}
int c;
C myC;
is(myC : c);
oops, forgot to capitalize. But compiler says "I know, you
really meant is(typeof(myC) : typeof(c)) -> false.
-Steve
If I explicitly wrote: is(typeof(myC) : typeof(c)) the outcome
would still be false and it would still require debugging. So
your example demonstrates nothing other then a type-o was made.
Try again...
In this unique case, the compiler should identify the class and
primitive types are incompatible and should issue an error
instead (and not return false).
Patrick
But with the current compiler you would never write
is(typeOf(myC) : typeof(c))
if in your mind "c" is actually a class "C" because if that is in
your mind you would just write
is(typeof(myC) : c)
which would get you the error. You only need typeof(variable) to
get to the type, there is no point in doing typeof(type), you
just write type and C is a type. Right?
Re: Writing some built-in functions for Bash, possible?
On Wednesday, 18 October 2017 at 08:15:53 UTC, evilrat wrote:
[...]
This isn't the actual code but should give you a hint, the rest
is up to you.
Woh Thanks a ton. I can have some working code after a few hours
:D
https://github.com/icy/dusybox/blob/master/lib/dusybox/bash_builtin_hello/package.d
(A screenshot:
https://github.com/icy/dusybox#a-bash-builtin-command)
I got problem with type conversion. I had to use inline
declaration for `long_doc`:
```
extern(C) static builtin dz_hello_struct =
{
name: cast (char*) "dz_hello",
func: _hello_builtin,
flags: BUILTIN_ENABLED,
long_doc: [
"Hello, it's from Dlang.",
"",
"A Hello builtin command written in Dlang."
],
short_doc: cast (char*) "dz_hello",
handle: null
};
```
otherwise the compiler reports that some variable is not be read
at compile time, or kind of `cannot use non-constant CTFE pointer
in an initializer`.
There are many things I need to study from your post. So far it's
good :)
Thanks again
