On Sunday, November 25, 2012 12:05:36 monarch_dodra wrote:
> AFAIK, there is no "official spec". And even if there was, the
> "de-facto" spec *is* TDPL... minus everything that could have
> changed since it's printing.
The online docs are the official spec. They're just not necessarily complete or
On Sunday, 25 November 2012 at 11:05:37 UTC, monarch_dodra wrote:
AFAIK, there is no "official spec". And even if there was, the
"de-facto" spec *is* TDPL... minus everything that could have
changed since it's printing.
I think TDPL is great, but there is a doc called "D Language
Specificat
On Sunday, 25 November 2012 at 00:12:04 UTC, Rob T wrote:
Thanks for pointing out where the postblit stuff is documented.
When I first started learning the language, I did read that
part a few times over, but I found it frustratingly hard to
grasp. I will re-read that section again.
This sh
On Saturday, 24 November 2012 at 20:47:17 UTC, Era Scarecrow
wrote:
This kind of behavior *really* needs to be documented in
precise detail, it's rather critical to know.
It IS documented. TDPL - pg. 248
[quote]
Thanks for pointing out where the postblit stuff is documented.
When I first st
On Saturday, 24 November 2012 at 20:47:17 UTC, Era Scarecrow
wrote:
On Friday, 23 November 2012 at 22:31:46 UTC, Rob T wrote:
That's VERY interesting indeed and originally I had no idea it
would do this without a custom opAssign at each level.
This kind of behavior *really* needs to be documen
On Friday, 23 November 2012 at 22:31:46 UTC, Rob T wrote:
That's VERY interesting indeed and originally I had no idea it
would do this without a custom opAssign at each level.
This kind of behavior *really* needs to be documented in
precise detail, it's rather critical to know.
It IS docume
On Monday, 19 November 2012 at 12:10:32 UTC, Dan wrote:
[...]
provide it - you do not need an opAssign at all, as your
postblit will be called. I think this is a step up over C++.
The example below prints:
--
Begin assign
postblit A
End assign
--
On Monday, 19 November 2012 at 12:10:32 UTC, Dan wrote:
Just following up to get confirmation. Hopefully Johnathan or
similar expert can follow up.
Here is a strong statement:
If for any struct S you implement a postblit then there is no
need to implement opAssign to get a working assignment
On Monday, 19 November 2012 at 09:37:35 UTC, Jonathan M Davis
wrote:
On Monday, November 19, 2012 10:29:21 Rob T wrote:
the D language specification (which is currently MIA).
The online documentation _is_ the official spec, though it
definitely doesn't
have enough detail to be unambiguous, an
On 11/19/12, Rob T wrote:
> perhaps best
> done using the C libs memcopy function.
I think the safest thing you can do is:
void oldAssign(Type rhs)
{
this.tupleof = rhs.tupleof;
}
On Monday, 19 November 2012 at 05:22:38 UTC, Jonathan M Davis
wrote:
On Monday, November 19, 2012 06:01:55 Rob T wrote:
postblit constructors and opAssign aren't really related. The
postblit
constructor is used when a _new_ instance is being constructed
(it plays the
same role as a copy const
On Monday, November 19, 2012 10:29:21 Rob T wrote:
> the D language specification (which is currently MIA).
The online documentation _is_ the official spec, though it definitely doesn't
have enough detail to be unambiguous, and in some cases, it's not properly up-
to-date.
- Jonathan M Davis
On Monday, 19 November 2012 at 06:32:56 UTC, Jonathan M Davis
wrote:
I'm not sure. Close certainly. But if any member variables
define an opAssign,
then the compiler probably calls them rather than doing a
simple memcpy. I'm
not sure though. If it does, then a memcpy would not exhibit
the same
On Monday, November 19, 2012 07:21:10 Rob T wrote:
> I think you've cleared things up for me.
>
> When I define an opAssign, I'm not really overriding a default
> opAssign, because there is none, instead I'm overriding the
> default behavior which is to perform a memcopy-like operation.
>
> So if
I think you've cleared things up for me.
When I define an opAssign, I'm not really overriding a default
opAssign, because there is none, instead I'm overriding the
default behavior which is to perform a memcopy-like operation.
So if I defined an opAssign function, but for some odd reason I
w
On Monday, November 19, 2012 06:01:55 Rob T wrote:
> I assume that when I define an opAssign, only the opAssign that I
> define gets called, which means there's no blit or postblit being
> called ever again.
>
> I may be thoroughly confused at this point. Is there both a blit
> and a postblit, and
I assume that when I define an opAssign, only the opAssign that I
define gets called, which means there's no blit or postblit being
called ever again.
I may be thoroughly confused at this point. Is there both a blit
and a postblit, and an optional opAssign that when specified will
override bo
On Saturday, November 17, 2012 15:33:48 Kagamin wrote:
> AFAIK, opAssign and postblit are different operators. Postblit is
> called after blit, and opAssign is called instead of blit.
postlbit is making a new copy of an object, whereas opAssign is replacing the
state of a pre-existing object. The
AFAIK, opAssign and postblit are different operators. Postblit is
called after blit, and opAssign is called instead of blit.
On Friday, November 16, 2012 21:31:26 Rob T wrote:
> My understanding is that a struct will have a default postblit
> opAssign. What I want to know is if I can call the default
> opAssign after overriding it, or is it inaccessible?
>
> I know that I do not have to execute the default after
> overr
My understanding is that a struct will have a default postblit
opAssign. What I want to know is if I can call the default
opAssign after overriding it, or is it inaccessible?
I know that I do not have to execute the default after
overriding, but if I can call it, I'd like to know because in
s
21 matches
Mail list logo
