Thursday, December 7, 2017

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

Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 07 09:46PM

On Wed, 2017-12-06, Lynn McGuire wrote:
> character literals, inline variables, fold expressions, and more. On the
> C++ standard library side is parallel versions of the STL algorithms, a
> file-system library derived from Boost, and other additions."
 
Good news!
 
> 1,605 pages ! ! !
 
> I would still like to see a standard windowing user interface library.
 
And yet everyone (I think) who responded, only did so to react to your
last comment.
 
Does someone has anything to say about the /actual/ C++17? What
features will I use the most when I get around to upgrading, in a few
years?
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Dec 08 10:55AM +1300

On 12/08/2017 10:46 AM, Jorgen Grahn wrote:
 
> Does someone has anything to say about the /actual/ C++17? What
> features will I use the most when I get around to upgrading, in a few
> years?
 
For us it's a bit of dilemma: use the gcc 6.3 based ARM SDK we have been
testing for a couple of months or start again with 7.2 to get C++17...
 
Just like when C++11 dropped, it'll take a while to find the new bits
that are really useful day to day. Today I tidied up some tool code by
using the return value form emplace_back, so the journey has begun :)
 
--
Ian.
David Brown <david.brown@hesbynett.no>: Dec 08 12:15AM +0100

On 07/12/17 22:46, Jorgen Grahn wrote:
 
> Does someone has anything to say about the /actual/ C++17? What
> features will I use the most when I get around to upgrading, in a few
> years?
 
There are lots of nice small things:
 
template auto
 
class template argument deduction
 
inline variables (it took me a while to figure out what these are)
 
initialisers in "if" and "switch" could be useful sometimes, and make
things a little more consistent. And it will put an end to the hideous
(IMHO) C idiom "if (x = nextVal()) ... ".
 
 
"if constexpr" is going to make some templates a /lot/ neater. Along
with constexpr lambdas, it also makes compile-time calculation more
flexible (something I like, since my compiler PC is probably 1000 times
faster than the my target processors!).
 
 
When I first heard of them, I thought structured bindings would be
great. Now we have multiple return values from functions:
 
auto squareroot(double a)
{
if (a >= 0) {
return std::make_pair(std::sqrt(a), true);
}
return std::make_pair(0.0, false);
}
 
auto foo(double x)
{
auto [sq, valid] = squareroot(x);
if (valid) return sq;
return -x;
}
 
It is all "auto". It is not quite as neat as multiple returns in
Python, but it is not bad.
 
But after more thought, I don't like that much. I'd rather write:
 
auto squareroot2(double a)
{
using Ret = struct {double sq; bool valid;};
if (a >= 0) {
return Ret { std::sqrt(a), true };
}
return Ret { 0, false };
}
 
auto foo2(double x)
{
auto y = squareroot2(x);
if (y.valid) return y.sq;
return -x;
}
 
It is still nicely "auto" in the caller, but you no longer have to
remember the order of the return values - it is more robust, and clearer
in the code.
 
Structured bindings can still be useful for pulling apart arrays.
 
 
 
The new attributes might be nice for people writing portable code - my
code is gcc-specific, so I expect to stick to gcc __attribute__ in most
cases.
 
 
std::byte is an odd one - it's a good idea, but I think it was wrong to
allow bitwise operations on it.
 
 
std::optional is a good idea, that will lead to code that more clearly
shows the intent:
 
std::optional<double> squareroot3(double a) {
if (a >= 0) {
return std::sqrt(a);
}
return {};
}
 
auto foo3(double x) {
auto y = squareroot3(x);
return y.value_or(-x);
}
 
With gcc at least, the std::optional version here is slightly less
efficient than the others, which is a little surprising and
disappointing. It is unlikely to make a big difference in practice.
 
 
std::variant will be useful in many ways, I think.
Intelli2 <intelli2@mama.com>: Dec 07 05:15PM -0500

Hello,
 
We have also to think like a manager..
 
I am here to make Embarcadero technologies better, i am thinking also to
the investors in Embarcadero technologies, so we have to think also
money, and we have to think big, because this is how we will make
Embarcadero technologies better, i have two choices, first one is to
sell my scalable algorithms and such and there implementations to
Embarcadero technologies, and second one is to sell them to Microsoft,
Microsoft loves to think big and thus to make money, so we have not to
think cheap, and thus we have to think big, this is why i am here to
help the managers of Embarcadero technologies to think better, so we
have to be smart to be able to think better, so how can we make
Embarcadero technologies better ? we have to better its name and to
attract consumers , this is what love managers of Embarcadero
technologies and what loves investors in Embarcadero technologies, and
to better its name and to attract consumers what can we do ? i will give
my ideas: if you look at Embarcadero technologies , they are not
thinking big because they are still using Pthreads that is not good, and
there Threadpool is not fully scalable and there FIFO queues are not
fully scalable in NUMA systems and multicore systems etc. etc., so
Embarcadero technologies is not thinking big, because the main problem
is that it's not thinking better scalability, this is why i am here to
sell my inventions that are my scalable algorithms and there
implementations, Embarcadero technlogies has to buy my inventions that
are my scalable algorithms and such and there implementations to make
Delphi and C++Builder much more scalable on NUMA systems and multicores,
this is the future Sir and Madam ! this is how we have to think big, and
this is how we will make a better name and we will attract much more
consumers, this is why i am writing here and this is why i will talk to
Embarcadero technologies soon, the future also is to make Embarcadero
products like Delphi and C++Builder more and more scalable on NUMA
systems and multicores.
 
A new fully scalable algorithm is coming, i have just invented it right now.
 
It is two fully scalable Threapools, my other Threadpools were not fully
scalable, my new scalable algorihms will be very powerful, they will use
a distributed technic that will make my Threadpools fully scalable (like
my scalable FIFO queues that i have invented and implemented in front of
your eyes), and they will use also scalable counting networks that are
fully scalable.
 
So stay tuned , it will take me one day to implement this new fully
scalable algorithm that i have just invented !
 
Also, I am thinking to include many of my projects in Embarcadero Delphi
and C++ products , they can be included in a directory called Utils(that
means utilities) inside Embarcadero Delphi and C++ products
 
What i want to include in Embarcadero Delphi and C++ products is my
inventions like my scalable Parallel Varfiler and my scalable RWLocks
and my scalable MLock and my scalable AMLock and my scalable FIFO queues
and my SemaMonitor and my C++ Synchronization Objects Library and
my Parallel Compression Library etc.
 
I am an experienced programmer specialized in Parallel programming and
synchronization algorithms, it is why i have invented many scalable
synchronization algorithms.and such, i am not an expert on coding, this
is why i will let Embarcadero enhance the coding style of my projects
and verify and text them more.
 
 
Thank you,
Amine Mouly Ramdane.
"James R. Kuyper" <jameskuyper@verizon.net>: Dec 07 03:44PM -0500

On 12/07/2017 02:25 PM, Marcel Mueller wrote:
>> with don't make it easy to filter out those responses.
 
> In my news reader (quite old Thunderbird) the relevant filter action is
> called "Ignore subthread". This excludes any troll feeder as well.
 
Thanks for pointing that out. I hadn't noticed that option before,
possibly because it doesn't quite do what I want: if someone posts a
message I don't want to see, that prompts a conversation between two
people whose messages I do want to see, I'd like to see that
conversation. "Ignore subthread" (assuming it's name means what it seems
to mean) would ignore that conversation. However, missing a small number
of messages I do want to see might be a price worth paying for skipping
a lot of messages I don't want to see. I'll give it a try.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 07 09:18PM

On Thu, 2017-12-07, Rick C. Hodgin wrote:
> posts could be flagged as spam, as well as users, and then they
> would either not appear in Thunderbird, or they would be shown
> only in a special folder.
 
Make that:
- designing a file format similar to the slrn score file format
- write various converters from this score file format to whatever
actual newsreaders use
- see people set up Git repositories with such files
 
But I suspect that's pretty much Marcel's proposal.
 
> We are software developers. Such things are within our grasp.
 
Yes. I don't think I'd use it, though. Killfiling is, to me, mostly
a private activity. I don't trust others to do it for me, and I
wouldn't want others to trust me.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Dec 07 01:26PM -0800

On Thursday, December 7, 2017 at 4:18:31 PM UTC-5, Jorgen Grahn wrote:
 
> Yes. I don't think I'd use it, though. Killfiling is, to me, mostly
> a private activity. I don't trust others to do it for me, and I
> wouldn't want others to trust me.
 
The idea isn't to have people auto-killfile for you, but if multiple
people mark a particular post or user, it could lend credence to the
thing being valid. We could also set it up so that you can set a
trust factor from other user's suggestions. If your colleague Bill
marks something spam, well you know Bill and if he marks it spam it
probably is spam, so you place a 90% confidence on him. But for me
marking something spam, you don't know me, you don't know if my view
for spam is correct or not, so you give me a 5% confidence, etc.
 
It's all workable ... just a little brainstorming.
 
--
Rick C. Hodgin
David Brown <david.brown@hesbynett.no>: Dec 07 10:43PM +0100

On 07/12/17 21:44, James R. Kuyper wrote:
> to mean) would ignore that conversation. However, missing a small number
> of messages I do want to see might be a price worth paying for skipping
> a lot of messages I don't want to see. I'll give it a try.
 
Yes, that is exactly what the "ignore subthread" option does. I have it
on some filters for spam-bots, where the "poster" is clearly a program.
As you say, it will filter out threads where a unwanted poster has
inspired a more interesting conversation, usually by accident.
Personally, I am quite quick at running through the latest posts - and
if necessary, pressing "k" or "shift-k" for "kill thread" and "kill
sub-thread" manually. It's a personal choice how you want to do it, and
where you draw your lines - but the tools are there to help.
 
My own judgement of when a thread is off-topic or inappropriate is based
on contributions - if there are a number of people (3 at a minimum)
making posts in the thread, excluding posts complaining about
topicality, language, etc., then it is a thread of interest to members
of the group. And surely that must make it at least somewhat topical -
a Usenet group is (or should be) defined by the preferences and
interests of its members, rather than the title of the group. It is
first and foremost a community.
Tim Rentsch <txr@alumni.caltech.edu>: Dec 07 07:12AM -0800

> think. The standard gives as an example 'B b[2] = { B(), B() };',
> about which it says "full-expression is the entire initialization
> including the destruction of temporaries"
 
This example was added for C++17, reflecting a change in the
definition of full-expression for C++17. That definition now
includes as one alternative
 
an init-declarator (Clause 11) or a mem-initializer (15.6.2),
including the constituent expressions of the initializer
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)