Re: is there any way for an object to make it self no longer usable
On Saturday, 19 July 2014 at 12:02:50 UTC, Sean Campbell wrote:
is there any way for an object to make it self no longer
usable? eg
class someclass {
string somevalue;
bool someflag;
int somelength;
this (value,length,flag) {
somevalue = value;
someflag = flag;
somelength = length;
}
void modify_value(string new_value){
somevalue = new_value;
}
void finalize_data(){
//do something with data
//make this invalid
// eg delete this or this = null
}
}
I don't want to use a private flag to tell weather the object
is valid or not
You do realize that if you do this then anywhere in your code
you'll have to check if the object is valid before use? If the
objects lifetime is "random"(because the object itself can decide
when to destroy itself), then there is no way to know when it
will be destroyed.
If you do this you are potentially asking for a lot of access
violation errors or undefined behavior.
In any case, an easy way is to allow the object to allocate and
deallocate itself.
If the object knows the ptr and size that was used to allocate
itself it is trivial to deallocate itself.
http://dlang.org/phobos/core_memory.html
Implement Interface "dynamically"
Is there a way to take an interface and implement it generically? e.g., All functions are implemented either as throw and/or return defaults and properties are implemented as getter/setters. This is for mocking up so I a simple way to create a class based off only the interface. Essentially something similar to whitehole and blackhole except properties are useable. In fact, I suppose it would be nice to have something analogous to them except properties are implemented. Then one could do Blackhole!(Bluehole!C) where Bluehole implements properties as getters and setters.
Re: dustmite build
On Monday, 7 July 2014 at 17:50:35 UTC, Frustrated wrote: when I build dustmite using dmd or gdc with no options or -O3, it is 18M but in the dmd directory, dustmite is only 650k. I assume I'm statically linking the whole library while in the small one is using some dynamic link library? Or is all that debug information or what? Also, how does one use dustmite on a project that invloves many subfolders and uses a library that is specified in the lib path in sc.ini, that also uses many directories? e.g., import a.b.c.d. Say the regression is in the library(worked in one version, new dmd version doesn't work cause it broke something in the library). Is dustmite going to pull in the problematic code from the library or is it too going to just crap out and now show the real problem?
dustmite build
when I build dustmite using dmd or gdc with no options or -O3, it is 18M but in the dmd directory, dustmite is only 650k. I assume I'm statically linking the whole library while in the small one is using some dynamic link library? Or is all that debug information or what?
Re: recursive definition error
On Monday, 7 July 2014 at 09:56:17 UTC, Marc Schütz wrote: On Monday, 7 July 2014 at 02:57:09 UTC, Frustrated wrote: So, I took all the code surrounding the error message(which was a lot of code) and stuck it into one .d file. No errors! Works as expected. So, WTF?!?! I guess now I have to attempt to split the code across modules to see WTF is going on? Maybe this is a modules issue. I know some of the code I'm using deals with module resolution and there was some talk in the main forum about changing something to do with modules. Could this be the issue? D really needs a better fing way to debug templates or improve the error messages. I'm dealing with about 20k lines of code spread across about 100 modules and the error messages are completely useless as when I put all the code surrounding what it says is causing the error, I do not get the error. Realize, this code works fine in 2.064 so it's not a coding issue as if something magical with my fingers when I copy the code from the modules into a single .d file. Either something was "fixed" or something was "broke"... after all the work I spend trying to figure out what was causing the problem, I'm just as clueless. Have you tried dustmite? It can also reduce source code split over several files. Thanks, I'll check it out.
Re: recursive definition error
So, I took all the code surrounding the error message(which was a lot of code) and stuck it into one .d file. No errors! Works as expected. So, WTF?!?! I guess now I have to attempt to split the code across modules to see WTF is going on? Maybe this is a modules issue. I know some of the code I'm using deals with module resolution and there was some talk in the main forum about changing something to do with modules. Could this be the issue? D really needs a better fing way to debug templates or improve the error messages. I'm dealing with about 20k lines of code spread across about 100 modules and the error messages are completely useless as when I put all the code surrounding what it says is causing the error, I do not get the error. Realize, this code works fine in 2.064 so it's not a coding issue as if something magical with my fingers when I copy the code from the modules into a single .d file. Either something was "fixed" or something was "broke"... after all the work I spend trying to figure out what was causing the problem, I'm just as clueless.
Re: recursive definition error
On Friday, 4 July 2014 at 21:15:02 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 20:25:28 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 16:31:28 UTC, Stanislav Blinov wrote:
On Friday, 4 July 2014 at 16:28:48 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 15:42:36 UTC, bearophile wrote:
Frustrated:
I'm not using 2.066 though...
I will revert back to the dmd version I was using when it
worked... Hopefully someone can make sure this is not a
regression in the mean time... (seems like it is and I don't
want to get bit again later on when I upgrade)
That template and its instantiation work fine for me on both
2.065 and 2.066b1.
Ok, I do not know where this error creeped in at. I do know at
one point the code was working fine without any changes I
believe. (it's possible though I messed something up)
The recursive error seems to be the wrong issue. Trying to
diagnose what the problem is now.
This must be some weird issue with Array or a change in what
imports does.
e.g.,
if I do
struct apple(T) { }
template Array(T) { alias apple!T Array; }
Then the code works(except I no longer can use array as an
array but I do not get any recursive issues.
The compiler I was using when it worked might have been pre
2.064... Or possibly something else is going on that breaks the
code.
Best I can tell is that the compiler is getting confused
between std.container.Array and my Array.
This seems to be a regression as it works fine in 2.064. The
error is not directly due to recursion as far as I can tell but
in a template that uses the Array template. Why it breaks the
array I have no idea. I will try to create a minimal project for
it.
Re: recursive definition error
On Friday, 4 July 2014 at 20:25:28 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 16:31:28 UTC, Stanislav Blinov wrote:
On Friday, 4 July 2014 at 16:28:48 UTC, Frustrated wrote:
On Friday, 4 July 2014 at 15:42:36 UTC, bearophile wrote:
Frustrated:
I'm not using 2.066 though...
I will revert back to the dmd version I was using when it
worked... Hopefully someone can make sure this is not a
regression in the mean time... (seems like it is and I don't
want to get bit again later on when I upgrade)
That template and its instantiation work fine for me on both
2.065 and 2.066b1.
Ok, I do not know where this error creeped in at. I do know at
one point the code was working fine without any changes I
believe. (it's possible though I messed something up)
The recursive error seems to be the wrong issue. Trying to
diagnose what the problem is now.
This must be some weird issue with Array or a change in what
imports does.
e.g.,
if I do
struct apple(T) { }
template Array(T) { alias apple!T Array; }
Then the code works(except I no longer can use array as an array
but I do not get any recursive issues.
The compiler I was using when it worked might have been pre
2.064... Or possibly something else is going on that breaks the
code.
Best I can tell is that the compiler is getting confused between
std.container.Array and my Array.
Re: recursive definition error
On Friday, 4 July 2014 at 16:31:28 UTC, Stanislav Blinov wrote: On Friday, 4 July 2014 at 16:28:48 UTC, Frustrated wrote: On Friday, 4 July 2014 at 15:42:36 UTC, bearophile wrote: Frustrated: I'm not using 2.066 though... I will revert back to the dmd version I was using when it worked... Hopefully someone can make sure this is not a regression in the mean time... (seems like it is and I don't want to get bit again later on when I upgrade) That template and its instantiation work fine for me on both 2.065 and 2.066b1. Ok, I do not know where this error creeped in at. I do know at one point the code was working fine without any changes I believe. (it's possible though I messed something up) The recursive error seems to be the wrong issue. Trying to diagnose what the problem is now.
Re: recursive definition error
On Friday, 4 July 2014 at 15:42:36 UTC, bearophile wrote: Frustrated: Since there is no recursion going on there, it shouldn't be a problem. Yes, sorry. In dmd 2.066 this too could work: alias Array(T) = std.container.Array!T; Bye, bearophile That just gives more errors. I'm not using 2.066 though... I will revert back to the dmd version I was using when it worked... Hopefully someone can make sure this is not a regression in the mean time... (seems like it is and I don't want to get bit again later on when I upgrade)
Re: recursive definition error
On Friday, 4 July 2014 at 15:37:52 UTC, Marc Schütz wrote:
On Friday, 4 July 2014 at 15:07:00 UTC, Frustrated wrote:
After upgrading to latest dmd, I get the follow error on the
code
template Array(T) { alias Array = std.container.Array!T; }
Error: Array!(iDataBlock).Array recursive alias declaration
I don't see anything recursive about it... and the code worked
before. Any ideas?
Which version of DMD exactly? This works in DMD git.
I don't remember what I was using before, I think 2.064. I just
upgraded to the latest 2.065.2 today and tried to compile some
old code and got all these errors. The code was working fine
before. Obviously I could have done something that I forgot but
the errors are saying the templates are recursive as if the
method doesn't work, yet it worked fine before.
Re: recursive definition error
On Friday, 4 July 2014 at 15:10:14 UTC, bearophile wrote:
Frustrated:
After upgrading to latest dmd, I get the follow error on the
code
template Array(T) { alias Array = std.container.Array!T; }
Try to use a different name inside the template, like "Vector".
Bye,
bearophile
Huh?
The template is simply wrapping std.container.Array so I can
later on use change it to a different array without breaking code
that uses it. As I said, it worked fine before without this
recursion problem.
Since there is no recursion going on there, it shouldn't be a
problem. This seems like a bug/regression.
An indirection does not help.
recursive definition error
After upgrading to latest dmd, I get the follow error on the code
template Array(T) { alias Array = std.container.Array!T; }
Error: Array!(iDataBlock).Array recursive alias declaration
I don't see anything recursive about it... and the code worked
before. Any ideas?
Re: Structs insted of classes for Performance
On Sunday, 20 April 2014 at 16:56:59 UTC, Ali Çehreli wrote: My understanding is not perfect. There may be compiler and CPU optimizations that I am not aware of. On 04/20/2014 08:03 AM, Frustrated wrote: > is the only argument really about performance when creating > structs vs creating classes Not only creating but also when using. A class variable is a reference to the actual object, implemented by the compiler as a pointer. So, there is that extra indirection overhead to access member variables of a class object. When the class variable and the object are far apart in memory, they may be fall outside of CPU caches. Further, unless they are defined as final or static, class member functions are virtual. Virtual member funtions are dispatched through the virtual function table (vtbl) pointer. So, a call like o.foo() must first hit the class vtbl in memory, read the value of the function pointer off that table and then jump to the function. Related to the above, class objects are larger than struct objects because they have the extra vtbl pointer, as well as another pointer (monitor) that allows every class object to be used as a synchronization item in concurrency. Larger objects are more expensive because less of those can fit in CPU caches. Yes, but this is the standard argument between structs and classes. Obviously the additional benefits of classes cost... else no one would use structs. If structs had inheritance, there would be no real reason for classes. I don't mind the cost of classes because I will try and use them were appropriately. Also, these problems are not language specific but simply because classes are heavier. The article I read was about D's specific issues and that using structs GREATLY sped up certain things... I'm sure it had to do with the GC and all that but can't remember. > Basically that boils down to stack allocation vs heap allocation speed? Not to forget, struct objects can be allocated on the stack as well by std.typecons.scoped. > Which, while allocation on the heap shouldn't be too much slower than > stack, the GC makes it worse? Stack allocation almost does not exist as some location on the stack is reserved for a given object. There is no allocation or deallocation cost at runtime other than certain decisions made by the compiler at compile time. On the other hand, any dynamic allocation and deallocation scheme must do some work to find room for the object at runtime. Ali Again, all those arguments are about the specific difference between a struct and class and apply to all languages that use those types of structures. In D though, I guess because of the GC(but which is why I am asking because I don't know specifically), classes could be much slower due to all the references causing the GC to take longer scan the heap and all that. If allocate or free a lot of classes in a short period of time it also can cause issues IIRC. I just can't remember if there was some other weird reasons why D's classes are, in general, not as performant as they should be. If I remember correctly, I came across a page that compared a few test cases with the GC on and off and there was a huge factor involved showing that the GC had a huge impact on performance.
Structs insted of classes for Performance
I know the difference between a struct and a class but I remember seeing somewhere that structs are much faster than classes in D for some strange reason. I'm not worried too much about class allocation performance because I will try and use classes when they will not be created frequently and structs or class reuse when they will be. So, is the only argument really about performance when creating structs vs creating classes or was there some finer detail I missed? Basically that boils down to stack allocation vs heap allocation speed? Which, while allocation on the heap shouldn't be too much slower than stack, the GC makes it worse?
