All this talk of CTFE and "compile-time", along with the confusion that
arises from conflating everything done by the compiler into the blanket
term "compile-time" makes me want to scream:
https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time
;-)
tl;dr: D's "compile-time"
I'm sorry about bringing this into here instead of DWT's
subforum, but it's somewhat dead and hasn't been getting a lot of
attention. I decided to finally play around with DWT today and
tried to build the example. I got this:
Performing "debug" build using /usr/bin/dmd for x86_64.
dwt:base
On Thursday, 7 June 2018 at 04:58:40 UTC, Jonathan M Davis wrote:
It would be trivial enough to create a wrapper template so that
you can do something like
immutable n = ctfe!(foo());
e.g.
template ctfe(alias value)
{
enum ctfe = value;
}
Would this be equivalent to using static
On Thursday, 7 June 2018 at 19:19:55 UTC, realhet wrote:
Hi,
The following narrow test program works fine when compiled with
DMD to 32bit target:
import std.stdio, core.sys.windows.windows, core.runtime;
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR
On Friday, 8 June 2018 at 00:55:35 UTC, cc wrote:
class CImpl : CCallbackBase {
extern(C++) {
If anyone has any insight to provide it would be greatly
appreciated, thanks!
I've not used any of the C++ interfacing features yet, but my
understanding is the extern(C++) has to apply
On Thursday, 7 June 2018 at 19:19:55 UTC, realhet wrote:
Hi,
The following narrow test program works fine when compiled with
DMD to 32bit target:
import std.stdio, core.sys.windows.windows, core.runtime;
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR
Hello, I'm attempting to interface with the Steam API DLL in D
and running into some trouble working with callbacks. I'm aware
there's already a project here http://derelict-steamworks.dub.pm/
but it seems to have not yet addressed the same issue. Steam
provides ways to poll for whether an
On Thursday, 7 June 2018 at 23:25:45 UTC, Steven Schveighoffer
wrote:
...
The WinMain exported function works alone well and on 32bit it
also does the console.
On 64 I also tried AllocConsole, but fail. I get the Console
handle with GetConsoleHandle, it sends back a nonzero value.
But as I
On 6/7/18 7:16 PM, realhet wrote:
On Thursday, 7 June 2018 at 19:42:05 UTC, Steven Schveighoffer wrote:
Are you just compiling the 32-bit dmd version with default flags?
Yes, no flags at all and it defaults to a 32bit target. I can use the
console and able to make windows, and able to setup an
On Thursday, 7 June 2018 at 19:42:05 UTC, Steven Schveighoffer
wrote:
Are you just compiling the 32-bit dmd version with default
flags?
Yes, no flags at all and it defaults to a 32bit target. I can use
the console and able to make windows, and able to setup an opengl
window too.
The console
On Thursday, 7 June 2018 at 23:08:22 UTC, Steven Schveighoffer
wrote:
On 6/7/18 6:58 PM, DigitalDesigns wrote:
On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer
wrote:
On 6/7/18 5:07 PM, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 =
On 6/7/18 6:58 PM, DigitalDesigns wrote:
On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer wrote:
On 6/7/18 5:07 PM, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
Yep, long-standing issue:
On Thursday, 7 June 2018 at 21:57:17 UTC, Steven Schveighoffer
wrote:
On 6/7/18 5:07 PM, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
Yep, long-standing issue:
https://issues.dlang.org/show_bug.cgi?id=2947
On Thursday, 7 June 2018 at 21:32:54 UTC, Jonathan M Davis wrote:
struct S
{
int* ptr = new int(42);
}
Is that supposed to compile? -> https://run.dlang.io/is/SjUEOu
Error: cannot use non-constant CTFE pointer in an initializer
&[42][0]
On 06/07/2018 11:26 PM, Ethan wrote:
The spec isn't clear on this but it uses the same rules as struct field
initialisation, ie it's defined once and copied to each instance on
creation.
https://dlang.org/spec/struct.html#default_struct_init
It says there that "The default initializers may
On 6/7/18 5:07 PM, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
Yep, long-standing issue: https://issues.dlang.org/show_bug.cgi?id=2947
Almost a decade old!
-Steve
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I don't think most languages allow this, and D used to not allow
it either, but then CTFE got class support and it got enabled. If
you
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to
On Thursday, June 07, 2018 21:07:26 DigitalDesigns via Digitalmars-d-learn
wrote:
> class A;
>
> class B
> {
> A a = new A();
> }
>
> auto b1 = new B();
> auto b2 = new B();
>
> assert(b1.a == b2.a)!!
>
>
> I'm glad I finally found this out! This is not typical behavior
> in most languages is
On Thursday, 7 June 2018 at 21:07:26 UTC, DigitalDesigns wrote:
assert(b1.a == b2.a)!!
The spec isn't clear on this but it uses the same rules as struct
field initialisation, ie it's defined once and copied to each
instance on creation.
On Thursday, June 07, 2018 11:31:13 jmh530 via Digitalmars-d-learn wrote:
> On Wednesday, 6 June 2018 at 22:19:58 UTC, Jonathan M Davis wrote:
> > On Wednesday, June 06, 2018 18:18:16 jmh530 via
> >
> > Digitalmars-d-learn wrote:
> >> On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
class A;
class B
{
A a = new A();
}
auto b1 = new B();
auto b2 = new B();
assert(b1.a == b2.a)!!
I'm glad I finally found this out! This is not typical behavior
in most languages is it?
I'd expect it to be translated to something like
class B
{
A a;
this()
{
a = new
On 6/7/18 3:19 PM, realhet wrote:
Hi,
The following narrow test program works fine when compiled with DMD to
32bit target:
import std.stdio, core.sys.windows.windows, core.runtime;
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int iCmdShow)
{
Hi,
The following narrow test program works fine when compiled with
DMD to 32bit target:
import std.stdio, core.sys.windows.windows, core.runtime;
extern(Windows) int WinMain(HINSTANCE hInstance, HINSTANCE
hPrevInstance, LPSTR lpCmdLine, int iCmdShow)
{
Runtime.initialize;
On Thursday, 7 June 2018 at 12:32:26 UTC, Arafel wrote:
Thanks for all the answers!
Is it possible to register, say, a base class, and have all the
subclasses then registered automatically?
My idea would be to make it as transparent as possible for the
plugin implementation, and also not
On 08/06/2018 12:25 AM, tipdbmp wrote:
What other libraries (if any) are part of Phobos?
That is pretty much it.
Thanks for all the answers!
Is it possible to register, say, a base class, and have all the
subclasses then registered automatically?
My idea would be to make it as transparent as possible for the plugin
implementation, and also not having to depend on it.
A.
There is a library that
What other libraries (if any) are part of Phobos?
On 07/06/2018 11:47 PM, tipdbmp wrote:
The following compiles without pragma(lib, ...):
extern(C) {
const(char)* zlibVersion();
}
void main() {
const(char)* sz = zlibVersion();
}
It has already been compiled in as part of Phobos.
The following compiles without pragma(lib, ...):
extern(C) {
const(char)* zlibVersion();
}
void main() {
const(char)* sz = zlibVersion();
}
On Wednesday, 6 June 2018 at 13:28:02 UTC, Arafel wrote:
I know it might not be the most idiomatic D, but as somebody
with mostly a Java background (with some C and just a bit of
C++) it seems something really straightforward to me:
myObject.getClass().getFields() [2].
Also, I know I could
On Wednesday, 6 June 2018 at 22:19:58 UTC, Jonathan M Davis wrote:
On Wednesday, June 06, 2018 18:18:16 jmh530 via
Digitalmars-d-learn wrote:
On Monday, 4 June 2018 at 03:18:05 UTC, Jonathan M Davis wrote:
> [snip]
>
> If you haven't yet, I'd suggest reading
Would make a good blog series?
On Wednesday, 6 June 2018 at 20:46:22 UTC, InfiniteDimensional
wrote:
I did register the main derived type and everything seems to
work. Why do I have to reset the registered types?
Do you have to reset the registered types? What happens otherwise?
I still can't have a void* in my class
34 matches
Mail list logo
