Monday, January 15, 2018

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

woodbrian77@gmail.com: Jan 14 08:54PM -0800

On Thursday, December 7, 2017 at 7:39:35 PM UTC-6, Ian Collins wrote:
> > and some other things need to be backported to their C++ 2011
> > compilers. Abseil won't cut it.
 
> I'm sure you realise by now that this will never happen.
 
Here are some features I think will be back-ported
to C++ 2011 compilers:
 
1. make_unique
2. string_view
3. emplace_back that returns a value
4. static_assert where the text message is optional
 
They are easy to back-port. =]
 
Brian
Ebenezer Enterprises
https://github.com/Ebenezer-group/onwards
Ian Collins <ian-news@hotmail.com>: Jan 15 06:09PM +1300

> 3. emplace_back that returns a value
> 4. static_assert where the text message is optional
 
> They are easy to back-port. =]
 
There is no point, compilers have moved on.
 
--
Ian.
Thiago Adams <thiago.adams@gmail.com>: Jan 15 04:43AM -0800

On Friday, December 8, 2017 at 9:43:57 PM UTC-2, Ian Collins wrote:
> it moves code from run to compile time.
 
> --
> Ian.
 
C++ is all about code generation. Any language
is, the difference is that C++ gives some tools
to the programmer to control, customize and
parameterize the generation.
 
 
if constexpr, as you said, will reduce the number
of lines and works as a complement of templates.
On limitation of if constexpr is that we
cannot use to select struct data members for
instance.
 
 
The code generation family of tools in C++ still
not complete. I can give many samples.
 
For instance, if C++ had no automatic generated
destructor we would not be able to generate it
using templates. We cannot create a function that
returns the name of one enum item.
 
Basically the missing part is compile time
reflection + some language to generate code.
"Sutter Metaclasses". The language to describe
the code generation can be imperative or
more declarative. constexpr functions uses
the same language "C++" to generate values but
it cannot generate types.
 
 
If C++ had a successful language to do code
generation, templates and if constexpr
would become specialized case that also
could be generated by this more general
language.
 
I am very interested in this subject of code
generation, and this have some relation with
the code generator I do called cprime.
 
I think the design of this "language" to
generated code needs to be created and
evolve from use.
 
I also think that c++ templates are in many ways
are very successful.
woodbrian77@gmail.com: Jan 15 07:55AM -0800

On Monday, January 15, 2018 at 6:44:21 AM UTC-6, Thiago Adams wrote:
> evolve from use.
 
> I also think that c++ templates are in many ways
> are very successful.
 
I think on-line code generation is the way things
are headed. One example is https://www.protlr.com/
. Another is the C++ Middleware Writer (CMW).
 
One strength of Protlr is it generates code that
can be used with Wireshark. A weakness of Protlr
(from what I can tell) is it has a web interface.
The CMW has a command line interface to simplify
integration into build processes.
 
G-d willing, we'll add support for Wireshark to the CMW
in the future.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
Tim Rentsch <txr@alumni.caltech.edu>: Jan 14 04:10PM -0800


>> Thanks. I like this better than maintaining the idiomatic use.
 
> To the best of my knowledge, this IS the idiomatic use. Using the
> comma operator, which forces you to repeat the 'c', is not idiomatic.
 
Both are idiomatic. You might say one is more well-known than
the other, or more commonly used. But both are idiomatic.
David Brown <david.brown@hesbynett.no>: Jan 15 01:13AM +0100

On 14/01/18 22:48, Stefan Ram wrote:
 
> Disclaimer: I don't know all precedence levels by heart,
> I look them up if need be. This is what I can
> write from my memory, but I'm just guessing, I'm not sure:
 
<snip mistakes>
 
> I'm sure I have made some mistakes and omissions above.
> As I said, I look up the precedence when I need to know it.
 
It is simply /crazy/ to write code that where you have a reasonable
expectation that average programmers will have to look up a reference
manual to interpret it correctly.
 
Some types of code are naturally difficult - some code in C++ is
downright mystical even for the world's leading experts. You can expect
that it will be difficult for most people to understand - and most
people will use references when trying to interpret it.
 
But most people will /not/ use references when reading or writing code
with operators. They will, like you, guess. And they will mostly get
it correct. Sometimes, however, they will get it wrong, especially when
using less common operators and combinations. "1<<4 + 5" is 512, not
21. "(1 << 4) + 5" leaves no room for confusion.
 
It is irresponsible to write code that it harder to understand than
necessary, for something as trivial as saving a couple of characters.
(If there are so many parenthesis that they become confusing, the
expression should be split up.) It is downright scary to hear this
attitude from someone who claims to teach C and C++ classes. I really
hope your students have other sources of good programming practice than
their teacher.
Tim Rentsch <txr@alumni.caltech.edu>: Jan 14 04:41PM -0800


> while ((c = fgetc (in)), c != EOF)
 
> when they could write
 
> while ((c = fgetc (in)) != EOF)
 
If asked to decide between writing
 
while (suitable(c=getchar())) ...
 
and writing
 
while (c=getchar(),suitable(c)) ...
 
(with the understanding that these two lines are the only choices
available), normally I would choose the second way, because I
think it's better not to bury the assignment inside the function
call argument list. Similarly, if asked to decide between writing
 
if ((p=malloc(amount))) ...
 
and writing
 
if (p=malloc(amount),p) ...
 
normally I would choose the second way, because I think it makes
it more plainly evident that the = is meant as an assignment (and
also because I think putting in extra parentheses to suppress a
warning that some compilers give is kind of dumb). Similarly
again, if asked to decide between writing
 
while ((c=getchar())!=EOF && c!='\n') ...
 
and writing
 
while (c=getchar(), c!=EOF && c!='\n') ...
 
normally I would choose the second way, to emphasize the symmetry
of the condition being tested.
 
Returning to the original question, for reasons of consistency
normally I would write the while() condition using a comma
operator, rather than testing against the value of the assignment
expression. Also I think the imperativeness of the while()
condition should stand out - it's not a pure expression but has a
state-changing function call (and also assignment), and I think
that distinction is worth bringing to the reader's attention.
Tim Rentsch <txr@alumni.caltech.edu>: Jan 14 04:48PM -0800

> world" project from the GUI and it defaults to CLANG_WARN_COMMA = YES.
> This is in the "all languages" section of the Xcode project settings
> so they have chosen to apply it universally.
 
I had to hunt to find the clang option that would turn on this
warning, which normally is off. Considering what I've learned
about it so far, I recommend turning it off and leaving it off.
I'm surprised that Xcode saw fit to enable it by default, but
then Xcode often makes choices that are IMO ill-advised.
Geoff <geoff@invalid.invalid>: Jan 14 08:11PM -0800

On Sun, 14 Jan 2018 16:48:23 -0800, Tim Rentsch
>about it so far, I recommend turning it off and leaving it off.
>I'm surprised that Xcode saw fit to enable it by default, but
>then Xcode often makes choices that are IMO ill-advised.
 
Done and done. I opened an older project that had not been opened in
the IDE and the latest iteration of Xcode popped up a dialog to update
project settings and indeed, "Suspicious Commas" was changed from no
to yes. I expect I'll have to be on the lookout for this from now on
unless the Apple geeks change it again.
Geoff <geoff@invalid.invalid>: Jan 14 08:22PM -0800

On Sun, 14 Jan 2018 16:41:23 -0800, Tim Rentsch
>condition should stand out - it's not a pure expression but has a
>state-changing function call (and also assignment), and I think
>that distinction is worth bringing to the reader's attention.
 
I have a feeling Apple will be undoing this change in Xcode since it
also flags constructs like:
 
src++, dest++;
Ian Collins <ian-news@hotmail.com>: Jan 15 05:27PM +1300

On 01/15/2018 05:22 PM, Geoff wrote:
 
> I have a feeling Apple will be undoing this change in Xcode since it
> also flags constructs like:
 
> src++, dest++;
 
It does spot some nasty bugs as well. We leave it on by default in our
builds. I'm guessing the boost folks do as well, there was a condition
flagged in the last but one release that has been fixed.
 
--
Ian.
"James R. Kuyper" <jameskuyper@verizon.net>: Jan 15 08:11AM -0500

On 01/14/2018 04:54 PM, Stefan Ram wrote:
[Re: precendence levels in C]
> Ok, now correcting, using notes:
 
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
 
To the extent that the rules of the C language can be described in terms
of operator precedence (which is a considerable extent), the precedence
levels correspond to the sub-sections of section 6.5.
 
6.5.1: Primary expressions:
identifier
'constant'
"string-literal"
>> (x)
_Generic()
 
6.5.1: Postfix expressions.
>> x[...]
>> x....
 
Your notation is confusing, because the member selection operator blends
in with your ellipses. I assume you meant what I would describe using
 
x.member
 
>> x(...)
 
> Here, a new level should have started by writing
> an empty line.
 
No, this is not a different level.
 
>> x++
>> x++
 
> Was intended to read "x--".
 
(type_name){initializer, list}
(type_name){initializer, list,}
 
6.5.3: Unary operators
>> !x
>> ~x
 
> forgot: &x, *x, sizeof x
 
_Alignof(type_name)
 
6.5.4: Cast operators
> forgot: (cast)x
 
 
6.5.5: Multiplicative operators
>> x*y
>> x/y
 
> forgot: x%y
 
6.5.6: Additive operators
>> x+y
>> x-x
 
6.5.7: Bitwise shift operators
>> x<<y
>> x>>y
 
6.5.8: Relational operators
> Oops, a major omission: Totally forgot
> x<y, x>y, x<=y and x>=y here.
 
6.5.9: Equality operators
> x==y x!=y
 
6.5.10: Bitwise AND operator
>> x&y
 
6.5.12: Bitwise exclusive OR operator
>> x|y
 
6.5.11: Bitwise inclusive OR operator
>> x^y ???
> ^ is higher than |, I thought about that
> possibility, but was not sure.
 
6.5.13: Logical AND operator
>> x&&y
 
6.5.14: Logical OR operator
>> x||y
 
|| has lower precedence than &&.
 
6.5.15: Conditional operator
>> x?y:z (does not exactly fit)
 
To be precise, the way in which it fails to fit is that any expression
between the '?' and the ':' is evaluated in it's entirety, and used as
the second operand of the operator, so in that regard, ?: has lower
precedence than any other operator. However, with regard to its first
and third operands, it behaves exactly as if it had precedence between
that of || and assignment expressions.
 
6.5.16: assignment operators
>> x = y
>> x += y and so on
 
6.5.17: Comma operator
Manfred <noname@invalid.add>: Jan 15 04:08PM +0100

On 1/15/2018 1:13 AM, David Brown wrote:
>> Vir Campestris <vir.campestris@invalid.invalid> writes:
>>> Please consider that future readers of your code may not have memorised
>>> them all.
 
<snip>
 
> It is simply /crazy/ to write code that where you have a reasonable
> expectation that average programmers will have to look up a reference
> manual to interpret it correctly.
 
I believe this is a bit hard as it is stated. I agree this is not good
practice, but I wouldn't categorize as hard as crazy.
Bad practice is not the same as crazy, I think. Besides, you wrote
yourself that there are cases where code cannot be written to be easily
readable.
 
> necessary, for something as trivial as saving a couple of characters.
> (If there are so many parenthesis that they become confusing, the
> expression should be split up.)
I tend to agree with the baseline, although I think that expression
splitting serves more that readability only.
 
  It is downright scary to hear this
> attitude from someone who claims to teach C and C++ classes.  I really
> hope your students have other sources of good programming practice than
> their teacher.
Here is where I tend to disagree. I think that it is right in the
context of schooling that it may be required for students to be more
familiar than average with the language syntax and rules.
This is different than a work environment, where "time is money"[1], so
you want to make life easy for yourself and your colleagues, and if a
couple of parentheses can help, you should definitely use them.
 
[1] In a school context, on the other hand, priority should be knowledge.
ram@zedat.fu-berlin.de (Stefan Ram): Jan 15 02:43PM

>precedence than any other operator. However, with regard to its first
>and third operands, it behaves exactly as if it had precedence between
>that of || and assignment expressions.
 
This is one of the rare cases where - for the common set of
operators - the syntax of C++ differs from that of C:
 
C++:
 
conditional-expression:
logical-or-expression
logical-or-expression ? expression : assignment-expression
 
C:
 
conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression
 
.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 15 06:57AM

On Sun, 2018-01-14, David Brown wrote:
>> (and other things) appear just when they're needed -- even though that
>> means main() as to come last.
 
> I think the same as you - I prefer to order my code as bottom-up.
 
Maybe it's the most common way to do it by now. I also find that it
helps encourage me to split out helper functions and classes.
 
Speaking about helper functions, does anyone use lambdas as local
helper functions these days? Like:
 
void foo(Arg arg)
{
...
auto bar = [&arg]() { ... };
...
// use bar()
}
 
where bar() is used for brevity and readability only, not as e.g. a
predicate. Sorry about the synthetic example.
 
I tend to do this in Python, and am beginning to do it in C++ too.
 
> And it should definitely be in an anonymous namespace or "static"
> (static is perhaps a bit old-fashioned).
 
I count static for this scenario as clearly old-fashioned; I think
Stroustrup said so in his TC++PL 20 years ago.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Ian Collins <ian-news@hotmail.com>: Jan 15 09:07PM +1300

On 01/15/2018 07:57 PM, Jorgen Grahn wrote:
> }
 
> where bar() is used for brevity and readability only, not as e.g. a
> predicate. Sorry about the synthetic example.
 
I just happed to have written something similar today:
 
auto error = [this]( std::string function )
{
LOG_ERROR(("Open: "+function+" failed %s").c_str(), strerror(errno));
close(m_SocketFd);
m_SocketFd = kInvalidFd;
return false;
};
 
for use in a function (in code that does not use exceptions) that has a
number of operations on a socket like
 
if (bind(m_SocketFd, (struct sockaddr *)&addr, sizeof(addr)) == -1)
{
return error("bind");
}
 
--
Ian.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jan 15 01:13PM

On Mon, 2018-01-15, Ian Collins wrote:
> {
> return error("bind");
> }
 
Thanks! That's more or less the non-synthetic example I wanted to give.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 15 03:34PM +0100

On 1/15/2018 2:13 PM, Jorgen Grahn wrote:
>> return error("bind");
>> }
 
> Thanks! That's more or less the non-synthetic example I wanted to give.
 
Here's another example:
 
https://github.com/alf-p-steinbach/NPP-plugin-Empty-files-as-Unicode/blob/d16829ea2025fb0c60eec01ee97bc1be40934f9d/source/plugin/Plugin.hpp#L124
 
void update_menus()
{
using Static_id = menu::Static_cmd_id;
const auto set_item_check = [&]( const Static_id::Enum i,
const bool value )
{
npp_.set_menu_item_check( menu::dynamic_cmd_id( i ),
value );
};
 
set_item_check( Static_id::set_enabled, not is_disabled_ );
set_item_check( Static_id::set_disabled, is_disabled_ );
}
 
 
Cheers!,
 
- Alf
Paavo Helde <myfirstname@osa.pri.ee>: Jan 15 12:38PM +0200

On 13.01.2018 17:47, bitrex wrote:
 
> There might be some optimal-for-an-application solution that involves a
> structure completely unrelated to any known "pattern", maybe blows all
> of them away by a mile, in fact. How will you ever find it?
 
Deep neural network? Apparently it invented some Go strategies which no
human had thought of so far.
 
A DNN solution is however not fully satisfactory as there is not much
insight involved in those fine-tuned values of 100,000 parameters. For
human understanding it should be back-translated into some kind of
meaningful structures, possibly inventing new concepts and patterns
along the way. Not sure how well this can be done in general.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 15 02:05PM +0100

On 1/15/2018 11:38 AM, Paavo Helde wrote:
> human understanding it should be back-translated into some kind of
> meaningful structures, possibly inventing new concepts and patterns
> along the way. Not sure how well this can be done in general.
 
The "deep" in DNN means there are most probably semantic structures in
the net, i.e., it's too some degree a semantic net. The success also
points that way. However, from what I knew about neural nets 15 years
ago it's hard to identify semantic structures: one can infer their
existence, but getting the net to explain its reasoning is überhard.
 
Cheers!,
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: Jan 15 06:58AM


> I did not write the post you replied to. It was written by a deceiver
> who mocks me, and mocks God, sowing confusion and strife rather than
> truth and righteousness.
 
You deserve it. Just fuck off, you fucking spammer.
Juha Nieminen <nospam@thanks.invalid>: Jan 15 06:56AM

> You mock me by impersonating me.
 
Then just fuck off, and the mockery will stop. You will get no sympathy.
Real Troll <real.troll@trolls.com>: Jan 14 09:50PM -0400

For those of you still looking for the C++14 Standard then look no
further!! It is here in pdf from the official source:
 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf>
 
Happy reading.
 
There is still no sign of C++17 free download. It's a matter of time
for this to appear. You can buy it for around $100.
Bo Persson <bop@gmb.dk>: Jan 15 04:44AM +0100

On 2018-01-15 02:50, Real Troll wrote:
> further!!  It is here in pdf from the official source:
 
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3690.pdf>
 
> Happy reading.
 
That's a first draft of the C++14 standard. There were at least 3 more
revisions before it became official.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 15 05:57AM +0100

On 1/15/2018 4:44 AM, Bo Persson wrote:
 
>> Happy reading.
 
> That's a first draft of the C++14 standard. There were at least 3 more
> revisions before it became official.
 
The final C++14 draft I use is N4140.
 
The final C++17 draft, from March 2017, is N4659.
 
 
Cheers!
 
- Alf
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)