Wednesday, June 24, 2020

Digest for comp.lang.c++@googlegroups.com - 5 updates in 3 topics

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 24 05:46PM +0100

On 24/06/2020 15:38, Sam wrote:
 
>>> Proposals for GUI libraries are accepted only from those who have actually written one.
 
>> I have written one, dear.
 
> Do you have a Youtube video, that shows it off? Where's the source repository, I'm curious to look at it, to see if I can pick up some tips, for mine's.
 
https://www.youtube.com/watch?v=KfHtoThyNkA
https://www.youtube.com/watch?v=WiHsFlyLuak
https://neogfx.org/
https://github.com/i42output/neogfx
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say."
Manfred <noname@add.invalid>: Jun 24 08:43PM +0200

On 6/24/2020 5:44 PM, Alf P. Steinbach wrote:
> trick used in Borland's framework, namely a /trampoline function/: a
> kind of pseudo function (as "window procedure") that just put an object
> address in a register and jumped to a common dispatch function.
 
I also seem to remember the peculiar Borland message handler:
 
virtual void onPaint() = WM_PAINT;
 
Bart <bc@freeuk.com>: Jun 24 05:47PM +0100

>> inter-process windowing. Actually there weren't any other processes,
>> only yours.
 
> Its not the mid-80s anymore.
 
So? What worked then /within an application/ will still work now within
an application.
 
> Great, but its not the mid-80s anymore. If you want to do graphics then every
> consumer OS requires you to deal with windows when doing graphics whether you
> like it or not.
 
And you still don't get it. in the same way that you can just print text
to a console without worrying about windowing or multiple consoles for
fonts or anything like that, you can do low-level graphics.
 
This is an extract from Stroutrup's paper listing future directions:
 
* "Support for simple graphics and simple user interaction"
 
That doesn't sound like GTK or WxWidgets to me. Neither does it sound
like using rendering libraries like Cairo or using PS/EPS/PDF.
 
 
The only exception is doing VGA graphics in a linux console
> or running a raw X server with no window manager but they're both frankly of
> little use in this day and age.
 
If such a thing can plot a pixel of a particular colour, then it has
everything needed to do graphics. (In theory; in practice it'll be too
slow for most things, and you will need to build a higher level library.)
 
 
> Thats because - on unix at least - stdout writes to the tty which may or may
> not be linked to a virtual or physical terminal. Normally that terminal will
> be the one you run the program from within but it doesn't have to be the case.
 
Fine, do the graphics via text escapes; it doesn't really matter. (I
used to develop graphics boards, and at least one was driven via a
serial interface.)
 
 
> graphical window in order to kick it off? You might wish that we were still
> in the past with a single output destination but consumer OS's are not like
> that.
 
Windows at least lets you have a handle to the current console such that
you can draw pixel graphics into it. You get results like this:
https://github.com/sal55/langs/blob/master/console.png
 
But I'd recommend creating a separate window. That that can become the
default for pixel-based output.
 
(I'd say that was a concession to the 2020s, but the first graphics
hardware I build 40 years also had separate circuits for text and pixel
graphics, in that case with a discrete switch; I can't remember if one
could be overlaid on the other. There was only one monitor anyway. That
system was used for 3D graphics and image capturing and processing - on
8-bit hardware.)
 
The idea is to keep it simple, yes? And also something that is
guaranteed to be available.
 
> Umm, pdf has been a standard interchange format for a very long time.
> Postscript seems to be fading away a bit.
 
PDF seems to be a development of encapsulated Postscript. I wrote CAD
applications where a variety of such things were rendering targets (and
NeXT showed that PS could be used for interaction). But I think a
dedicated screen library, with the possibility of capturing drawing
commands, would be better.
 
>> used are thin-ish wrappers around WinAPI, and using 1990s GDI (though
>> using dynamic code).
 
> You're stuck in the past. Time for you to catch the clue train back to 2020.
 
Not me. Clearly you and plenty of others want things to remain
complicated (maybe you get better paid that way, I don't know), with
myriad choices of graphics libraries each more elaborate than the next.
 
I like looking to the past because things that were a piece of cake back
then are now a bleeding nightmare, so lessons can be learnt. Yes, things
are bit more complex now, but maybe 1 magnitude more complex not several
magnitudes.
"Öö Tiib" <ootiib@hot.ee>: Jun 24 09:03AM -0700

On Wednesday, 24 June 2020 18:56:40 UTC+3, Alf P. Steinbach wrote:
> }
 
> [P:\temp]
> > g++64 foo.cpp -std=c++14
 
I said C++17 ... it does C++14
 
already5chosen@yahoo.com: Jun 24 09:04AM -0700

On Wednesday, June 24, 2020 at 6:49:04 PM UTC+3, Öö Tiib wrote:
> {
> return std::max(rand(), bar::foo);
> }
 
It works on gcc and clang only when -std=c++17 explicitly specified.
As a practical solution it is not as good as "const inline". Both of them require C++17, but "const inline" makes it more explicit.
In effect an innocent user that forgot to specify -std=c++17 will get incomprehensible link error in the first case vs quite intelligible warning (or error) in the second case.
It's a pity, actually, because esthetically 'constexpr' is less ugly than rather monstrous 'const inline'.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)