On Tuesday, 20 November 2018 at 15:46:35 UTC, Adam D. Ruppe wrote:
On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
Because the more you learn about D the less you want to use
classes.
classes rock. You just initialize it. You're supposed to
initialize *everything* anyway.
a fan
On Tuesday, 20 November 2018 at 23:14:27 UTC, Johan Engelen wrote:
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class objects explicit,
which makes it harder to see where the dereference is
Hi,
I translated the CPP example of a windows service to D.
https://docs.microsoft.com/en-us/windows/desktop/Services/svc-cpp
I wonder how can I integrate a vibe.d http server here:
__gshared HANDLE ghSvcStopEvent = NULL;
VOID SvcInit(DWORD dwArgc, LPTSTR* lpszArgv)
{
ghSvcStopEvent = Crea
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you run the program, so
I just don't see it as a big deal. You lose a m
On Wednesday, 21 November 2018 at 10:47:35 UTC, NoMoreBugs wrote:
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe
wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you r
On Wednesday, 21 November 2018 at 11:53:14 UTC, Alex wrote:
Am I misled, or isn't this impossible by design?
´´´
import std.stdio;
import std.random;
class C
{
size_t dummy;
final void baz()
{
if(this is null)
{
wri
Start vibe in another thread and return from ServiceMain, see
https://docs.microsoft.com/en-us/windows/desktop/Services/service-servicemain-function also ideally you should report running state only after vibe initialized, opened sockets and started listening, before that it's not really running.
On Wednesday, 21 November 2018 at 14:21:44 UTC, Kagamin wrote:
A value passed to ref parameter is assumed to be initialized.
C# would reject to call function foo.
This was not my point. I wonder, whether the case, where the
compiler can't figure out the initialization state of an object
is
On Wed, 21 Nov 2018 17:00:29 +, Alex wrote:
> C# wouldn't reject the case above, would it?
C# *would* reject that (you can't call any methods on a null object), but
in D, it compiles and runs and doesn't segfault.
On Wednesday, 21 November 2018 at 10:47:35 UTC, NoMoreBugs wrote:
On Monday, 19 November 2018 at 21:39:22 UTC, Adam D. Ruppe
wrote:
On Monday, 19 November 2018 at 21:23:31 UTC, Jordi Gutiérrez
Hermoso wrote:
What's the reasoning for allowing this?
The mistake is immediately obvious when you r
On Wednesday, 21 November 2018 at 17:09:54 UTC, Neia Neutuladh
wrote:
On Wed, 21 Nov 2018 17:00:29 +, Alex wrote:
C# wouldn't reject the case above, would it?
C# *would* reject that (you can't call any methods on a null
object), but in D, it compiles and runs and doesn't segfault.
No, i
Hi!
I'm trying to build the docs for my project with `dub -b docs`
and dub also generates the docs for the dependencies of my
project.
Is it possible to generate the docs *only* for my code?
Thx!
On Wednesday, 21 November 2018 at 09:20:01 UTC, NoMoreBugs wrote:
On Tuesday, 20 November 2018 at 15:46:35 UTC, Adam D. Ruppe
wrote:
On Tuesday, 20 November 2018 at 13:27:28 UTC, welkam wrote:
Because the more you learn about D the less you want to use
classes.
classes rock. You just initiali
On Wednesday, 21 November 2018 at 15:05:31 UTC, Kagamin wrote:
Start vibe in another thread and return from ServiceMain, see
https://docs.microsoft.com/en-us/windows/desktop/Services/service-servicemain-function also ideally you should report running state only after vibe initialized, opened sock
On Wednesday, 21 November 2018 at 19:24:52 UTC, Antonio Corbi
wrote:
Hi!
I'm trying to build the docs for my project with `dub -b docs`
and dub also generates the docs for the dependencies of my
project.
Is it possible to generate the docs *only* for my code?
Thx!
As far as I understand t
On Wednesday, 21 November 2018 at 17:46:29 UTC, Alex wrote:
compiled against 4.6.1 Framework.
However, of course, there is a NullReferenceException, if c
happens to be null, when calling baz.
So the difference is not the compiler behavior, but just the
runtime behavior...
How could the com
On Wed, 21 Nov 2018 20:15:42 +, welkam wrote:
> In D classes are reference type and unless you mark them as final they
> will have vtable.
Even if you mark your class as final, it has a vtable because it inherits
from Object, which has virtual functions. The ProtoObject proposal is for a
bas
On Wednesday, 21 November 2018 at 09:31:41 UTC, Patrick Schluter
wrote:
On Tuesday, 20 November 2018 at 23:14:27 UTC, Johan Engelen
wrote:
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:
D does not make dereferencing on class
On Wednesday, 21 November 2018 at 07:47:14 UTC, Jonathan M Davis
wrote:
IMHO, requiring something in the spec like "it must segfault
when dereferencing null" as has been suggested before is
probably not a good idea is really getting too specific
(especially considering that some folks have ar
On Wednesday, 21 November 2018 at 03:05:07 UTC, Neia Neutuladh
wrote:
Virtual function calls have to do a dereference to figure out
which potentially overrided function to call.
"have to do a dereference" in terms of "dereference" as language
semantic: yes.
"have to do a dereference" in term
On Wednesday, 21 November 2018 at 21:05:37 UTC, aliak wrote:
On Wednesday, 21 November 2018 at 17:46:29 UTC, Alex wrote:
compiled against 4.6.1 Framework.
However, of course, there is a NullReferenceException, if c
happens to be null, when calling baz.
So the difference is not the compiler b
On Wednesday, 21 November 2018 at 17:11:23 UTC, Stefan Koch wrote:
For _TRIVIAL_cases this is not hard.
But we cannot only worry about trivial cases;
We have to consider _all_ cases.
Therefore we better not emit an error in a trivial case.
Which could lead users to assume that we are detecting
Does anyone have experience with using meson to wrap around a dub
project?
I have a typical dub project, meaning I have a dub dependency but
I want to use meson for two reasons:
1. I want to distribute the application in form of a snap package
(https://snapcraft.io/). Snapcraft does not reco
23 matches
Mail list logo