Thursday, June 25, 2020

Digest for comp.lang.c++@googlegroups.com - 17 updates in 4 topics

Sam <sam@email-scan.com>: Jun 24 07:35PM -0400

Alf P. Steinbach writes:
 
>> repository, I'm curious to look at it, to see if I can pick up some tips,
>> for mine's.
 
> I guess you can find Leigh's neoGFX easily just by googling it.
 
Yeah, Windows-based library, oriented towards game development, from the
looks of it.
 
Mine, on the other hand, is an X11 widget stack, Linux only, classic widget
set.
 
> 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.
 
My driver was a desire to get up to speed and learn C++11. Thinking about
what I could possibly practice on: writing an X11 widget stack was appealing
for some reason. I also found that learning X was quite interesting. I
intentionally set up my development environment to tunnel X over ssh, over a
wireless connection. This makes implementation inefficiencies very obvious.
 
These days, my toolkit targets C++20, after the introduction of constraints,
and other C++20 features, into my library.
 
> initialization guarantee, that after constructor execution you have a fully
> working usable object at hand, with class invariants established.
 
> I.e., no MFC-style two-phase or multi-phase construction.
 
Not familiar with MFC's two-phase construction, so I might be talking about
something else; but I did find a need for two-phase construction, for certain
specific use cases, myself. My definition of two-phase construction was a
requirement to call a class method after constructing an instance, in order
to finish something.
 
I found a workable solution by having the framework take care of it, without
really having to explicitly invoke the 2nd phase. I don't have to call the
2nd phase constructor, every time, myself. All my widgets and other objects
gets constructed by templates, and the templates use SFINAE to determine
whether the constructed class instance has a second phase constructor; and
if so invoke it automatically. Objects with a second phase constructor end
up getting instantiated identically to regular objects, without having to
think about it. Completely exception safe.
 
> <url: https://github.com/alf-p-steinbach/winapi>.
 
https://www.libcxx.org/w/
boltar@nowhere.co.uk: Jun 25 09:09AM

On Wed, 24 Jun 2020 19:35:26 -0400
>These days, my toolkit targets C++20, after the introduction of constraints,
>and other C++20 features, into my library.
 
If you want it to be used by a significant number of people thats probably
a bad idea. Most people and companies don't upgrade compilers all that often
and Clang (on the Mac anyway) still doesn't support C++ 20 fully - eg
co routines still don't work properly and the <=> isn't yet supported (which
seems odd given how trivial it should be to implement).
Sam <sam@email-scan.com>: Jun 25 07:12AM -0400

> and Clang (on the Mac anyway) still doesn't support C++ 20 fully - eg
> co routines still don't work properly and the <=> isn't yet supported (which
> seems odd given how trivial it should be to implement).
 
This is not something where there's a large existing code base that could
potentially come into play. One might argue that aiming for general
compatibility with existing toolkits is an advantage, but I would argue that
this offers very little value-added. What value-added would there be, in
porting an existing code base to a different, unproven stack, when ol'
reliable is where it is?
 
So, without worrying about compatibility, targetting the current C++
standard makes more sense to me. I just dropped all relative comparison
overloads, and replaced them with three-way comparison overload. Not a major
deal, but the end result is cleaner, and better.
 
Otherwise, you end up with a situation like Qt, which stays compatible with
older C++ standards, but is full of reinvented wheels, and macros.
 
On top of that, my library's packaging allows for concurrent installs of
multiple runtime versions. If it ever catches on, there won't be an issue
with versions. Master can continue, effectively, track the current standard,
while older versions continue to remain installed and linked with whatever
software is fixed on them.
Sam <sam@email-scan.com>: Jun 25 07:38AM -0400

Mr Flibble writes:
 
>> 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
 
I chose to represent color channel values as their native 16 bit values, in
decimal or hexadecimal, the actual values used by the underlying X protocol;
three individual sliders for each color channel, and a pallette limited to
the standard HTML 3.2 colors:
 
https://www.youtube.com/watch?v=KfHtoThyNkA
 
This video is slightly old. The rendering is more optimized now, and there's
also an alpha channel there, as well.
 
> https://www.youtube.com/watch?v=WiHsFlyLuak
 
I already mentioned that I use an intentionally degraded environment, with X
tunneled over an ssh connection, over WiFi, to see any performance problems.
 
Anyway, what I was looking for was a demo of the individual widgets, similar
to what's shown here:
 
https://developer.gnome.org/gtk3/stable/ch03.html
 
I think that some Gtk widgets are quite ugly. Look at Gtk's panes. A bunch
of flat squares. Three lonely dots separating them. That's the visual cue
for dragging the panes? Compare:
 
https://www.libcxx.org/w/panelayoutmanager.html
 
Perhaps the ugliest one, IMO, is Gtk's notebook. For the longest time I
thought that firewall-config had a bug with its tabs, where I couldn't get
to the last ones. It was not obvious at all how to scroll the tabs. And the
currently active tab is identified ...by a line under its name. Really?
 
Is it really too hard to show obvious scroll buttons, so that when the number
of tabs exceeds their allotted width, it's obvious how to scroll them?
 
https://www.libcxx.org/w/booklayoutmanager.html
boltar@nowhere.co.uk: Jun 25 02:33PM

On Thu, 25 Jun 2020 07:12:03 -0400
>standard makes more sense to me. I just dropped all relative comparison
>overloads, and replaced them with three-way comparison overload. Not a major
>deal, but the end result is cleaner, and better.
 
Very noble, just don't expect it to get much traction anytime soon, thats all.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 25 07:11PM +0100

On 25/06/2020 00:35, Sam wrote:
 
>>> 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.
 
>> I guess you can find Leigh's neoGFX easily just by googling it.
 
> Yeah, Windows-based library, oriented towards game development, from the looks of it.
 
neoGFX will be cross platform and can be used to create both apps and games.
 
/Flibble
 
--
"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."
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jun 25 07:14PM +0100

On 25/06/2020 12:38, Sam wrote:
 
> I chose to represent color channel values as their native 16 bit values, in decimal or hexadecimal, the actual values used by the underlying X protocol; three individual sliders for each color channel, and a pallette limited to the standard HTML 3.2 colors:
 
> https://www.youtube.com/watch?v=KfHtoThyNkA
 
> This video is slightly old. The rendering is more optimized now, and there's also an alpha channel there, as well.
 
Eh? That is my video not yours.
 
/Flibble
 
--
"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."
Paavo Helde <eesnimi@osa.pri.ee>: Jun 25 11:23AM +0300

23.06.2020 09:23 Juha Nieminen kirjutas:
 
> Currently there are like nine billion GUI/graphical libraries out there,
> none of which follow *any* kind of standard (because there is no standard).
 
There is a widespread standard for graphical layout and basic user
interaction which is supported by most platforms having graphics (and
even by some without). It's called HTML.
boltar@nowhere.co.uk: Jun 25 08:59AM

On Wed, 24 Jun 2020 17:47:30 +0100
 
>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.
 
Not on unix you can't. TTYs are text only. End of.
 
 
>* "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.
 
Perhaps he'd had a few too many drinks when he wrote that as I have no idea
what he's thinking. Clearly he's spent too long with compilers and doesn't
understand how modern graphics systems work. C++ doesn't even support ANSI
text graphics natively and that WOULD be easy and portable.
 
>> 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
 
Sure , at the price of not allowing any other graphically based application
to run at the time including terminals and interactive debuggers. I'm sure
that would be a popular.
 
 
>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.)
 
Some old terminals used to do something just like that. But you still have the
issue of where the output goes.
 
>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
 
So what? Its non portable. If you only care about windows graphics use a
Windows API, don't expect it to be put in the core language.
 
>But I'd recommend creating a separate window. That that can become the
>default for pixel-based output.
 
Presumably output only and a fixed size which can't be changed which for
backwards compatibility would have to be a maximum of 640x400 with 256 colours.
 
>hardware I build 40 years also had separate circuits for text and pixel
 
So did most PC graphics cards back in the 80s and 90s.
 
 
>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.
 
Its not a case of wanting things to be complicated, its a case of things ARE
complicated because consumer computers are multiprocess multiwindow machines
and applications have to play nice with each other. MS tried the 1 program
gets the whole display smartphone approach with Windows 8 and look how
popular that turned out to be.
Manfred <noname@add.invalid>: Jun 25 04:28PM +0200

On 6/25/2020 10:23 AM, Paavo Helde wrote:
 
> There is a widespread standard for graphical layout and basic user
> interaction which is supported by most platforms having graphics (and
> even by some without). It's called HTML.
 
Probably one more reason to *not* put this kind of thing into the language.
However common, graphics does not belong to C++ as a language, IMHO.
It is primarily a matter of application libraries, that may well aim to
be cross-platform and at some level of standardization, still at a
different level than the language.
 
C++ works around a CPU model. Nowadays' GPU architectures are
substantially different from CPUs, and I don't see for them a converging
path either, rather the opposite looks much more likely.
From a different perspective, C++ as a language is designed at the
level of the process model. GUIs are designed as human interface models;
that's a different level.
 
If and when some agreement on GUI standardization will become realistic
(I think we are quite far from that), it might be that a dedicated
language could find its use. I understand GLSL is an attempt in this
direction - I have no idea how successful; it is a fact that some major
corporations try to push their solutions in this area - things like
Android and XAML clearly diverge from the C++ model.
Bart <bc@freeuk.com>: Jun 25 03:44PM +0100

On 25/06/2020 09:23, Paavo Helde wrote:
 
> There is a widespread standard for graphical layout and basic user
> interaction which is supported by most platforms having graphics (and
> even by some without). It's called HTML.
 
HTML is more like a rendering target. It itself is a markup language
which has to be rendered into a graphical display. And even that is not
powerful enough by itself, it needs extras to get the needed
functionality (eg. embedded Javascript).
 
How would you draw a circle from within C++ (not just C++, this debate
is common to most such languages)? How do you then get user input (eg.
user clicks within the circle or outside it)?
 
Actually, forget graphics; is there even a standard way to detect
whether a key has been pressed, and which one?
 
This stuff used to be tricky on 70s mainframe computers, then the
informal microcomputer came along, and it became child's play. Now it
has long been difficult again.
Paavo Helde <eesnimi@osa.pri.ee>: Jun 25 07:02PM +0300

25.06.2020 17:44 Bart kirjutas:
>> even by some without). It's called HTML.
 
> HTML is more like a rendering target. It itself is a markup language
> which has to be rendered into a graphical display.
 
Rendering would be done by the web browser. For most C++ newbies it
would be easier to launch a browser than to launch a command line
interpreter.
 
> And even that is not
> powerful enough by itself, it needs extras to get the needed
> functionality (eg. embedded Javascript).
 
Isn't there something called WASM which can be programmed in C++? Also,
Javascript could be emitted from a C++ library as easily as HTML.
 
 
> How would you draw a circle from within C++ (not just C++, this debate
> is common to most such languages)? How do you then get user input (eg.
> user clicks within the circle or outside it)?
 
There would be a more or less specialized widget outputting:
 
<svg OnClick="..."><circle .../></svg>
 
OnClick would pass the click coordinates back to the C++ program which
would do whatever it wants with these numbers.
 
 
 
> Actually, forget graphics; is there even a standard way to detect
> whether a key has been pressed, and which one?
 
There are standard ways with JavaScript and I presume with WASM. I
gather they are a bit inconsistent across browsers, but this could be
leveraged by the C++ side support library, similar to how
std::filesystem leverages OS differences.
 
 
> This stuff used to be tricky on 70s mainframe computers, then the
> informal microcomputer came along, and it became child's play. Now it
> has long been difficult again.
 
It's not difficult but platform-specific. And with DOS it was extremely
platform-specific.
Juha Nieminen <nospam@thanks.invalid>: Jun 25 06:15AM

> So, unless I am missing something, in 2020 C++ still has no nice portable syntax for typed constants that can be declared at class==struct scope and don't come in conflict with basic DRY principle.
 
You don't seem to understand that you want a *pointer* to such a variable.
The pointer has to point somewhere. You can't have a pointer to a
compile-time constant. It has to actually point to a real address, and the
value you specified needs to be found there.
 
That means that the variable needs to be instantiated in one compilation
unit. The compiler (or more precisely the linker) needs to find it
somewhere.
 
As you noticed, C++17 added the possibility of automatizing that a bit
by using the "inline" keyword. It will instantiate the variable for you
(in each compilation unit where it's used, and the linker is then
instructed to use only one of them and discard the rest).
already5chosen@yahoo.com: Jun 25 01:58AM -0700

On Thursday, June 25, 2020 at 9:16:06 AM UTC+3, Juha Nieminen wrote:
> already5chosen@yahoo.com wrote:
> > So, unless I am missing something, in 2020 C++ still has no nice portable syntax for typed constants that can be declared at class==struct scope and don't come in conflict with basic DRY principle.
 
> You don't seem to understand that you want a *pointer* to such a variable.
 
You don't seem to understand that everything "you understand" about low level things I understand at least as well or better.
What I probably don't understand/know as well as yourself is a "new" C++11/14/17 things.
 
> by using the "inline" keyword. It will instantiate the variable for you
> (in each compilation unit where it's used, and the linker is then
> instructed to use only one of them and discard the rest).
 
And I expected that it was here since C++03 and without special keyword.
Was disappointed to find out that it wasn't.
I really see zero advantage for C++ users (as opposed to C++ compiler's maintainers) in all that mess. IMHO, the way Microsoft handling it, i.e. things just work, is The Correct Way.
System-provided linker can't handle that? Come on, it's not 1970s any more! You (C++ compiler vendor) can develop your own linker or to help a system vendor to enhance his linker for your needs. Anything less is laziness. Esp. considering that very similar linker abilities are necessary for templates.
boltar@nowhere.co.uk: Jun 25 09:13AM

On Thu, 25 Jun 2020 06:15:53 +0000 (UTC)
 
>You don't seem to understand that you want a *pointer* to such a variable.
>The pointer has to point somewhere. You can't have a pointer to a
>compile-time constant. It has to actually point to a real address, and the
 
You can't? Whats this then:
 
const char *ptr = "hello world";
James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 24 07:59PM -0400

> On Tuesday, 23 June 2020 12:36:11 UTC+1, Scott Newman wrote:
...
 
>> This ain't a lambda.
 
> Are you claiming that []{} is not a lambda?
> Good luck with that.
 
I know that this won't do anything to change Scott's opinion on the
matter, but section 8.1.5 gives the relevant grammar productions:
 
lambda-expression:
lambda-introducer lambda-declarator opt compound-statement
lambda-introducer:
[ lambda-capture opt ]
lambda-declarator:
( parameter-declaration-clause ) decl-specifier-seq opt
noexcept-specifier opt attribute-specifier-seq opt
trailing-return-type opt
 
 
"[]" is a lambda-introducer, with the optional lambda-capture missing,
{} is an empty compound-statement. The combination is a
lambda-expression with the optional lambda-declarator missing.
Stuart Redmann <DerTopper@web.de>: Jun 25 09:32AM +0200

> {
> // your code here
> }
 
That can still be improved:
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html
 
Regards,
Stuart
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)