ok, thanks you very much for the information.
On Saturday, November 04, 2017 01:52:06 Martin via Digitalmars-d-learn
wrote:
> Thank you for the answer
>
> On Saturday, 4 November 2017 at 01:35:41 UTC, Adam D. Ruppe wrote:
> > Why are these ref?
> > Just taking ref away from both of those will likely fix your
> > problems.
>
> because without
Thank you for the answer
On Saturday, 4 November 2017 at 01:35:41 UTC, Adam D. Ruppe wrote:
Why are these ref?
Just taking ref away from both of those will likely fix your
problems.
because without it i get the error "Program exited with code -11"
The thing is, somwhere deeper in `setRelatio
On Saturday, November 04, 2017 01:22:05 Martin via Digitalmars-d-learn
wrote:
> I have a interface
> `interface Node {...}`
>
> and some classes implementing Node:
> ```
> class Text : Node {...}
> class Element : Node {...}
> ```
> and a function like this:
> `public void setRelation(ref Node par
On Saturday, 4 November 2017 at 01:22:05 UTC, Martin wrote:
`public void setRelation(ref Node parent , ref Node child)
Why are these ref?
A lot of people coming from C++ use ref in places you shouldn't
use it in D. Remember, in D, a class object is implicitly ref, so
doing `ref Object` is mo
I have a interface
`interface Node {...}`
and some classes implementing Node:
```
class Text : Node {...}
class Element : Node {...}
```
and a function like this:
`public void setRelation(ref Node parent , ref Node child) {...}`
if i do this it works:
```
Node root = new Element("root");
Node te
On Fri, Nov 03, 2017 at 05:59:20PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn
> wrote:
> > Perhaps the solution is to go the
> > one-overload-set-per-file route, with std/algorithm/package.d
> > basically impo
On Friday, November 03, 2017 16:32:52 H. S. Teoh via Digitalmars-d-learn
wrote:
> Perhaps the solution is to go the
> one-overload-set-per-file route, with std/algorithm/package.d basically
> importing everything underneath. :-P
>
> (Shhh, don't tell Andrei, or we'll get another lecture about wa
On Fri, Nov 03, 2017 at 04:30:21PM -0600, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Friday, November 03, 2017 14:52:22 H. S. Teoh via Digitalmars-d-learn
> wrote:
[...]
> > Arguably, many of these large flat files ought to be split up into
> > smaller files. For example, std.algorithm
On Friday, November 03, 2017 14:52:22 H. S. Teoh via Digitalmars-d-learn
wrote:
> On Fri, Nov 03, 2017 at 05:43:55PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> > On 11/3/17 5:08 PM, Nathan S. wrote:
> > > On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
> > >
On Friday, November 03, 2017 21:23:02 Nathan S. via Digitalmars-d-learn
wrote:
> Is this advice from 2015 outdated? I found it while I was
> wrestling with shared data structures, and after reading I
> stopped doing that.
>
> https://p0nce.github.io/d-idioms/#The-truth-about-shared
>
> >The truth
On Fri, Nov 03, 2017 at 05:43:55PM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
> On 11/3/17 5:08 PM, Nathan S. wrote:
> > On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
> > > Most folks are surprised by this behavior
> >
> > I found it surprising at first but n
On 11/3/17 5:08 PM, Nathan S. wrote:
On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd to me.
None of the benefits of data encapsulation apply to code written five
li
On Fri, Nov 03, 2017 at 09:08:56PM +, Nathan S. via Digitalmars-d-learn
wrote:
> On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis wrote:
> > Most folks are surprised by this behavior
>
> I found it surprising at first but now any other way seems absurd to
> me. None of the benefi
Is this advice from 2015 outdated? I found it while I was
wrestling with shared data structures, and after reading I
stopped doing that.
https://p0nce.github.io/d-idioms/#The-truth-about-shared
The truth about shared
It's unclear when and how shared will be implemented.
Virtually noone use sh
On Friday, 3 November 2017 at 20:01:27 UTC, Jonathan M Davis
wrote:
Most folks are surprised by this behavior
I found it surprising at first but now any other way seems absurd
to me. None of the benefits of data encapsulation apply to code
written five lines away in the same file.
On Friday, November 03, 2017 13:43:15 rikki cattermole via Digitalmars-d-
learn wrote:
> Visibility modifiers like private, and public are to the module not the
> scope.
>
> "Symbols with private visibility can only be accessed from within the
> same module."
>
> This is how module based languages
On Friday, 3 November 2017 at 12:42:29 UTC, ANtlord wrote:
Hello! I can't get how to use double linked list in
concurrency. Please help.
...
I get a compile error onlineapp.d(8): Error: template
std.container.dlist.DList!string.DList.insertFront cannot
deduce function from argument types !()(s
On Friday, 3 November 2017 at 12:24:43 UTC, Guillaume Piolat
wrote:
On Friday, 3 November 2017 at 10:50:27 UTC, Kagamin wrote:
It only looks at the name.
I'll test if that name needs to be "IUnknown" or the exact
"core.sys.windows.unknwn.IUnknown", since I'm in @nogc and not
necessarily on
On Friday, 3 November 2017 at 12:43:15 UTC, rikki cattermole
wrote:
Visibility modifiers like private, and public are to the module
not the scope.
"Symbols with private visibility can only be accessed from
within the same module."
This is how module based languages work, a bit more useful th
On Friday, 3 November 2017 at 12:20:43 UTC, Guillaume Piolat
wrote:
On Friday, 3 November 2017 at 02:30:59 UTC, evilrat wrote:
My guess it will work fine when derive from any
extern(Windows) interface(that's right, not class) that has
base 3 methods(AddRef, Release, QueryInterface)
I'll test
Answering my own questions:
On Thursday, 2 November 2017 at 14:22:56 UTC, Guillaume Piolat
wrote:
Question 1. Is it mandatory to inherit from
core.sys.windows.unknwn.IUnknown, or just having an interface
named "IUnknown" validate it for being a COM interface?
Deriving from an interface named
Hello! I can't get how to use double linked list in concurrency.
Please help.
Providing code
import std.stdio;
import std.container;
synchronized class SocksQueue {
private shared(DList!string) _queue;
public void f(string data) {
this._queue.insertFront(data);
}
}
void
Visibility modifiers like private, and public are to the module not the
scope.
"Symbols with private visibility can only be accessed from within the
same module."
This is how module based languages work, a bit more useful then to the
scope approach IMO. An easy mistake to make.
https://dla
hello, being new to D i assumed that the private keyword would
work as in C++, but writing this code, i excepted it to throw an
error at compile time, it appear to not doing anything, is there
something i am doing wrong ?
--
import std.stdio;
class Foo
{
private int id = 10;
}
struct
On Friday, 3 November 2017 at 10:50:27 UTC, Kagamin wrote:
It only looks at the name.
I'll test if that name needs to be "IUnknown" or the exact
"core.sys.windows.unknwn.IUnknown", since I'm in @nogc and not
necessarily on Windows, so I can't inherit from
core.sys.windows.unknwn.IUnknown (
On Friday, 3 November 2017 at 02:30:59 UTC, evilrat wrote:
You can't(or maybe you can but that is not a true COM). COM is
Windows tech. It is backed up by OLE or whatever server it is.
What happens is that I translate a SDK which provides "COM-like"
objects, on Windows and Mac (claiming ABI co
On Thursday, 2 November 2017 at 14:22:56 UTC, Guillaume Piolat
wrote:
Question 1. Is it mandatory to inherit from
core.sys.windows.unknwn.IUnknown, or just having an interface
named "IUnknown" validate it for being a COM interface?
If yes, then how am I supposed to use COM interfaces in
ot
28 matches
Mail list logo
