 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ...or rather, to /use/ run-time polymorphism, you need to do manual
>> memory management, and manual memory management is infamously hard.
>
> ... or use Boost's (or C++11's) smart pointers.
Wouldn't that mean I'd have to somehow install Boost and tell the IDE
where the hell to find it?
Compared to that, manual memory management sounds trivial. :-P
>>> If you're using MS Visual Studio (or any other sane contemporary C++
>>> IDE), GUI programming is quite easy as well; after all, you have a GUI
>>> builder included.
>>
>> Yeah, but I'm told programming the Win32 APIs directly is incredibly
>> hard.
>
> Sane IDEs don't use the Win32 C API for GUI (or for most anything else
> for that matter); instead, they come with a fancy object-oriented
> framework of libraries hiding all the uglies from you. (MFC used to be
> the thing for MS Visual C++; they have something new by now, same thing
> they use for C#.)
Interesting. Is /that/ why I keep having to install the "VisualStudio
C++ runtime" every few weeks?
> First time I ever wrote a C program that needed graphical output, I
> actually opted for using a printer rather than the computer display,
> because I already knew some PostScript :-P (Later I employed GhostScript
> of course; but only for test runs, as the "display" quality of the A3
> printer was unparalleled :-))
Oh, that's old skool! :-D
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
Suddenly using HTML and HTTP to present a GUI doesn't seem quite so
insane after all...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/06/2012 1:12 PM, Invisible wrote:
> 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
I remember playing "golf" where the graphical display was a printer.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] dev null> wrote:
> >> ...or rather, to /use/ run-time polymorphism, you need to do manual
> >> memory management, and manual memory management is infamously hard.
> >
> > ... or use Boost's (or C++11's) smart pointers.
> Wouldn't that mean I'd have to somehow install Boost and tell the IDE
> where the hell to find it?
> Compared to that, manual memory management sounds trivial. :-P
Just use a compiler that support C++11. You can then use std::shared_ptr
to manage the objects. (If the object doesn't need to be shared, only moved
around, then you can use std::unique_ptr instead, which is more efficient.)
To be fair, though, if your program allocates and deallocates such objects
in large quantities very fast, the Java version will probably be faster than
the C++ version (because memory allocation has been optimized in Java but
not in C++).
(To be clear: It's not the polymorphism that's slow in C++. It's all the
new's and delete's.)
Some applications require runtime polymorphism of objects (GUI programming
being the most prominent example), but in many cases compile-time
polymorphism using templates is enough (and significantly more efficient).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.06.2012 14:12, schrieb Invisible:
>>> ...or rather, to /use/ run-time polymorphism, you need to do manual
>>> memory management, and manual memory management is infamously hard.
>>
>> ... or use Boost's (or C++11's) smart pointers.
>
> Wouldn't that mean I'd have to somehow install Boost and tell the IDE
> where the hell to find it?
As for the smart pointers, actually no - the smart pointers magic is all
header files, so you just need to copy those to a suitable subdirectory
of your own project and add that directory to the list of preprocessor
include directories.
And if you use VS 2010 (or later), it's even as simple as activating the
C++11 (aka "C++0x") features. The C++11 smart pointers are actually
identical to the boost smart pointers, except that they live in a
different namespace.
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:
typedef shared_ptr<FooType> FooPtr; // really helps
FooPtr A(new FooType());
FooPtr B;
B = FooPtr(A); // NOT just "B = A;"
or just
FooPtr B(A);
shared_ptr is complemented with weak_ptr.
>> Sane IDEs don't use the Win32 C API for GUI (or for most anything else
>> for that matter); instead, they come with a fancy object-oriented
>> framework of libraries hiding all the uglies from you. (MFC used to be
>> the thing for MS Visual C++; they have something new by now, same thing
>> they use for C#.)
>
> Interesting. Is /that/ why I keep having to install the "VisualStudio
> C++ runtime" every few weeks?
Not really. That's just the /general/ habit of dynamically-linked
software. Usually the VS C++ Runtime should simply discover that the VS
C++ Runtime is already installed though.
> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> 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.
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).
--
- Warp
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...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.06.2012 16:35, schrieb Warp:
> clipka<ano### [at] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
