Friday, September 6, 2019

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

"Öö Tiib" <ootiib@hot.ee>: Sep 05 11:44PM -0700

On Thursday, 5 September 2019 23:23:48 UTC+3, Daniel wrote:
 
> Anyone can tell me what is status "cd4"?
 
The "C++ Standard Core Language Active Issues" document describes it as:
"CD4: A DR/DRWP or Accepted/WP issue not resolved in C++14 but included in the Committee Draft advanced for balloting at the June, 2014 WG21 meeting."
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html>
"Öö Tiib" <ootiib@hot.ee>: Sep 06 02:06AM -0700

On Friday, 6 September 2019 09:44:38 UTC+3, Öö Tiib wrote:
 
> The "C++ Standard Core Language Active Issues" document describes it as:
> "CD4: A DR/DRWP or Accepted/WP issue not resolved in C++14 but included in the Committee Draft advanced for balloting at the June, 2014 WG21 meeting."
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html>
 
In layman terms CD4 means that the changes proposed made it into C++17.
 
My current impression is that clang does not do what
[over.ics.rank] of C++17 seems to say. The
<https://clang.llvm.org/cxx_dr_status.html> shows that they
consider themselves good with 1467 and 1589 since clang 3.7.
Yet there are differences:
 
#include <initializer_list>
#include <string>
#include <iostream>
 
void f1(int)
{
std::cout << "f1 1\n";
}
 
void f1(std::initializer_list<long>)
{
std::cout << "f1 2\n";
}
 
void foo(char const*)
{
std::cout << "foo 1\n";
}
 
void foo(std::initializer_list<std::string>)
{
std::cout << "foo 2\n";
}
 
int main()
{
f1({42}); // both output fl 2 like standard suggests
foo({"bar"}); // clang outputs foo 1, g++ outputs foo 2
// despite standard seems to suggest foo 2
}
Daniel <danielaparker@gmail.com>: Sep 06 11:27AM -0700

On Friday, September 6, 2019 at 5:07:09 AM UTC-4, Öö Tiib wrote:
 
> In layman terms CD4 means that the changes proposed made it into C++17.
 
Thanks :-)
Daniel
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 05 08:04PM -0400

Juha Nieminen wrote:
> will make it std::greater<void> when no parameter is specified.
 
> std::greater<void> in turn has a specialization that has a
> templated operator(), which allows it to compare any types.
 
Uh-huh. Just in case you have not found it these are called "deduction
guides" in the standard. I did not answer you question because I still
don't understand these enough to use fearlessly. A good tutorial /
how-to article would be useful. -Pavel
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Sep 06 02:55PM +0100

On Thu, 5 Sep 2019 20:04:39 -0400
> guides" in the standard. I did not answer you question because I still
> don't understand these enough to use fearlessly. A good tutorial /
> how-to article would be useful. -Pavel
 
'template <typename T = void> struct greater' (and its equivalent for
the other standard comparison structs) was first provided in C++14
(not C++17), allowing type deduction for operator(). It does not need
to rely on C++17 deduction guides - you can supply an empty template
type specifier of <> when instantiating std::greater in C++14.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 05 10:02PM -0400

Bonita Montero wrote:
 
> No one here has experience with systems where they think exception
> -handling should be inappropriate for performance-reasons; that's
> all pure phantasy.
Well, let's see here.. EPOC32 by Psion (later known as Symbian by
Symbian consortium) was a decent RTOS for the time (could reliably mete
out some 10 micros jobs at some 5-10 Mhz CPU -- not a small feat).
"Decent" in a sense of well-written kernel and API *features* that is.
The system gained a lot of traction, was running successful and
significant consumer electronics (e.g. Psion Series 5 palmtop computer
(more powerful than 16-bit Palm Pilot) and the Nokia "Communicators"
series -- first seriously smart phones).
 
BUT, they made an unfortunate decision to use a proprietary C++ API for
accessing OS services (later they added some C POSIX level as an
after-thought but it was half-hearted and too late so it did not save
the baby).
 
What was worse than just using C++ API and probably the crux of their
problems and eventual death is that they decided (I am guessing that it
was at advice of some C++ exception aficionado "expert") is to use
exceptions exclusively to communicate OS call failures (remember, all
these calls were C++ APIs). That is, the app programmers (hereinafter
users) did not have a choice of using error code -- unless they did not
use any OS services in their apps -- that was, well, never in my
experience (killed a couple of years developing for the OS).
 
To relate to your many times reiterated point that exception is
something to use at I/O failure or resource exhaustion only, in my
experience 99+% of system call failures fall squarely to this category.
So I hope you agree (but please feel free to correct me if I am wrong)
that the EPOC32 decision to use C++ exceptions to communicate system
call failures shall agree with your recipe to C++ exception applications.
 
Here is what happened next:
 
Early in the game someone at Psion figured out (presumably from hard
experience) that
a) standard C++ exception handling mechanism with stack unwinding was
too slow for RTOS, I/O errors or not
b) that C++ lack of compile-time-checked exceptions was an invitation
for unsafe, poorly tested and inscrutable software.
 
Not to be scared (the origins of the system was British and then two
Scandinavian nations and Japan jumped in so I guess Tor and samurai
spirit were with them), they devised a solution to both of the above
minor issues:
 
-- They modified their embedded gcc port to not unwind C++ stack
automatically (trust me this people knew a thing or two about
performance and their RTOS beat all competition of GUI-capable RTOSes
with accessible API at the time -- I should know because I did the
comparison before deciding to go for it so they must have had a good
reason to do such a labor consuming and controversial thing). Instead
they provided a user-controlled API to "cleanup stack" where people
would manually place their resources. This was supposed to cure a) (and
I guess it did).
-- they created a special naming convention for all functions whereas
the function was affixed with L and/or C letters (by now I forgot
whether they were prefices or suffices) to indicate whether a function
may "leave" (in normal C++ terms, throw an exception) or must take care
of its portion of cleanup stack at normal exit. This was supposed to
mitigate b); you are free to guess how well it worked.
---- To HELP people in following the conventions, they created some code
checker to check that L- functions can only be called from C- functions
or whatever the implications were (can't recall this crap precisely
now); and
---- To ENFORCE the convention in deployed APPs (and not give their
pristine OS a bad name by sloppy app programming) they introduced
(possibly for the first time in history or maybe it is just me who met
this first with them) some production-ids that one had to receive from
Psion (later, probably, Symbian consortium) after they verified the code
for these (and other) conventions AND INDEPENDENTLY TESTED BY EPOC32
engineers and only apps with such production ids could be deployed on
the devices and sold (this was mainly enforced legally, I think; but you
can see Apple is no way first in this kind of bureaucracy in accepting
an app for the platform; the only difference was, it did not cost this
much with EPOC32 IIRC).
 
Well, the results of these efforts is history. From my experience,
C++-with-exceptions system API was absolutely the biggest reason for
their death. From what I remember from their support mailing lists (that
time social media), the C++ exceptions were by far most hated feature of
the RTOS (truly, it did not have much else to complain about; much later
it started to lag, mainly in GUI features; but this was obviously due to
narrow acceptance by users (app developers) that in turn caused money
issues). A failed (too late, too little) attempt to provide an
alternative limited POSIX API (which is no way perfect in my opinion,
even if they implemented complete POSX; but it would be infinitely
better than C++ API with exceptions) is a proof that the management got
it, too, eventually -- but too late to save it.
 
What did it leave me with? Bitter after-taste for two lost
could-be-productive years (well, almost, I designed non-EPOC32 software
during that time, too) and life-long resolution to never use C++
exceptions for anything. Have been happy so far following it, never had
to look back. Sometimes I start to think Java-style compile-time-checked
exceptions would not be a bad addition to C++; but then I start to
recall that, in practice, exception handling in Java was always wordier
and not necessarily more readable than scoped status collectors and
return codes in C++ (and measurably slower than return codes, even for
Java land) and such my stupid thought leaves me. Now that std::optional
and std::variant are being standardized (I guess, being borrowed from
Haskel's Maybe and Either and Scala's Option and result) I feel like I
almost have more tools under my belt for error handling than I will ever
need. Bye-bye C++ exceptions, rest in peace..
 
-Pavel
Bonita Montero <Bonita.Montero@gmail.com>: Sep 06 07:10AM +0200

>> C++ simply hasn't any significant advantage over C on such tiny
>> projects.
 
> Many embedded developers would disagree.
 
From a nerdish point of view ...
Ian Collins <ian-news@hotmail.com>: Sep 06 05:16PM +1200

On 06/09/2019 04:56, Richard wrote:
 
>> C++ simply hasn't any significant advantage over C on such tiny
>> projects.
 
> Many embedded developers would disagree.
 
Indeed we do!
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Sep 06 08:25AM +0200

On 05/09/2019 20:07, Daniel wrote:
 
> Still, I think it would be uncontroversial to say that C is still the #1
> choice over C++ for firmware/embedded system development? When every byte
> counts?
 
It is certainly correct that C is dominant in small embedded systems.
There are many reasons for this - some good technical reasons, others
not so good or not so technical. C++ has very little, usually zero,
overhead compared to C if you can turn off exceptions and RTTI fully in
the compiler (and usually you can do so). It is quite easy to write C++
code that is accidentally larger than the C code - however, it is also
easy to write C++ that results in smaller object code than equally
maintainable C code. This is especially true compared to C90, which is
still used for a large proportion of such code.
 
C is used rather than C++ from habit, for standards (the embedded world
is much more concerned with coding standards than the PC world, and it
takes a long time to change coding standards), for limited compilers
(not all targets have gcc or other good compilers), based on the
experience and knowledge of developers, due to ignorance or prejudice
amongst managers, for compatibility or portability, etc.
 
People who tell you C++ doesn't have advantages over C, even for tiny
projects, are wrong. People who tell you C++ (minus exceptions and
RTTI) means less efficiency, or bigger code, than C are wrong.
 
But people who tell you C is still dominant, are right!
David Brown <david.brown@hesbynett.no>: Sep 06 10:05AM +0200

On 05/09/2019 18:03, Daniel wrote:
> be a shame if that happened. Personally I find Bonita's posts a welcome breath
> of fresh air, I may be a minority of one, but perhaps not.
 
> Daniel
 
It is possible there are more women posting than you think - it is not
uncommon for women to use male pseudonyms in technical groups, and of
course there are lots of anonymous or pseudonym posters on Usenet. I
think it is a terrible shame that some people feel they have to hide an
aspect of themselves - whether it be their gender, nationality, age,
sexuality, religion, or anything else that is irrelevant to discussions
here.
 
This is a technical group, for discussing C++ and issues relating to the
language. I have a total disregard for whether someone is male or
female, or any other non-technical matter. I expect the same standards
of politeness and respect from anyone. And that is how it should be,
and that is how most of this group feels (as far as I can judge). There
are a few posters that are openly misogynist or otherwise bigoted, but
they are only a small minority and their worst excesses are condemned by
other posters.
 
If there is an off-topic thread in which other aspects of someone's life
are relevant (some people here are happy with occasional off-topic
threads, others are not - but that is another matter), then it is fine
to bring it up.
 
Otherwise, Bonita deserves no difference in how we treat her, or what
standards she should hold, due to her gender. I don't welcome Bonita to
this group because she is a women - and doing so is disrespectful,
patronising and misogynist. I welcome /anyone/ to this group - whether
they are male, female, hermaphrodite, or an intelligent slug from the
planet Zog. All I ask is that they try, at least roughly, to follow in
the broad standards of the group. An example of that is including
attributions in posts - Bonita has explained in posts in another group
(comp.arch) that she snips them intentionally, with a total disregard
for anyone else, because she prefers it that way for her own newsgroup
reading. It is an active choice to put here own wishes first and
viewing the specific requests of others as irrelevant and beneath her.
To me, this is a much bigger issue than calling me a "liar" - I've been
called far worse in these technical groups, including by people whose
opinions matter to me (and I thank them for their honesty). A person
who holds the egoistic attitudes shown by Bonita is not a person I would
want to deal with in real life, regardless of any programming ability.
And being a women in a male-dominated profession is not an excuse of any
kind.
"Öö Tiib" <ootiib@hot.ee>: Sep 06 02:36AM -0700

On Thursday, 5 September 2019 19:55:10 UTC+3, Richard wrote:
 
> Agreed. I find it interesting that all these proponents of other
> languages keep pointing to problems that C++ has solved decades ago as
> the reason why we need their language.
 
The issue is not solved in practice. All public repos are full of C++
code that compiles without warnings but leaks, violates bounds, uses
potentially invalid iterators etc.
Unsafe constructs are still well-formed and nothing helps to avoid usage
of those (or to use these *only* in that 5% of code-base where less safe
feature might improve perceived performance of whole product).
BGB <cr88192@gmail.com>: Sep 06 06:24AM -0500

On 8/30/2019 4:42 PM, Ian Collins wrote:
 
> Have you actually measured the difference?  I have on several occasions
> and yes, the no-throw path with exceptions is faster (even if only
> slightly) than testing error returns.  It is also foolproof..
 
I agree, in this case.
 
A sane implementation of exceptions can use a lookup table for
PC/EIP/RIP/whatever, and so only involves significant time overhead when
actually throwing an exception.
 
Though, this does work under the assumption that exceptions are used
primarily or solely for error handling, and not as a part of the normal
control-flow.
 
 
In most cases, the overhead is primarily in terms of space, namely the
cost of storing the lookup tables and the unwind-related logic.
 
Depending some on the ISA and ABI, it may be possible to reduce the size
of this table to some extent (for many ABIs it may 8-16 bytes per
function and/or try/catch block), and to encode some information needed
for unwinding via a predefined format for the epilog (the instruction
sequence telling how to unwind the current stack frame), ...
 
Though, granted, this space overhead may still matter in some
applications, so it still isn't entirely free.
 
...
scott@slp53.sl.home (Scott Lurndal): Sep 06 01:51PM


>A sane implementation of exceptions can use a lookup table for
>PC/EIP/RIP/whatever, and so only involves significant time overhead when
>actually throwing an exception.
 
It's the unwinding support that adds overhead. Regardless of whether
the exception is ever thrown in any particular codepath.
 
I have a large application (a full-system simulator) written in C++.
When simulating an instruction, if an exception is detected (illegal
instruction, illegal operand, instruction timeout, etc), it will
longjmp back to the main loop.
 
Replacing the longjmp with 'throw' cost 30% in application performance,
even given the infrequency of longjmp calls/throw (exceptions in production
code are rare; mainly when the stack limit is reached and more stack needs
to be allocated by the OS to the application).
 
 
YMMV.
Sam <sam@email-scan.com>: Sep 06 06:44AM -0400

Szyk Cech writes:
 
 
> I search few minutes Internet without success.
 
> My question is:
> Is this any reasonable solution which allow to render HTML in NCurses apps?!?
 
Sure: simply write a little bit of C++ code to parse HTML, and show the
parsed text using ncurses. It's not complicated. HTML parsing is not that
hard.
 
> I want to write app with commandline and Qt or NCurses interface.
> It will be nice if I can display some basic tags in Qt and NCurses without
> conversions...
 
I don't know what "conversions" means. Parsing and formatting basic HTML is
not rocket science. Cone, a terminal mail reader, is capable of displaying
HTML-formatted E-mail, and it didn't take an eternity to write a basic HTML
parser for it; even translating some basic HTML tags into terminal color and
highlight attributes. No CSS or tables, but basic HTML content is quite
readable.
Thiago Adams <thiago.adams@gmail.com>: Sep 06 05:15AM -0700

On Friday, September 6, 2019 at 7:44:39 AM UTC-3, Sam wrote:
> parser for it; even translating some basic HTML tags into terminal color and
> highlight attributes. No CSS or tables, but basic HTML content is quite
> readable.
 
If someone wants to create a project for that, let me know, I am in.
 
In my view HTML is the current standard of everything related with UI.
Everything else is a wast of time.
 
And of course we don't need all features but a subset.
 
I would like to use this to create interfaces for servers.
For instance a small utility to edit server config files.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Sep 06 03:17AM -0700

> to have exactly same last 2 parameter types as the interface
> method it calls ((I,I) for ma, (const I&, const I&) for mb and
> (const I&, I) for mc). [...]
 
I took a pretty long look at this. I think you're up against a
hard problem. Here's the best I came up with (please excuse
some minor changes in names, etc):
 
template< typename T, const int >
class Caller {
T &worker;
public:
Caller( T &w ) : worker( w ) {}
 
template< typename ... Stuff > void
invoke( void (T::*pmf)( Stuff ... ), Stuff ... stuff ){
(worker.*pmf)( stuff ... );
}
};
 
and in main(), instead of
 
Caller<IA,1>(a).callMethod( &IA::ma, i1, i2 );
Caller<IA,2>(a).callMethod( &IA::mb, i3, i4 );
Caller<IA,3>(a).callMethod( &IA::mc, i5, i6 );
 
I have
 
Caller<IA,1>(a).invoke< I , I >( &IA::ma, i1, i2 );
Caller<IA,2>(a).invoke< const I &, const I & >( &IA::mb, i3, i4 );
Caller<IA,3>(a).invoke< const I &, I >( &IA::mc, i5, i6 );
 
I looked at using forward(), but I don't think it helps you. I
should add though that I'm still pretty much of a novice with
those things.
 
My sense is that you will be stuck with having to give the
template argument types explicitly rather than having them be
deduced. I have a similar disclaimer about not having any
level of expertise in template type deduction.
Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 05 11:26PM -0400

Ralf Goertz wrote:
 
> gives:
> 1
> 2
my guess is the above pt declarator is roughly equivalent to
pt(vector<int>(initializer_list<int>(initializer_list<int>(1,2)))) --
which just happens to give you an expected result. I think it is
undefined or implementation-specific what default copy constructor does
on initializer_list because the data members of it are not defined by
the standard.
 
>> { { /* something */ } } introduces a braced initialization list with
>> one value.
 
> But didn't we need to use two braces for container intialization?
 
for vector<int>, because there is constructor with count and value, you
need something like = { 1, 2}; (note =) for {1,2} to be interpreted as
initializer_list; for vector<string> you should be able to initialize
with {"One", "Two"} directly.
 
-Pavel
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)