I have a 2 questions.
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln("Test CTor.");
}
this(this) {
writeln("Test Copy CTor");
}
~this() {
writeln("Test DTor");
On 07/19/2012 02:27 PM, Namespace wrote:
> I have a 2 questions.
>
> I have this code:
>
> [code]
> import std.stdio;
>
> struct Test {
> public:
> this(int i = 0) {
> writeln("Test CTor.");
> }
>
> this(this) {
> writeln("Test Copy CTor");
> }
>
> ~this() {
Is there any way to avoid the implizit copy ctor by array
concatenation?
Or is the only way to use a pointer?
On 07/19/2012 03:00 PM, Namespace wrote:
> Is there any way to avoid the implizit copy ctor by array concatenation?
> Or is the only way to use a pointer?
Yes, in some way you have to. If you want to not copy a lot of data (or
avoid additional on-copy effort) you either have to you pointers
explic
Ok, so if a put a struct into an array, it will copied into the
array. But then? How it is deleted?
For exmaple, i have this code:
[code]
import std.stdio;
struct Test {
public:
static uint _counter;
this(int i = 0) {
writeln("Test CTor.");
_co
Use std.algorithm.move if you want to avoid the copy ctor call.
On Thursday, 19 July 2012 at 14:31:02 UTC, Timon Gehr wrote:
Use std.algorithm.move if you want to avoid the copy ctor call.
With "move" I see the lost DTor call, but not without. Ist that a
bug? o.O
On Thursday, 19 July 2012 at 15:36:01 UTC, Namespace wrote:
_counter is still 1 but the scope is released. How is that
possible?
Even with _arr.clear(); at the end of the scope, _counter is
still 1.
I see one CTor and one Copy CTor but only one DTor.
_arr is actually a dynamic array, which al
New question:
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln("CTOR");
}
this(this) {
writeln("COPY CTOR");
}
~this() {
writeln("DTOR");
}
}
void main() {
On Fri, 20 Jul 2012 14:50:19 +0100, Namespace
wrote:
New question:
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln("CTOR");
}
this(this) {
writeln("COPY CTOR");
}
~this() {
For correctness:
A copy call is still fine if I assign a local variable to _arr
(even if i think that ref parameters should'nt be copied), but i
think that it is not fine if I assign directly, as you see above.
Does:
_arr[0] = Test(0);
avoid the copy construction?
R
[code]
void main() {
Test[2] _arr = void;
_arr[0] = Test(0);
writeln("end main");
}
[/code]
puts
CTOR
DTOR
end main
DTOR
DTOR
If i wrote Test[] instead of Test[2] i get an exception.
There is no dynamic way f
On Friday, July 20, 2012 15:50:19 Namespace wrote:
> Why on earth?
http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move-
semantics
If you want to guarantee that you don't get any copies while moving an object
around, it needs to be a reference type (which would includ
On Friday, 20 July 2012 at 13:50:20 UTC, Namespace wrote:
New question:
I have this code:
[code]
import std.stdio;
struct Test {
public:
this(int i = 0) {
writeln("CTOR");
}
Be careful about "int i = O". Structs are not allowed to have
default constructors. Th
On Friday, July 20, 2012 08:08:47 Jonathan M Davis wrote:
> On Friday, July 20, 2012 15:50:19 Namespace wrote:
> > Why on earth?
>
> http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move
> - semantics
>
> If you want to guarantee that you don't get any copies while movi
If i @disable the postblit i get a strange behaviour:
[code]
struct Test {
public:
int _id;
this(int i) {
_id = i;
writeln("CTOR");
}
@disable
this(this);
~this() {
writeln("DTOR");
}
}
vo
On Friday, 20 July 2012 at 16:02:18 UTC, Namespace wrote:
If i @disable the postblit i get a strange behaviour:
@disable
this(this);
I think @disable is broken right now, and does nothing (ei:
allows a default implementation of this(this) ).
If you replace by the C++ "declar
It seems structs are very broken right now...
I would use classes, but they are nullable and without
correct/good error handling instead of "access violation" i
prefer structs.
Funny, all variables are default initialized which would be even
done by the OS. But Null Exceptions aren't exists and
On 07/20/2012 09:02 AM, Namespace wrote:
> If i @disable the postblit i get a strange behaviour:
Something is not right. Compiled with dmd 2.059, the linker says:
undefined reference to `_D6deneme4Test10__postblitMFZv'
64 bit Linux...
Ali
Something else which is against classes: incorrect scope
behaviour:
[code]
import std.stdio;
class TestC {
public:
this() {
writeln("CTOR class");
}
~this() {
writeln("DTOR class");
}
}
struct TestS {
public:
this(int i) {
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
Why comes "DTOR class" _after_ "end main" and not before?
If i write "scope TestC c = ...;" it is correct, but i read that
"scope" will be deprecated. Can someone explain me that
behaviour?
The destructor will be invoked when the GC col
On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote:
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
Why comes "DTOR class" _after_ "end main" and not before?
If i write "scope TestC c = ...;" it is correct, but i read
that
"scope" will be deprecated. Can someone explain me
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
Something else which is against classes: incorrect scope
behaviour:
[code]
import std.stdio;
class TestC {
public:
this() {
writeln("CTOR class");
}
~this() {
writeln("DTOR class")
On 07/20/2012 02:54 PM, Namespace wrote:
On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote:
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
Why comes "DTOR class" _after_ "end main" and not before?
If i write "scope TestC c = ...;" it is correct, but i read that
"scope" w
That happens because the destructor is being called when Garbage
collector is cleaning the memory used by the class instance.
How can i call the DTOR or at least a Release method after end of
scope?
Optimally automatic without any explicit calls.
On Friday, 20 July 2012 at 21:54:05 UTC, Namespace wrote:
On Friday, 20 July 2012 at 21:51:02 UTC, David Nadlinger wrote:
On Friday, 20 July 2012 at 21:41:45 UTC, Namespace wrote:
Why comes "DTOR class" _after_ "end main" and not before?
If i write "scope TestC c = ...;" it is correct, but i re
On Saturday, July 21, 2012 00:04:21 Namespace wrote:
> > That happens because the destructor is being called when Garbage
> > collector is cleaning the memory used by the class instance.
>
> How can i call the DTOR or at least a Release method after end of
> scope?
> Optimally automatic without an
On Friday, 20 July 2012 at 16:02:18 UTC, Namespace wrote:
If i @disable the postblit i get a strange behaviour:
[code]
struct Test {
public:
int _id;
this(int i) {
_id = i;
writeln("CTOR");
}
@disable
this(this);
That's great. Hope 2.060 fixes many errors, especially in structs.
BTW: When comes 20060? I thought dmd versions come in cycles of
2-3 months?
On Saturday, July 21, 2012 22:18:40 Namespace wrote:
> That's great. Hope 2.060 fixes many errors, especially in structs.
> BTW: When comes 20060? I thought dmd versions come in cycles of
> 2-3 months?
Usually, they do, but Walter got caught up in working on COFF support for
Windows and there's n
Ok. I hope it will not take months. :/
BTW:
I have a new strange behaviour by experiementing with structs.
This code http://dpaste.dzfl.pl/new#top
works fine, as long as i don't do _any_ operation after line 91.
If i activate one of the out comment operations or something
else, the program work
I have tried various compiler flag combinations, even without.
But it still crashes. Seems to be a Windows bug.
On Saturday, 21 July 2012 at 20:48:16 UTC, Namespace wrote:
I have tried various compiler flag combinations, even without.
But it still crashes. Seems to be a Windows bug.
I'm stupid... I only compiles but not save my paste.
Here is the Code:
http://dpaste.dzfl.pl/d385c56b
On Saturday, July 21, 2012 22:41:10 Namespace wrote:
> Ok. I hope it will not take months. :/
Well, it's looking like it's going to take at least a month or two, but we'll
see. It'll likely depend on how quickly Walter can complete what he's working
on. He could have it done by the end of the mo
I'm not sure if it's a bug or my code is nonsense. ;)
On 07/21/2012 01:41 PM, Namespace wrote:
Ok. I hope it will not take months. :/
BTW:
I have a new strange behaviour by experiementing with structs.
This code http://dpaste.dzfl.pl/new#top
works fine, as long as i don't do _any_ operation after line 91.
If i activate one of the out comment opera
Cool. Any idea how to fix it?
Check whether this._ptr! is null && *this._ptr! is null does not
help.
Although I'm just experimenting, but it would be nice to have a
solution.
First, my earlier writeln("exit main"); wasn't achieving much without
putting everything before it in a scope (like it is below).
On 07/21/2012 03:12 PM, Namespace wrote:
> Cool. Any idea how to fix it?
> Check whether this._ptr! is null && *this._ptr! is null does not help.
> Although I'm just
The strange constructs in std.algorithm aren't something i like
to use in real projects. Is there some other solution?
On Sunday, July 22, 2012 09:48:39 Namespace wrote:
> The strange constructs in std.algorithm aren't something i like
> to use in real projects. Is there some other solution?
And what's so strange about them? That they use ranges? If you start avoiding
ranges, you're going to be missing out on a l
On Saturday, 21 July 2012 at 21:12:55 UTC, Namespace wrote:
I'm not sure if it's a bug or my code is nonsense. ;)
While there are some bugs D, you have to realize that D is a
garbage collected language, which means you should not rely on
objects being destructed in a timely fashion (or at all
Yes, C++ was my previous language.
And no, nobody say anything about Ranges. But i doesn't like
stuff who is deprecated as language feature and is rebuild as
std.algorithm construct. It is that simple. :)
On Sunday, July 22, 2012 10:16:25 Namespace wrote:
> Yes, C++ was my previous language.
>
> And no, nobody say anything about Ranges. But i doesn't like
> stuff who is deprecated as language feature and is rebuild as
> std.algorithm construct. It is that simple. :)
std.algorithm doesn't have anyt
Oh yes, i mean std.typecons, not std.algorithm, my bad.
If delete will be deprecated, how can i delete/call dtor of one
of my objects manually?
On Sunday, July 22, 2012 10:46:51 Namespace wrote:
> Oh yes, i mean std.typecons, not std.algorithm, my bad.
>
> If delete will be deprecated, how can i delete/call dtor of one
> of my objects manually?
You're _really_ not supposed to be doing that. If you're dealing with GC
allocated memory, th
The reason for my experiements is just to find a good solution
for Not Null types. :)
As long as they are not implement in std.typecons. Maybe you take
my solution, if i have some. ;)
On 07/22/2012 01:46 AM, Namespace wrote:
> Oh yes, i mean std.typecons, not std.algorithm, my bad.
>
> If delete will be deprecated, how can i delete/call dtor of one of my
> objects manually?
In C++, deleting involves two steps: call the destructor and release the
memory.
It is different in D
On the other hand, calling the destructor is still acceptable
in D because it may be important for the programmer to run the
contents earlier than GC would. clear() does that:
auto t = new Test(f3);
// ...
clear(t);// <-- Run the destructor
Unfortunately it has a bad name, whic
Nice to know. A name like "destroy" or "delete " would be better
i think.
But isn't a solution for the not null problem.
A other question:
How can i check if t is valid, after i call "clear"?
[code]
import std.stdio;
class Test {
public:
this() {
writeln("CTor");
}
~this() {
writeln("DTor");
}
}
void main() {
Test t = new Test();
cl
A other question:
How can i check if t is valid, after i call "clear"?
[code]
import std.stdio;
class Test {
public:
this() {
writeln("CTor");
}
~this() {
writeln("DTor");
}
}
void main() {
Test t = new Test();
cl
On 07/22/2012 09:27 AM, Mafi wrote:
>> Unfortunately it has a bad name, which is going to be changed.
> Really? I thought we have to stay with this name now. In my
> opinion this name is quite bad, especially in the presence of
> UFCS. What is going to be changed to? destroy()?
Yep! :) It shoul
On Sunday, 22 July 2012 at 17:41:33 UTC, Ali Çehreli wrote:
On 07/22/2012 09:27 AM, Mafi wrote:
>> Unfortunately it has a bad name, which is going to be
changed.
> Really? I thought we have to stay with this name now. In my
> opinion this name is quite bad, especially in the presence of
> UFCS.
On 07/22/2012 09:35 AM, Namespace wrote:
> A other question:
> How can i check if t is valid, after i call "clear"?
After the destructor is run, the object itself is put into a strange
state. I amnot really sure about the actual details but I think the
virtual function table is cleared (or perh
On Sunday, July 22, 2012 20:14:20 Namespace wrote:
> On Sunday, 22 July 2012 at 17:41:33 UTC, Ali Çehreli wrote:
> > On 07/22/2012 09:27 AM, Mafi wrote:
> > >> Unfortunately it has a bad name, which is going to be
> >
> > changed.
> >
> > > Really? I thought we have to stay with this name now. In
On Sunday, 22 July 2012 at 18:14:21 UTC, Namespace wrote:
On Sunday, 22 July 2012 at 17:41:33 UTC, Ali Çehreli wrote:
On 07/22/2012 09:27 AM, Mafi wrote:
>> Unfortunately it has a bad name, which is going to be
changed.
> Really? I thought we have to stay with this name now. In my
> opinion th
Works fine. :)
Now my little test case work as expected:
[code]
import std.stdio;
class Test {
public:
this() {
writeln("CTor");
}
~this() {
writeln("DTor");
}
void echo() const {
writeln("Here is Test");
On Sunday, July 22, 2012 20:45:05 monarch_dodra wrote:
> AFAIK, there are no invalid objects in D*. structs don't have
> default constructors, because they all have a compile time "init"
> value which they are filled with when
> "emptied"/"moved"/"cleared". Ergo, even after being "destroyed",
> the
58 matches
Mail list logo
