On Wednesday, 29 March 2017 at 09:50:10 UTC, abad wrote:
Is this on purpose and what's the rationale?
In Andrei's book, chapter 6.9.1 "the non virtual interface (NVI)
idiom" answers your question. It cites this article by Herb
Sutter as the originator of the idea:
http://www.gotw.ca/public
On Wed, Mar 29, 2017 at 11:01:12PM +, Enigma via Digitalmars-d-learn wrote:
> On Wednesday, 29 March 2017 at 21:36:14 UTC, Petar Kirov [ZombineDev] wrote:
> > On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
> > > [...]
> >
> > It looks like you are looking for this:
> > http://dlang
On Wednesday, 29 March 2017 at 21:36:14 UTC, Petar Kirov
[ZombineDev] wrote:
On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
[...]
It looks like you are looking for this:
http://dlang.org/phobos-prerelease/std_experimental_allocator_building_blocks_region.html.
But these seem to
On Wednesday, 29 March 2017 at 19:19:48 UTC, Enigma wrote:
I have a memory buffer allocated using different methods. It is
simply a pointer and a size.
I would like to be able to manage this buffer by treating it as
a memory pool or heap. I think I can use allocators to do this
but not sure h
On 2017-03-29 23:30, Faux Amis wrote:
On 2017-03-29 21:19, Enigma wrote:
I have a memory buffer allocated using different methods. It is simply a
pointer and a size.
Can you maybe just tread it like an array and slice it for allocation?
*treat*
On 2017-03-29 21:19, Enigma wrote:
I have a memory buffer allocated using different methods. It is simply a
pointer and a size.
Can you maybe just tread it like an array and slice it for allocation?
On Wed, Mar 29, 2017 at 11:24:04AM -0700, Jonathan M Davis via
Digitalmars-d-learn wrote:
> On Wednesday, March 29, 2017 10:08:02 abad via Digitalmars-d-learn wrote:
> > Related question, it seems that final methods are allowed in
> > interfaces. Obviously you can't implement them anywhere, so is
I have a memory buffer allocated using different methods. It is
simply a pointer and a size.
I would like to be able to manage this buffer by treating it as a
memory pool or heap. I think I can use allocators to do this but
not sure how.
Effectively I want something like new or malloc but it
On Wednesday, March 29, 2017 10:08:02 abad via Digitalmars-d-learn wrote:
> Related question, it seems that final methods are allowed in
> interfaces. Obviously you can't implement them anywhere, so is
> this also on purpose and on what rationale? :)
If the function is final, it can have an implem
On Wednesday, 29 March 2017 at 05:15:33 UTC, Ali Çehreli wrote:
scope: references in the parameter cannot be escaped
(e.g. assigned to a global variable). Ignored for
parameters with no references
However, it doesn't behave that way. For example, my example
here currently is
On Wednesday, 29 March 2017 at 11:17:48 UTC, abad wrote:
Yes, does make sense. I was looking this from Java 7
perspective where interfaces can't implement any methods.
D did not support them either for much of its history. IIRC, we
got them at some point after Java did.
On Wednesday, 29 March 2017 at 05:15:33 UTC, Ali Çehreli wrote:
[..] How would you change the text there?
scope: references in the parameter cannot be escaped (e.g.
assigned
to a global variable) in @safe code when compiled with
-dip1000.
Ignored for parameters with no referenc
On Wednesday, 29 March 2017 at 05:15:33 UTC, Ali Çehreli wrote:
(More correctly, "scope storage class".)
https://dlang.org/spec/function.html#Parameter
still says
scope: references in the parameter cannot be escaped
(e.g. assigned to a global variable). Ignored for
parame
On Wednesday, 29 March 2017 at 11:06:55 UTC, Petar Kirov
[ZombineDev] wrote:
On Wednesday, 29 March 2017 at 10:12:08 UTC, abad wrote:
On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
Related question, it seems that final methods are allowed in
interfaces. Obviously you can't implement t
On Wednesday, 29 March 2017 at 10:12:08 UTC, abad wrote:
On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
Related question, it seems that final methods are allowed in
interfaces. Obviously you can't implement them anywhere, so is
this also on purpose and on what rationale? :)
So actua
On Wednesday, March 29, 2017 10:08:02 abad via Digitalmars-d-learn wrote:
> Related question, it seems that final methods are allowed in
> interfaces. Obviously you can't implement them anywhere, so is
> this also on purpose and on what rationale? :)
If the function is final, it can have an implem
On Wednesday, 29 March 2017 at 10:08:02 UTC, abad wrote:
Related question, it seems that final methods are allowed in
interfaces. Obviously you can't implement them anywhere, so is
this also on purpose and on what rationale? :)
So actually it's just a question of not catching this mistake
ear
Related question, it seems that final methods are allowed in
interfaces. Obviously you can't implement them anywhere, so is
this also on purpose and on what rationale? :)
On Wednesday, March 29, 2017 10:56:34 rikki cattermole via Digitalmars-d-
learn wrote:
> On 29/03/2017 10:50 AM, abad wrote:
> > This works:
> >
> > class Foo {
> >
> > protected void bar() {
> >
> > writeln("hello from foo");
> >
> > }
> >
> > }
> >
> > void main() {
> >
> > au
Never mind, it's working OK if the class is defined in another
module.
On 29/03/2017 10:50 AM, abad wrote:
This works:
class Foo {
protected void bar() {
writeln("hello from foo");
}
}
void main() {
auto foo = new Foo;
foo.bar();
}
Is this on purpose and what's the rationale?
http://dlang.org/spec/attribute.html#visibility_attributes
"p
This works:
class Foo {
protected void bar() {
writeln("hello from foo");
}
}
void main() {
auto foo = new Foo;
foo.bar();
}
Is this on purpose and what's the rationale?
On Tuesday, 28 March 2017 at 16:30:19 UTC, kinke wrote:
That's a mangling compression scheme (possibly tunable via gcc
options), from
https://github.com/gchatelet/gcc_cpp_mangling_documentation:
To save space a compression scheme is used where symbols that
appears multiple times are then substi
On Tuesday, March 28, 2017 22:15:33 Ali Çehreli via Digitalmars-d-learn
wrote:
> (More correctly, "scope storage class".)
>
>https://dlang.org/spec/function.html#Parameter
>
> still says
>
>scope: references in the parameter cannot be escaped
> (e.g. assigned to a global variable
24 matches
Mail list logo
