Friday, June 26, 2020

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

Juha Nieminen <nospam@thanks.invalid>: Jun 26 10:27AM


> 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.
 
I think that HTML is really off the mark here. A much more apt example
would have been, for example, OpenGL, which is exactly the kind of
standard I'm talking about. (Maybe I should have specified in my
post more specifically that I'm talking about an API standard, rather
than something else). Indeed, OpenGL is a very well-established and
very widely used standard, supported by almost all platfors that can
display 3D graphics.
 
Of course in this case OpenGL would not be the answer to the problem
because OpenGL is not a GUI API standard, but a 3D rendering API
standard, so it can't really be used to present a (native) GUI to
the user. (Also, OpenGL lacks many drawing utilities that would be
useful for the average user, like vector graphics, pixel graphics
etc.)
 
There are lots of GUI libraries out there, like tk, wxwidgets, gtk
and so on and so forth, but they all do their own unique thing when
it comes to their API, and do not follow any standard, because there
is no universal standard API for GUIs.
 
I suppose that the reason why I'm talking about GUI API standards here
is that if in C++ you would want to write and distribute a GUI'd program,
you would inevitably be tying it to one particular GUI library, which
cannot be replaced by another.
 
This is unlike most of the C++ standard library: If you write a program to
use the C++ standard library it doesn't really matter what the actual
library implementation is. It could be libc++, libstdc++, or any other.
The API is standardized, so it doesn't matter.
 
I don't know if this would be feasible with a GUI library, but at least
if one existed, it would make it much easier for people (especially
beginners) to just display graphics on screen with minimal effort.
 
Something that I myself would like a lot. I really hate the fact that
it's extraordinarily laborious to set up a system where I can easily
draw something on screen, using C++.
boltar@nowhere.co.uk: Jun 26 11:04AM

On Thu, 25 Jun 2020 19:02:50 +0300
 
>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.
 
If someone finds using a command line to hard then they've got no chance
learning C++.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 26 04:05PM +0200

On 26.06.2020 12:27, Juha Nieminen wrote:
>> interaction which is supported by most platforms having graphics (and
>> even by some without). It's called HTML.
 
> I think that HTML is really off the mark here.
 
A bit off the mark, but there are at least 2 C++ GUI libraries with the
front end in HTML+CSS+JavaScript.
 
 
> the user. (Also, OpenGL lacks many drawing utilities that would be
> useful for the average user, like vector graphics, pixel graphics
> etc.)
 
The colors don't work in Microsoft's OpenGL example in Windows 10.
 
I think that means that nobody now uses OpenGL for anything serious on
the Windows platform.
 
 
 
> I don't know if this would be feasible with a GUI library, but at least
> if one existed, it would make it much easier for people (especially
> beginners) to just display graphics on screen with minimal effort.
 
Herb Sutter started a proposal for a standard 2D graphics library based
on the Cairo library.
 
As far as I know that proposal fizzled out, no current work.
 
 
> Something that I myself would like a lot. I really hate the fact that
> it's extraordinarily laborious to set up a system where I can easily
> draw something on screen, using C++.
 
 
Yeah. It's especially a problem for educators. Dynamic graphics is
highly motivating, and not having graphics is demotivating.
 
But then, C doesn't have a standard graphics library, and neither does
Ada. Even Rust doesn't have that. But maybe C++ can take some direction
from Rust.
 
<url: https://wiki.alopex.li/AGuideToRustGraphicsLibraries2019>
 
 
- Alf
Manfred <noname@add.invalid>: Jun 26 06:05PM +0200

On 6/26/2020 4:05 PM, Alf P. Steinbach wrote:
>> the user. (Also, OpenGL lacks many drawing utilities that would be
>> useful for the average user, like vector graphics, pixel graphics
>> etc.)
 
I don't understand what you mean here, OpenGL is perfectly capable of
doing vector graphics etc.
Along the lines of your comment, one may however note that the
complexity of using OpenGL is not parameterized to the complexity of the
graphics operation: doing vector or pixel graphics is just as complex as
advanced 3D rendering. In this sense it is not much beginner-friendly.
It is true that its target is not GUIs indeed - even drawing text is
pretty intricate.
 
 
> The colors don't work in Microsoft's OpenGL example in Windows 10.
 
> I think that means that nobody now uses OpenGL for anything serious on
> the Windows platform.
 
I don't think so.
Windows' native support for OpenGL is minimal at best (I think it is
still at version 1.1, so to use more recent versions some extra legwork
is needed - however version 1.1 is sufficient for most standard 3D
rendering), and the documentation is poor, so I am not really surprised
that some example doesn't work.
However, it is a distinctive mark of OpenGL that the implementation does
not come with the OS, it comes from the graphics vendor instead, and
using its features does not really require much from the OS vendor.
 
In accordance with their policy of hindering what is "Not Invented
Here", they promote DirectX instead. This doesn't mean that OpenGL does
not work on Windows, especially since virtually all graphics vendors
have been supporting it for a long time already.
Juha Nieminen <nospam@thanks.invalid>: Jun 26 04:36PM

> I don't understand what you mean here, OpenGL is perfectly capable of
> doing vector graphics etc.
 
No, it's not. It can only render triangles and 1-pixel-width
non-antialiased lines and pixels. That's it. Has absolutely
no support for anything else.
Juha Nieminen <nospam@thanks.invalid>: Jun 26 10:49AM

>> > 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.
 
I appreciate your humility.
 
> What I probably don't understand/know as well as yourself is a "new" C++11/14/17 things.
 
I don't really understand why you are talking about the new C++ standards
in this respect. I don't get your point.
 
Class variables (ie. "static" variables inside the scope of a class) have
always worked in this manner, all the way since the first standard, C++98
(and probably for as long as any version of C++ has supported static
variables inside a class scope). If you declare a class variable, you need
to tell the compiler where it should instantiate it, because the instance
must only be found in one compilation unit (if you instantiate it in
several compilation units you'll get a linker error because of duplicate
names). It's no different from function definitions.
 
Somehow you write as if this had changed between C++98 and C++11. It didn't.
 
C++17 added support for the 'inline' keyword in variables (including
class variables), which makes them work (from the perspective of the linker)
in the same way as 'inline' functions have always worked. In other words,
if the linker finds the same variable signature in more than one
compilation unit, it's instructed to not give an error about duplicate
names and instead just take one of them and discard the rest.
 
> And I expected that it was here since C++03 and without special keyword.
 
Why are you singling out C++03 in particular? Static variables inside a
class have *always* worked the same way, since C++98 and prior.
 
> IMHO, the way Microsoft handling it, i.e. things just work, is The Correct Way.
 
And how exactly does Microsoft handle this?
Juha Nieminen <nospam@thanks.invalid>: Jun 26 10:54AM

>>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";
 
That's a string literal, not a compile-time constant. String literals are
instantiated wherever they are used (like happens here).
 
If you have a string literal in a header file, chances are that it will
be duplicated in every compilation unit where it's used (whether the
compiler will merge all these instances into one is implementation-defined,
but in most implementations unlikely to happen).
 
The difference to a class variable (ie. a "static" variable inside the
scope of a class) is that it must genuinely be instantiated only once.
Every use of that variable must refer to the same physical instance.
You mustn't have duplicated instances of it. (This is because all the
code that uses that variable must see the same variable, especially
if its value changes.)
boltar@nowhere.co.uk: Jun 26 11:32AM

On Fri, 26 Jun 2020 10:54:48 +0000 (UTC)
 
>> const char *ptr = "hello world";
 
>That's a string literal, not a compile-time constant. String literals are
>instantiated wherever they are used (like happens here).
 
Not for pointers. In this case "hello world" is stored in the text portion
of the binary and is at a fixed location from the minute the binary is loaded
into memory and is never instantiated.
 
>If you have a string literal in a header file, chances are that it will
>be duplicated in every compilation unit where it's used (whether the
 
Or more likely you'll get a duplicate symbol error unless you declare it
as extern in all but 1 of those units.
 
>compiler will merge all these instances into one is implementation-defined,
>but in most implementations unlikely to happen).
 
Thats exactly what will happen:
 
fenris$ cat t.h
#include <stdio.h>
 
#ifdef MAIN
const char *ptr = "hello world";
#else
extern const char *ptr;
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)