 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.06.2012 16:35, schrieb Warp:
> clipka<ano### [at] anonymous org> wrote:
>> The only caveat not explicitly warned about in the smart pointers
>> documentation is that the smart pointer assignment operator ("=") is
>> implemented as a swap operation, so to create another smart pointer
>> referencing the same object you need to explicitly make use of the smart
>> pointers' copy constructor:
>
> That makes no sense. It would break basically everything if it were like
> that.
That's what I thought when I first saw it (or, rather, imagined to see it).
> You are confusing it with how operator= of some versions of shared_ptr might
> be implemented, in that it internally swaps its contents with a temporary
> that has been initialized with the parameter (this is done to avoid problems
> that would happen when assigning to itself). Externally there's no swapping
> behavior (and there can't be).
Hm... I just re-read the boost shared_ptr assignment specs, and you're
obviously right. How I read that misconception into the docs I have no
idea (it's been unchanged for ages), but for obvious reasons it stuck.
I guess I'm just having a bit of cleanup work in the POV-Ray code cut
out for me...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/06/2012 11:06 AM, Invisible wrote:
> Building the GUI was a somewhat frustrating exercise. The UI painter
> makes it easy enough to draw what you want. Except that the UI painter
> uses the "Windows" look and feel, while the generated code defaults to
> the "Nimbus" look and feel, and AFAIK there is /no way/ to change this.
I forgot to even mention: By default, nothing is resizable. As in, when
you resize the window, the bottom-most pane inherits all the additional
space. And there's no way to make the other regions larger.
To fix this, you have to use a "splitter". And the way it works is
pretty retarded. (In particular, you cannot have, say, a 3-way split.
You can only have nested 2-way splits. Presumably because that made the
library author's job easier. :-P ) It took me ages to get it to actually
work right!
And I still don't know why the text field at the top insists it should
have space for /4 lines/ of text, even if you haven't typed that much
text in. It's very irritating...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I'm told back in the days of the old mainframes, /all/ user output was
>>> through a printer. It literally didn't /have/ a video display /at all/.
>>> So the PRINT command in BASIC? It used to actually *print* stuff! :-D
>>
>> Yup. Heard that, too. Haven't ever seen any proof with my own eyes
>> though, so it must be urban legend :-P
>
> I've personally operated a green-screen terminal where there's a
> 2-second delay between pressing a key and seeing the character on the
> screen because it's a dumb terminal connected over a modem link to a
> mainframe somewhere. After keying in several /very/ cryptic commands,
> the line printer next to be sprang into life. And let me tell you, those
> things are LOUD! I was using it to print benefits cheques for the local
> county council, in around about 1997 or so. I doubt that their
> infrastructure has been modernised since then...
Even most dumb terminal had local screen management. That's why on most
of them you had separate RETURN and ENTER keys. RETURN would simply
move the cursor down one line, and ENTER would transmit the entire page
(or all the filled-in filed, depending on your terminal).
Yes, hitting ENTER on a partially filled-in screen would display the
behaviour you saw, since the host end would simply tell you "hey, you
didn't finish filling this screen!"
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I've personally operated a green-screen terminal where there's a
>> 2-second delay between pressing a key and seeing the character on the
>> screen because it's a dumb terminal connected over a modem link to a
>> mainframe somewhere. After keying in several /very/ cryptic commands,
>> the line printer next to be sprang into life. And let me tell you, those
>> things are LOUD! I was using it to print benefits cheques for the local
>> county council, in around about 1997 or so. I doubt that their
>> infrastructure has been modernised since then...
>
> Even most dumb terminal had local screen management. That's why on most
> of them you had separate RETURN and ENTER keys. RETURN would simply move
> the cursor down one line, and ENTER would transmit the entire page (or
> all the filled-in filed, depending on your terminal).
>
> Yes, hitting ENTER on a partially filled-in screen would display the
> behaviour you saw, since the host end would simply tell you "hey, you
> didn't finish filling this screen!"
This one didn't appear to work that way. The characters literally didn't
appear until a second or so after you typed them. (I have no idea what
it was actually running on, but I assume some kind of modem...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
