Re: Why is this legal?
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/publications/mill18.htm
Re: Memory Allocation
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.org/phobos-prerelease/std_experimental_allocator_building_blocks_region.html. > > But these seem to require passing a mallocator. I simply want to pass > an already allocated region/block/buffer and have the allocators use > it. I will allocate and free on my own. Huh? Where does it say that a mallocator is required? As far as I can tell, you could simply do this: void[] myBuffer = ...; auto allocator = Region!()(myBuffer); auto p = allocator.allocate(...); The default parent allocator is NullAllocator, which does nothing, so that leaves the management of myBuffer entirely up to you. T -- Life would be easier if I had the source code. -- YHL
Re: Memory Allocation
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 require passing a mallocator. I simply want to pass an already allocated region/block/buffer and have the allocators use it. I will allocate and free on my own.
Re: Memory Allocation
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 how. Effectively I want something like new or malloc but it pulls from the memory buffer rather than the program heap. // Allocated once at program start void* FancyBuffer = FancyAlloc(1000); Then when I want to use the buffer I'll do stuff like auto myptr = FancyMalloc(10); FancyFree(myptr); or whatever. The main thing is, I don't want to have to write my own allocator to manage this buffer as it seems that D's allocators would do a better job. I imagine that most of the time the buffer will not have more than one piece of code using it(no overlapping uses) but since I won't be 100% sure, I need allow for the cases where there might be overlapping usage. (else I wouldn't ever have to worry about "allocating or releasing" from it. Thanks. It looks like you are looking for this: http://dlang.org/phobos-prerelease/std_experimental_allocator_building_blocks_region.html.
Re: Memory Allocation
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*
Re: Memory Allocation
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?
Re: Why is this legal?
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 > > this also on purpose and on what rationale? :) > > If the function is final, it can have an implementation. [...] If a function is final, it *must* have an implementation, since there can be no further overrides that would provide one in a derived type. The rationale for allowing final methods in an interface is to provide users of the interface with nice syntactic sugar, e.g., a set of methods that are commonly used together abstracted into a single final method, while requiring subclasses to only implement a smaller number of orthogonal methods that can be used to implement that method. T -- When solving a problem, take care that you do not become part of the problem.
Memory Allocation
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 pulls from the memory buffer rather than the program heap. // Allocated once at program start void* FancyBuffer = FancyAlloc(1000); Then when I want to use the buffer I'll do stuff like auto myptr = FancyMalloc(10); FancyFree(myptr); or whatever. The main thing is, I don't want to have to write my own allocator to manage this buffer as it seems that D's allocators would do a better job. I imagine that most of the time the buffer will not have more than one piece of code using it(no overlapping uses) but since I won't be 100% sure, I need allow for the cases where there might be overlapping usage. (else I wouldn't ever have to worry about "allocating or releasing" from it. Thanks.
Re: Why is this legal?
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 implementation.
interface I
{
final bool foo() { return true; }
}
class C : I
{
}
void main()
{
}
- Jonathan M Davis
Re: What is the state of scope function parameter?
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 a lie because there is no compilation error with 2.073.2: If you break the rules, even if the compiler doesn't actually catch it, you are still writing illegal code and subject to runtime undefined behavior and/or compilation errors in future versions. The compiler DOES use the scope attribute to optimize out heap allocations in some cases now, which means if you use in improperly you are liable for memory corruption. So maybe it should say "must not" instead of "cannot" since you CAN, it is just broken if you do.
Re: Why is this legal?
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.
Re: What is the state of scope function parameter?
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 references.
Re: What is the state of scope function parameter?
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
parameters with no references
However, it doesn't behave that way. For example, my example
here currently is a lie because there is no compilation error
with 2.073.2:
http://ddili.org/ders/d.en/function_parameters.html#ix_function_parameters.scope
What's the truth? How would you change the text there?
Thank you,
Ali
The truth is that almost non of the scope checks are on, unless
you compile with -dip1000:
$ source ~/dlang/dmd-2.073.2/activate
$ dmd ddili_scope_test1.d
$ echo $?
0
$ dmd -dip1000 ddili_scope_test1.d
ddili_scope_test1.d(5): Error: scope variable parameter may not
be returned
Now that's one error, out of two expected, so what's going on
here? As DIP1000 mentions
(https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#safe):
Errors for scope violations are only reported in @safe code.
So if when I changed the code to:
int[] globalSlice;
int[] foo(scope int[] parameter) @safe {
globalSlice = parameter;// ← compilation ERROR
return parameter; // ← compilation ERROR
}
void main() {
int[] slice = [ 10, 20 ];
int[] result = foo(slice);
}
I got:
$ dmd -dip1000 ddili_scope_test1.d
ddili_scope_test1.d(4): Error: scope variable parameter assigned
to non-scope globalSlice
ddili_scope_test1.d(5): Error: scope variable parameter may not
be returned
Just as expected.
Re: Why is this legal?
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 them anywhere, so is this also on purpose and on what rationale? :) So actually it's just a question of not catching this mistake early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall. The idea between `final` functions in interfaces is to provide a default non-overridable implementation. For example: Yes, does make sense. I was looking this from Java 7 perspective where interfaces can't implement any methods.
Re: Why is this legal?
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 actually it's just a question of not catching this mistake
early, because obviously compilation will fail when any class
tries to implement the interface so the end result is ok.
Maybe it _could_ just disallow final methods altogether to
catch the errors earlier. But very minor detail overall.
The idea between `final` functions in interfaces is to provide a
default non-overridable implementation. For example:
interface Lockable
{
void lock();
void unlock();
alias Action = void delegate();
final void performLocked(Action action)
{
lock();
// Ensures that the lock will be released after `action`
// is called, even if throws an exception.
scope(exit) unlock();
action();
}
}
class Mutex : Lockable
{
void lock() { /* ... */ }
void unlock() { /* ... */ }
// Can't override `performLocked` differently
}
A common example is frameworks which provide customization points
for applications through non-final interface functions, but
overall take-over the application control flow:
interface App
{
/// Main application loop
final bool run()
{
init();
while(handleInput())
{
update();
auto frame = render();
// implement somewhere else as a free function
present(frame);
}
return true;
}
/// Initializes the application's resources on startup.
void init();
/// Handles the input.
/// Returns:
/// false - if the app should be closed and true -
otherwise.
bool handleInput();
/// Updates the application state after handling input.
void update();
/// Renders and the next frame into a buffer and
/// returns a reference to it.
Framerender();
}
Other times, it's just for convenience in generic code:
interface SceneDscNode
{
final T get(T)() const
{
static if (isBoolean!T) return getBool();
else static if (isIntegral!T) return getInt.to!T();
else static if (isFloatingPoint!T) return getFloat.to!T();
else static if (isSomeString!T) return getString.to!T();
else static assert(0, "Type not supported: " ~
T.stringof);
}
string getName() const;
SceneDscNode getChild(string propertyName) const;
SceneDscNode[] getChildren() const;
protected:
bool getBool() const;
long getInt() const;
double getFloat() const;
string getString() const;
}
class JsonValueWrapper : SceneDscNode
{
string getName() const { /* ... */ }
SceneDscNode getChild(string propertyName) const { /* ... */ }
SceneDscNode[] getChildren() const { /* ... */ }
protected
{
bool getBool() const { /* ... */ }
long getInt() const { /* ... */ }
double getFloat() const { /* ... */ }
string getString() const { /* ... */ }
}
private JSONValue json;
}
class SdlValueWrapper : SceneDscNode
{
string getName() const { /* ... */ }
SceneDscNode getChild(string propertyName) const { /* ... */ }
SceneDscNode[] getChildren() const { /* ... */ }
protected
{
bool getBool() const { /* ... */ }
long getInt() const { /* ... */ }
double getFloat() const { /* ... */ }
string getString() const { /* ... */ }
}
private const SDLTag sdl;
}
Re: Why is this legal?
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 implementation.
interface I
{
final bool foo() { return true; }
}
class C : I
{
}
void main()
{
}
- Jonathan M Davis
Re: Why is this legal?
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 early, because obviously compilation will fail when any class tries to implement the interface so the end result is ok. Maybe it _could_ just disallow final methods altogether to catch the errors earlier. But very minor detail overall.
Re: Why is this legal?
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? :)
Re: Why is this legal?
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() {
> >
> > auto foo = new Foo;
> > foo.bar();
> >
> > }
> >
> > Is this on purpose and what's the rationale?
>
> http://dlang.org/spec/attribute.html#visibility_attributes
>
> "protected only applies inside classes (and templates as they can be
> mixed in) and means that a symbol can only be seen by members of the
> same module, or by a derived class. If accessing a protected instance
> member through a derived class member function, that member can only be
> accessed for the object instance which can be implicitly cast to the
> same type as ‘this’. protected module members are illegal."
Yeah, everything in a module can see everything else in a module. It avoids
needing to add the complication of friend function and classes like in C++.
Basically, it's like everything within a module were declared as friends. If
you want something to not have access to something else, then it's going to
need to be put in a separate module.
- Jonathan M Davis
Re: Why is this legal?
Never mind, it's working OK if the class is defined in another module.
Re: Why is this legal?
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
"protected only applies inside classes (and templates as they can be
mixed in) and means that a symbol can only be seen by members of the
same module, or by a derived class. If accessing a protected instance
member through a derived class member function, that member can only be
accessed for the object instance which can be implicitly cast to the
same type as ‘this’. protected module members are illegal."
Why is this legal?
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?
Re: C++ namespace mangling: bug or me being stupid?
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 substituted by an item from
the sequence : S_, S0_, S1_, S2_, etc ...
As to nested C++ namespaces - `extern(C++, ns1) { ...
extern(C++, ns2) { ... } }` should work in a single D file.
Not only good to know, this... fixed it. So I was being stupid.
Thanks!
Atila
Re: What is the state of scope function parameter?
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). Ignored for > parameters with no references > > However, it doesn't behave that way. For example, my example here > currently is a lie because there is no compilation error with 2.073.2: > > > http://ddili.org/ders/d.en/function_parameters.html#ix_function_parameters > .scope > > What's the truth? How would you change the text there? > > Thank you, > Ali Not sure when that was changed, since that's not what the spec used to say on scope. IIRC, it used to be that it did not say anything about references and was _very_ vague. But unless something major has changed, _all_ scoped does at this point is make it so that a delegate will not allocate a closure. I'm not sure that it's even properly checked for escaping (though it may be). But scoped has zero effect on other types. Now, I believe that Walter has been working on stuff that would change that, but I don't think that any of that has made it in yet except maybe with a compiler switch intended to separate out the changes until they're ready. - Jonathan M Davis
