This escapes a stack reference.
Ins't b supposed to be allocated on the heap?
On Wednesday, July 11, 2012 08:34:28 Tobias Pankrath wrote:
This escapes a stack reference.
Ins't b supposed to be allocated on the heap?
The object is. The reference is not. b is taking the address of the
reference, not the object.
- Jonathan M Davis
On Wednesday, 11 July 2012 at 06:34:29 UTC, Tobias Pankrath wrote:
This escapes a stack reference.
Ins't b supposed to be allocated on the heap?
The Bar instance is, but the pointer to it is not. Making _b a
Rebindable instead of using a pointer (to what effectively is a
pointer to the
On Wednesday, 11 July 2012 at 06:48:59 UTC, David Nadlinger wrote:
On Wednesday, 11 July 2012 at 06:34:29 UTC, Tobias Pankrath
wrote:
This escapes a stack reference.
Ins't b supposed to be allocated on the heap?
The Bar instance is, but the pointer to it is not. Making _b a
Rebindable
On Wednesday, July 11, 2012 09:00:26 Tobias Pankrath wrote:
Bar b = new Bar;
auto b2 = b; // type of b2 is Bar*
So does it meen, that a pointer of type Bar* does not point to
the real object?
It's a pointer to a reference, not to the object.
How do I get such a pointer then and which type
Is there a (compile time) way to check if a template param is null?
static if ( is (T:int) )
else static if ( is(T:long) )
// how to check if T == null ?
On Wednesday, July 11, 2012 09:59:44 Andrea Fontana wrote:
Is there a (compile time) way to check if a template param is null?
static if ( is (T:int) )
else static if ( is(T:long) )
// how to check if T == null ?
Check if its type is typeof(null):
is(T == typeof(null))
-
Whoops I tried typeof(T) == null :)
Il giorno mer, 11/07/2012 alle 01.02 -0700, Jonathan M Davis ha scritto:
On Wednesday, July 11, 2012 09:59:44 Andrea Fontana wrote:
Is there a (compile time) way to check if a template param is null?
static if ( is (T:int) )
else static if (
On Wednesday, 11 July 2012 at 08:56:39 UTC, Artur Skawina wrote:
On 07/11/12 09:00, Tobias Pankrath wrote:
Bar b = new Bar;
auto b2 = b; // type of b2 is Bar*
So does it meen, that a pointer of type Bar* does not point to
the real object?
Yeah, unfortunately.
Can anybody think of a reason
On Wednesday, 11 July 2012 at 09:49:43 UTC, David Nadlinger wrote:
On Wednesday, 11 July 2012 at 08:56:39 UTC, Artur Skawina wrote:
On 07/11/12 09:00, Tobias Pankrath wrote:
Bar b = new Bar;
auto b2 = b; // type of b2 is Bar*
So does it meen, that a pointer of type Bar* does not point
to the
On 07/11/12 11:49, David Nadlinger wrote:
On Wednesday, 11 July 2012 at 08:56:39 UTC, Artur Skawina wrote:
On 07/11/12 09:00, Tobias Pankrath wrote:
Bar b = new Bar;
auto b2 = b; // type of b2 is Bar*
So does it meen, that a pointer of type Bar* does not point to the real
object?
Yeah,
Why this code print five ?
writeln((One, 10, Five));
What does ( ... , ... , ...) means?
On 07/11/2012 02:44 PM, Andrea Fontana wrote:
Why this code print five ?
writeln((One, 10, Five));
What does ( ... , ... , ...) means?
, is the comma operator inherited from C.
a,b means: execute a first, then b, and the result is b.
On Wednesday, 11 July 2012 at 10:00:33 UTC, Tobias Pankrath wrote:
The languages conflates reference and instance type for
classes. See here http://dpaste.dzfl.pl/a55ad2b6 . I wouldn't
say this should change but it is a minor inconsistency I just
stumbled on.
This is not an inconsistency,
On Wednesday, 11 July 2012 at 10:05:40 UTC, Artur Skawina wrote:
Because it doesn't let you have a real pointer to a class.
What is a »real pointer«? Class references are really just
pointers, in a way – you can cast them to void*.
The obvious alternative would be:
auto r = new Bar();
On 07/11/2012 08:52 AM, David Nadlinger wrote:
I fail to see anything inconsistent here.
Most other operations act on the object:
class B
{
// ...
}
auto b = new B();
++b;// on the object
b b; // on the object
// etc.
b; // on the reference
That can be seen as an
On 07/11/12 17:54, David Nadlinger wrote:
On Wednesday, 11 July 2012 at 10:05:40 UTC, Artur Skawina wrote:
Because it doesn't let you have a real pointer to a class.
What is a »real pointer«? Class references are really just pointers, in a way
– you can cast them to void*.
A real pointer
On Tuesday, 10 July 2012 at 19:27:56 UTC, Namespace wrote:
Maybe D need's a readonly keyword.
[...]
Or has D an alternative?
https://github.com/D-Programming-Language/dmd/pull/3
I'm using the deimos libX11 bindings, DMD 2.058 OpenSUSE x86_64.
In Xlibint.d, my linker can't resolve '_XData16' (it's proto is
on line 624 of Xlibint).
Does anyone who knows X11 know what library I should be linking
to for that function? Or an easy way to grep the symbols in a
directory
On Wednesday, 11 July 2012 at 23:18:25 UTC, cal wrote:
I'm using the deimos libX11 bindings, DMD 2.058 OpenSUSE x86_64.
In Xlibint.d, my linker can't resolve '_XData16' (it's proto is
on line 624 of Xlibint).
Does anyone who knows X11 know what library I should be linking
to for that
I'm fairly new to D, but I have been using C++ for a while now
(about 5 years, selftaught).
From what I have learned, const in C++ is inconsistent.
For example:
int main()
{
const int x = 0; // could be placed in ROM because it's known
at compile time
}
void f(int x)
{
const int y = x
On Thu, Jul 12, 2012 at 02:14:30AM +0200, Minas Mina wrote:
[...]
D has const as well... This is were it becomes a bit tricky for me.
To be honest, I haven't got the book about D - it should(does it?)
have information about that.
You should get the book, it explains all the basic concepts (and
On Wednesday, July 11, 2012 09:51:37 Ali Çehreli wrote:
On 07/11/2012 08:52 AM, David Nadlinger wrote:
I fail to see anything inconsistent here.
Most other operations act on the object:
class B
{
// ...
}
auto b = new B();
++b; // on the object
b b; // on the object
// etc.
On Wednesday, July 11, 2012 23:09:17 Artur Skawina wrote:
The advantages of having pointers to classes? Eg solving the problem that
triggered this thread w/o hacks like ClassPtr (Rebindable is an even worse
hack). [1]
You'd also lose polymorphism, which you don't with Rebindable. In D,
On Wednesday, July 11, 2012 10:56:23 Artur Skawina wrote:
Can anybody think of a reason to keep the current (broken) behavior?
Easily.
Making Object* point to the object itself rather than the reference would be
so broken that it's not even funny. I can understand why you would think that
On Thursday, 12 July 2012 at 00:37:22 UTC, H. S. Teoh wrote:
On Thu, Jul 12, 2012 at 02:14:30AM +0200, Minas Mina wrote:
[...]
** wall o' text **
You forgot about their quantum uncertainty loving transvestite
cousin: inout.
26 matches
Mail list logo
