Soviet_Mario <SovietMario@CCCP.MIR>: Jul 01 12:18AM +0200
I left C++ quite some years ago and now that I'm beginning
again (QT Creator IDE) I can no longer have control over
scope among files.
I was used to separate code in different files, but it seems
that I have some wrong setting (maybe in the makefile
self-generated by QT, the errors are on linking)
I've tried to include the .CPP files besides the normal .H
files (with the normal protection against multiple
inclusion, #ifndef #define
ram@zedat.fu-berlin.de (Stefan Ram): Jun 30 01:30PM
Do C++ programmers have a word for a value that will yield an
iterator when being the argument value in a call to cbegin?
For, example,
cbegin( 2 )
does not make sense, because »2« is not an ... .
What must an object be so that it can be meaningfully be
the argument of cbegin? Is there a single word for it?
For example, cbegin would meaningfully accept an array,
a vector, an initialization list, or a string, but not
a pair (AFAIK), a stream, or a fundamental object.
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 30 01:35PM
>a pair (AFAIK), a stream, or a fundamental object.
PS: I'm not so sure about the stream part now.
»cbegin« possibly might accept a stream.
But maybe »cbegin« will not accept an
»::std::atomic<int>«, for another example.
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 30 02:56PM
>I mean, I think that an hypothetical 'pure' keyword would /require/ the
>function to have no side effects, instead of silently decaying to non-pure.
In mathematics, there is no requirement that the evaluation
of a function application has no effects. Instead, one just
does not talk about it (one does not study this, one does
not care about it, one does not require or specify effects).
So, a C function that has effects can double as a
mathematical function (the effects being ignored).
For example:
int twice( int const n )
{ ::std::cout << "howdy!\n";
return 2 * n; }
. This implements the mathematical function f: x :-> 2*x
(for some int values near 0).
What /is/ required in mathematics for a function is:
1.) The function must take at least one argument.
For example,
int five(){ return 5; }
implements no mathematical function, but
int five( int const x ){ return 5; }
does.
2.) The function must be deterministic.
So, after »#include <time.h>«
int five( int const x ){ return 5 + time( 0 ); }
does not implement a mathematical function,
under an implementation where time( 0 ) does
not always return the same value.
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 30 06:27PM
>Subject: C++ question
What a "smart" subject for a C++ newsgroup!
>I have the following C like C++ code:
"C-like C++ code"
>I read all that, and see that in the new syntax, apparently there is no
>way to access the index of the loop, i.e. the index of the object you
>are working on.
"New syntax" is too vague. It's "the range-based for statement".
If you need the index, don't use the range-based for statement.
| jacobnavia <jacob@jacob.remcomp.fr>: Jun 30 08:09PM +0200
I have the following C like C++ code:
for (int i=0; i<v.size(); i++) {
if (i&1) continue; // Treat only pair pixels
// Processing...
}
Well, ashamed of my lack of fluency in C++, I thought about porting that
code to the new syntax. Then, I came to meet the "range" definition.
Range-based for loop see
https://en.cppreference.com/w/cpp/language/range-for
I read all that, and see that in the new syntax, apparently there is no
way to access the index of the loop, i.e. the index of the object you
are working on.
In the "C like" code above the index is easily accessible. No big deal.
But with the new syntax, we have __begin and __bound, but we haven't
__index, so there is no way to do that C like code with the new syntax.
We lost the index with the new syntax.
Or I am just wrong and I have overlooked something?
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 30 07:33AM +0200
On 29.06.2018 22:33, Vir Campestris wrote:
> pure foo function();
> You don't need to say it's virtual. It's implied - it cannot not be
> virtual.
No, "pure" is an adjective applied to "virtual". It can be applied to
other things. Therefore it doesn't imply "virtual".
Besides, it's the phrase "pure virtual" that has a special meaning.
Just "pure" means something else.
Cheers!,
- Alf
| "Öö Tiib" <ootiib@hot.ee>: Jun 30 03:14AM -0700
On Saturday, 30 June 2018 08:34:00 UTC+3, Alf P. Steinbach wrote:
> other things. Therefore it doesn't imply "virtual".
> Besides, it's the phrase "pure virtual" that has a special meaning.
> Just "pure" means something else.
We already have "pure function" in language (in sense that it may
not have side effects) but it has obscure keyword "constexpr" to
denote that.
| Manfred <noname@invalid.add>: Jun 30 04:38PM +0200
On 6/30/2018 12:14 PM, Öö Tiib wrote:
> We already have "pure function" in language (in sense that it may
> not have side effects) but it has obscure keyword "constexpr" to
> denote that.
Good point, although, even if I am not an expert in pure functions (in
the sense you mean), I think that the fact that constexpr functions
silently decay to non-constexpr when conditions are not met, deviates
from a specification of 'pure'.
I mean, I think that an hypothetical 'pure' keyword would /require/ the
function to have no side effects, instead of silently decaying to non-pure.
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 30 05:37PM +0100
On Sat, 30 Jun 2018 16:38:04 +0200
> from a specification of 'pure'.
> I mean, I think that an hypothetical 'pure' keyword would /require/ the
> function to have no side effects, instead of silently decaying to non-pure.
When called with arguments known only at run time (that is, with values
that are not literals), a constexpr function does not as far as I can
see decay to "non-pure". Rather it decays to evaluation at run time
instead of at compile time.
I think it probably follows, from the C++ specification for constexpr
functions, that they are pure. The feature of a constexpr function
however is that it will be executed at compile time if passed values
known at compile time. That is not a requirement for a pure function
(many can be evaluated at compile time when passed literal arguments,
but not all - see below).
The requirement of a pure function in a computer science sense is that
it has no side effects and does not depend on mutable state (either
global or as a closure). On the current C++ requirements for a
function to be constexpr, you can clearly have pure functions which do
not qualify as constexpr. There is nothing to stop a pure function
using 'goto' within its implementation for example, but if it does it
cannot be constexpr.
Probably the C++ specification for constexpr functions can be expanded
further to include other pure functions. However I doubt that the two
can be completely aligned. If there were to be a 'pure' keyword in
C++, it could for example cover functions depending on const static
state. This might be relevant to a function which depends on the
number of processors on the machine executing the program; such a
function could be "pure" (on any one run it always gives the same
outputs for the same inputs) but cannot be "constexpr".
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 30 05:56PM +0100
On Sat, 30 Jun 2018 17:37:41 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
[snip]
> number of processors on the machine executing the program; such a
> function could be "pure" (on any one run it always gives the same
> outputs for the same inputs) but cannot be "constexpr".
Incidentally languages (or programs) which assume the availability of
memory (that is, which just make the program fail irrecoverably in the
event of the memory supply being exceeded, and do not throw exceptions
in that case) can nominate functions using, say, local string objects as
"pure", even where the string objects require dynamic memory. Such
functions could never be "constexpr" as the word is currently defined
in C++.
I suppose such points of detail come down to what the language decides
is "pure" in the context of whatever compiler optimizations it is
trying to support by adopting that keyword.
| Tim Rentsch <txr@alumni.caltech.edu>: Jun 30 11:03AM -0700
>> understand C++ code. This is not the only part of modern C++ that doxygen
>> doesn't quite pick up.
> IMO the C++ syntax has now jumped the shark, [...]
"jumped the shark". That's good. :)
| "Öö Tiib" <ootiib@hot.ee>: Jun 30 02:44AM -0700
On Wednesday, 27 June 2018 17:02:36 UTC+3, David Brown wrote:
> never allow short-circuit expressions that have side effects. So you
> don't allow "A && B" if B has a side-effect - you write "if (A) { B; }".
> The same goes for || and ?:.
I also think that Alf went far in his tricks of ?: and comma usage.
However that requirement in C++ coding standards does often hurt clarity
of code.
We have lot of different unavailable states in language. Few examples
are "one past back", nullptr, NaN and std::optional. The diversity of
unavailable states indicates that it is next to impossible to write
programs without that. In place where lot of things can be unavailable
but usage of short-circuiting && for availability checks is forbidden
by standard because something potentially short-circuited might have
side effects then the resulting pile of "ifs" will not improve clarity
in any way.
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 30 08:02PM +0200
On 24.06.2018 07:39, Alf P. Steinbach wrote:
> [snip]
As a compromise between succinct DRY code and what this thread says
current average programmers can grok at a glance (namely, not single
line expressions that involve all of RAII, conditional and comma) I
landed on the following more debugger-friendly but more verbose:
void cppmain()
{
using namespace std;
class With_faux_text
{
istringstream faux_input{ some_text() };
const ptr_<streambuf> original_buffer = cin.rdbuf();
public:
With_faux_text() { cin.rdbuf( faux_input.rdbuf() ); }
~With_faux_text() { cin.rdbuf( original_buffer ); }
};
class With_stream_detection
{
public:
With_stream_detection()
{
using namespace sys::io;
if( not is_connected( Stream_id::in ) ) { cin.setstate(
ios::failbit ); }
}
};
stdlib::ext::process::Command_line_args args;
if( args[1] == "--faux-text" )
{
With_faux_text{}, app::run();
}
else
{
With_stream_detection{}, app::run();
}
}
Is this, too, too complex for average current programmers?
Or would it be better to replace the commas with variable names, and if
so, what variable names would/could facilitate at-a-glance grokability?
Cheers!,
- Alf
| Tim Rentsch <txr@alumni.caltech.edu>: Jun 30 11:01AM -0700
> that it is a legacy that is practically required to stick to.
> On top of that, meanwhile this has become C++ legacy too, and breaking
> changes are notoriously on top of the "no go" list.
I found this the most sensible commentary in the thread.
As to the original question, it seems clear that what boltar is
asking for /could/ be done. The more important question is
/should/ it be done? That is a much harder question.
(<editorial>Personally I find how initializer lists are done in
C++ to be kind of half-baked. If we were working in C this
wouldn't even be a question - just write (int[]){ 1, 2, 3 } and
the problem is solved. It seems very strange that initializer
lists in C++ are wired in as special cases at selected points
in the syntax, rather than just being expressions that could
be written whenever needed. Of course I'm sure there are reasons
for why they were done as they were, but the end result is a
bigger patchwork quilt in a syntactic terrain that was already
pretty rocky. For some reason I am reminded of John McCarthy's
quote about various features added to Lisp...</editorial>)
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 30 09:45AM -0400
I have a common operation in my code where I need to reset everything
in a structure, except for portions of the structure header area that
contains something like unique ids, or linked list pointers (or a few
linked list pointers), etc.
Does anyone know of a way in C where I could easily reset portions of
the structure contents in a reliable way?
I'm thinking for CAlive to add new section {{..}} blocks, which can
be mismatched, but would allow sub-components within structures (and
classes in CAlive) to be identified and grouped together, allowing
for operations on those sub-groupings without explicit coding to do
so.
It would be something like this. Consider a definition of a strut
which contains section blocks in addition to normal member creation:
// Raw structure:
struct SExample
{
struct SLinkList ll1;
struct SLinkList ll2;
int a;
int b;
int c;
int d;
union {
int ei;
float ef;
}
float f;
float g;
float h;
};
// With section references:
struct SExample
{
section linklist {{
struct SLinkList ll1;
struct SLinkList ll2;
}} // Since this one is not nested, doesn't need closing
// "section linklist" text
section data {{
section integers {{
int a;
int b;
int c;
int d;
section floats {{
union {
int ei;
float ef;
}
section integers }}
float f;
float g;
float h;
section floats }}
section data }}
};
In this example, there are four sections defined:
linklist
data
integers
floats
Some sections overlap, but each one is defined within its {{ and }}
named range.
Having these sub-blocks within would allow access to the section
groups, including the feature I need which is to reset that portion
of the structure, yet without affecting the whole thing:
SExample e;
// Reset everything like normal
reset e; // Equivalent of memset(&e, 0, sizeof(e));
// Or only reset portions:
reset e.linklist; // memset() only the linklist {{..}} members
reset e.data; // memset() only the data {{..}} members
reset e.integers; // memset() only the integers {{..}} members
reset e.floats; // memset() only the floats {{..}} members
It would also allow sub-portions of structures to be passed by ref
or pointer, so they can be accessed as their sub-portion members,
but no more, as in:
// Definition
void my_function(SExample.floats* f)
{
// Access to the SExample.floats members here through f->
f->ef = 0.0f;
f->f = 0.0f;
f->g = 0.0f;
f->h = 0.0f;
}
Usage:
struct SExample e;
my_function(&e.floats);
Is there an existing way in C or C++ to do this?
--
Rick C. Hodgin
| Bart <bc@freeuk.com>: Jun 30 06:34PM +0100
On 30/06/2018 14:45, Rick C. Hodgin wrote:
> linked list pointers), etc.
> Does anyone know of a way in C where I could easily reset portions of
> the structure contents in a reliable way?
I'm sure you know what C is capable of, which is very little. But as
you're posting to C++ too, again anything is possible.
> section floats }}
> section data }}
> };
Defining overlapping regions like this is very bad form. And probably
explains where you weren't able to use indentation more to show the
structure, which might be more like this:
section linklist {{
struct SLinkList ll1;
struct SLinkList ll2;
section linklist}} // for consistency
section data {{
section integers {{
int a;
int b;
int c;
int d;
section floats {{
union {
int ei;
float ef;
}
section integers }}
float f;
float g;
float h;
section floats }}
section data }}
};
This makes the strange overlapping region clearer. This seems to be
frowned upon (look at HTML and XML which don't allow overlapping tag
scopes).
But here it's doubly bad because you already have a structuring
mechanism (nested, anonymous structs and unions) and you're
superimposing another one.
> reset e.data; // memset() only the data {{..}} members
> reset e.integers; // memset() only the integers {{..}} members
> reset e.floats; // memset() only the floats {{..}} members
The most useful idea here is the 'reset' feature.
(I used to have something called 'clear' I think, which I might reinstate.)
But your problem here isn't zeroing memory, but imposing an unnatural
structuring over the data. I think if that is really necessary, there
are a number of ways of doing that in C.
For example, for 'floats' section, define a dummy struct with the same
layout, and then do manipulations with pointers.
Alternatively, make use of the fact that each element of your struct is
32 bits, and alias an array to it of which you can clear selected slices.
All a bit untidy, but not that much worse than your proposal, and not
requiring yet more obscure features.
--
bart
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jun 30 01:44PM -0400
On 6/30/2018 1:34 PM, Bart wrote:
>> the structure contents in a reliable way?
> I'm sure you know what C is capable of, which is very little. But as you're
> posting to C++ too, again anything is possible.
I know a lot about C, but I still learn new things all the time. I
learned recently that sprintf() returns the length of the string,
for example. Never knew that. Would've come in handy hundreds of
times over the decades.
> number of ways of doing that in C.
> For example, for 'floats' section, define a dummy struct with the same
> layout, and then do manipulations with pointers.
And the ei/ef union?
--
Rick C. Hodgin
| Tim Rentsch <txr@alumni.caltech.edu>: Jun 30 10:22AM -0700
>>> od
>> Do you have a point here?
> You can use gotos even when the language doesn't have gotos.
I see. I didn't understand what point it was you were
originally trying to get at.
| Tim Rentsch <txr@alumni.caltech.edu>: Jun 30 10:26AM -0700
> someone can to clear this?
> i don't know even what "virtual" means, nor interst me; but i'm
> interested in the question on objects... [...]
What you're asking about is different from the topic
being discussed in what you're responding to. I don't
have anything to say on what you're asking about (if
I understand what it is, which I'm not sure if that's
true).
| Tim Rentsch <txr@alumni.caltech.edu>: Jun 30 10:28AM -0700
>> pointer/referece.
> Of course they work. (Well, unless you consider the implicit use of
> 'this' to be using the object "by pointer".)
It is! That is exactly the point.
| Siri Cruise <chine.bleu@yahoo.com>: Jun 30 10:34AM -0700
In article <kfnbmbsfatq.fsf@x-alumni2.alumni.caltech.edu>,
> >>>>>> of 'goto', even though it's one of the simplest features to implement.
> I see. I didn't understand what point it was you were
> originally trying to get at.
Python is a special.
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
I'm saving up to buy the Donald a blue stone This post / \
from Metebelis 3. All praise the Great Don! insults Islam. Mohammed
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 30 05:18PM +0200
On 30.06.2018 15:35, Stefan Ram wrote:
> »cbegin« possibly might accept a stream.
> But maybe »cbegin« will not accept an
> »::std::atomic<int>«, for another example.
"const-iterable" maybe. At least it's a descriptive term that fits the bill.
Cheers!,
- Alf
| raltbos@xs4all.nl (Richard Bos): Jun 30 10:29AM
> I'm not at all convinced that min and max operators, with whatever
> syntax, are worth adding to the language at all. If they were to be
> added, agreeing on a syntax would be difficult.
It's a very simple idea, which has been mentioned before, but has
(ttbomk) never appeared as an extension in any compiler _in a
generalisable, Standardisable manner_. Ad-hoc hacks, yes; something we
could have in the Standard, no.
That, to me, strongly suggests that there is no real desire for such a
feature in general. Everybody wants a _specific_ instance from time to
time, but those specific instances are too easy to write with what we
already have for the general feature to be worth including.
Richard
| Bart <bc@freeuk.com>: Jun 30 12:17PM +0100
On 30/06/2018 11:29, Richard Bos wrote:
> feature in general. Everybody wants a _specific_ instance from time to
> time, but those specific instances are too easy to write with what we
> already have for the general feature to be worth including.
If min/max were operators, so that they could be written as 'a max b',
perhaps as well as 'max(a,b)', then the following becomes possible:
a max= b;
as well as:
A[++i] max= lowerlim;
This I would use (as I do use when it is available elsewhere).
(And actually, the x64 processor has native MIN and MAX instructions for
floating point; presumably they were considered useful enough to
implement in hardware.)
--
bartc
Not C:
real x, y
x max:= y
Compiler output:
movq XMM0, [x]
maxsd XMM0, [y]
movq [x], XMM0
| raltbos@xs4all.nl (Richard Bos): Jun 30 10:32AM
> "Modern C++ for C Programmers: part 1"
> https://ds9a.nl/articles/posts/c++-1/
Does it give me a reason why I should bother?
No, a _real_ reason, not "it's so much better" or "it's so much more
'powerful'"? Something that isn't propaganda, but which applies to _me_?
Then I won't bother.
Richard
|
jameskuyper@alumni.caltech.edu: Jun 28 08:49PM -0700
On Thursday, June 28, 2018 at 10:20:40 AM UTC-4, Chris Vine wrote:
> > keywords may break older programs that use them as names elsewhere.
> A pure function means something completely different. That would be a
> very poor choice of words, quite apart from needing a new keyword.
We're talking about C++ here. The C++ standard defines what the term
"pure virtual function" means in the context of C++ (10.4p2). Like many
other pieces of C++ jargon, you can't interpret it correctly by
interpreting it word for word according to the generally accepted
meanings of those words - the only way to correctly understand what the
phrase means in a C++ context is to read what the C++ standard says
about such functions. That definition does not correspond to "a pure
function in the mathematical sense which is also virtual".
This is not a particularly odd occurrence in C++ - consider the term
"null pointer constant" (NPC). You might be forgiven for thinking it
should mean "a constant expression with pointer type and a null value" -
but the reality is that many constant expressions fail to qualify as
integer literals, and therefore fail to qualify as NPCs. Furthermore,
while an NPC implicitly converts to pointer types in many contexts, in
themselves they are prohibited from having pointer type.
You're free to refer to other possible meanings of the phrase "pure
virtual function", but in a C++ context you should always identify the
fact that you're not using the meaning for that term which is provided
by the C++ standard. To criticize someone for using the term in a C++
context with precisely the meaning described by the C++ standard for
that term, is to reject the whole point of having a standard.
| boltar@cylonHQ.com: Jun 29 09:02AM
On Thu, 28 Jun 2018 16:58:47 +0100
>> Either you're being pedantic for the sake of it or you're just another
>> aspie unable to follow normal discussion.
>If I were, that would be a totally inappropriate remark to make. Ad
I couldn't care less and I think you are.
>hominem remarks of that kind would just be an indication that you have
>lost the argument. So you seem not only to be lacking understanding
I haven't lost anything, you're just being defensive because you know you don't
have a leg to stand on as someone else has pointed out very eloquently. I'll
just settle for calling you an idiot.
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 29 11:36AM +0100
On Thu, 28 Jun 2018 20:49:27 -0700 (PDT)
> phrase means in a C++ context is to read what the C++ standard says
> about such functions. That definition does not correspond to "a pure
> function in the mathematical sense which is also virtual".
My point was not that in C++ the expression "pure virtual function"
means a pure function which is also virtual. I know that in C++ "pure
virtual function" refers to a virtual function without implementation.
'pure' is not at present a keyword in C++. My point was that if C++ is
going to have a 'pure' keyword, then the keyword ought to be used to
denote a pure function in the computer science sense, and not used to
denote a C++ pure virtual function (in other words, it shouldn't be
used just to provide an alternative to writing '= 0'). Out of
interest, is this a view you actually disagree with?
On whether to have 'pure' as a keyword, that raises other issues. D
has one, rust has decided not to because rust's type system deals with
the issue in other ways. I would take the lead from compiler writers
and ask them whether the keyword would provide optimization
opportunities that would otherwise be difficult to apply.
| jameskuyper@alumni.caltech.edu: Jun 29 03:47AM -0700
On Friday, June 29, 2018 at 6:37:08 AM UTC-4, Chris Vine wrote:
> On Thu, 28 Jun 2018 20:49:27 -0700 (PDT)
> jameskuyper@alumni.caltech.edu wrote:
...
> denote a C++ pure virtual function (in other words, it shouldn't be
> used just to provide an alternative to writing '= 0'). Out of
> interest, is this a view you actually disagree with?
Yes - since the C++ standard defines the meaning of "pure virtual
function", then I think would be entirely appropriate for it to be
modified to use "pure" as a keyword for the purpose of making a virtual
function be a pure virtual function. I think that using "pure" with any
other meaning would be MORE confusing.
Convince the committee that it shouldn't have used the term "pure" for
this purpose, and they can change the standard to use some other
terminology, without breaking any existing code. Unless and until you
succeed in convincing them, them it would be reasonable for them to
define a "pure" keyword with that meaning; and reasonable to criticize
their decision to use "=0" instead.
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 10:33PM +0200
> succeed in convincing them, them it would be reasonable for them to
> define a "pure" keyword with that meaning; and reasonable to criticize
> their decision to use "=0" instead.
The `=0` goes way back. It's Bjarne's work exclusively. The committee is
not to blame, they couldn't do a thing about it.
He wrote in evolution & design that it was meant to indicate no function
body.
That clashes a bit with modern C++ (possibly also the pre-standard ARM,
but my copy is not accessible to me now) where a pure virtual can have a
function body, just not in the declaration in the class.
Which is a strange inconsistency in the standard.
Anyway...
Cheers!,
- Alf
| Vir Campestris <vir.campestris@invalid.invalid>: Jun 29 09:33PM +0100
> succeed in convincing them, them it would be reasonable for them to
> define a "pure" keyword with that meaning; and reasonable to criticize
> their decision to use "=0" instead.
OK, so I'm not a mathematician - but I'm not aware of the use of pure in
maths. Chemistry, yes...
However if the intent is to replace
virtual foo function() = 0;
then shouldn't the syntax be
pure foo function();
You don't need to say it's virtual. It's implied - it cannot not be virtual.
Andy
| David Brown <david.brown@hesbynett.no>: Jun 28 10:10PM +0200
On 28/06/18 16:53, Alf P. Steinbach wrote:
> their eyes glaze over?
> I hadn't ever dreamed that current programmers have such difficulties.
> But I'm learning. And maybe we can nail this more precisely. ;-)
I think you'll have a lot of difficulty trying to get a precise point
here - this is not a binary issue. The "maximum" example is easy, your
original code is hard, and in between there is a sliding scale. It
takes experience and a good understanding of other programmers to be
able to tell if code is /too/ hard - and it will depend massively on the
details of the code, the type of problem you are solving, and of course
the programmers who are looking at the code. There is no black and
white answer here - sorry.
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 29 06:08AM +0200
On 28.06.2018 20:03, Bart wrote:
> The same argument applies to the comma operator; you use it when you
> really need to evaluate one expression inside another, and not just to
> be able to write:
In this case one really needs to evaluate one expression inside another.
The control structure expresses exactly the intent.
> else
> With_stream_detection{}._);
> app::run();
Here cleanup is performed before `app::run()`, which means it will never
get executed with faux text.
> : With_stream_detection{}._),
> app::run();
> but it's not as good as just writing it properly.
So it seems that /formatting/ is crucial. Thanks.
Cheers!,
- Alf
| woodbrian77@gmail.com: Jun 28 09:44PM -0700
On Wednesday, June 27, 2018 at 3:54:28 PM UTC-5, Alf P. Steinbach wrote:
> and `goto` a common cleanup.
> We use it because it's easier to understand and analyze, to prove
> correctness of, due to the simple guarantees.
Agreed, but iirc Nicolai Josuttis told of a problem he ran
into with RAII. He had a lock but didn't give it a name.
So the scope of the lock started and ended on the same line.
If he can be tripped up by RAII and temporaries this way,
it's not always easy breezy.
Brian
Ebenezer Enterprises - In G-d we trust.
https://github.com/Ebenezer-group/onwards
| David Brown <david.brown@hesbynett.no>: Jun 29 09:12AM +0200
On 29/06/18 06:08, Alf P. Steinbach wrote:
>> app::run();
>> but it's not as good as just writing it properly.
> So it seems that /formatting/ is crucial. Thanks.
I would not go as far as to say the change in formatting makes the code
good, but it certainly makes it a lot clearer. It also gives spots for
adding comments if that helps. (I do not advocate comments as an
alternative to writing clear code - but sometimes code has to be
complicated, and comments can then help.)
Even something as simple as changing the spacing can greatly improve the
readability of code.
| ram@zedat.fu-berlin.de (Stefan Ram): Jun 29 05:21AM
>a pure function in the mathematical sense
I am not aware of "pure function" being a common
mathematical term.
>while an NPC implicitly converts to pointer types in many contexts, in
>themselves they are prohibited from having pointer type.
What'll you tell me next? That a vector of bool is
neither a container nor does it contain bools? But, yeah,
main.cpp
#include <iostream>
#include <ostream>
#include <type_traits>
template< typename T > void describe( T const )
{ ::std::cout << ::std::is_pointer< T >::value << '\n'; }
int main() { describe( nullptr ); }
transcript
0
|
Sent from my iPad
Begin forwarded message:
From: Hsiao Hung < k6hsi@aol.com> Date: June 28, 2018 at 8:07:48 PM CDT Subject: Fwd: 黃公望與富春山居圖
Subject: Fwd: 黃公望與富春山居圖
50歲學畫，80歲畫神作，人生若覺無作為，願君讀讀黃公望https://youtu.be/dUPYM9qipiI*********************************************************************世上只有一種成功，就是用你喜歡的方式度過一生。不泯然於眾，只遵從內心真實的感受，欣然向前。明末年間，有一副畫傳到了著名的收藏家吳洪裕手上，他把這副畫看得比命還重。去世前，跟家裡人說了句：這幅畫我得帶走，你們把它燒了吧。家人看著吳洪裕死前最後一口氣都咽不下去，只好當他的面開始燒這幅叫《富春山居圖》的畫，侄子吳靜庵趕到，一把將畫從火盆里奪出。畫燒成兩截，前半截為《剩山圖》，後半截為《無用師卷》。畫這副畫的人是一個元朝人，叫黃公望。生活里，我們翻山越嶺，登舟涉水，山一程、水一程，有時候走著走著，頓覺一生一事無成，便開始抱怨自己碌碌無為。人生若覺無作為，推薦你讀讀黃公望。01公元1269年，黃公望出生於江蘇常熟。他是那個時代最大的loser，從小讀遍四書五經，考科舉，到了45歲，才在浙西廉訪司當了一名書吏。官還沒做幾天，他的上司張閭，因貪污舞弊掠奪田產逼死了九條人命，朝廷抓了張閭，順道把黃公望也抓了。等黃公望出獄時，已經過了五十歲。想想這一生，也快走到了盡頭。元朝的一天，黃公望正在屋裡寫字，做官的朋友來了。跟他說： 「去我府上做書吏吧！」黃公望把筆一放，說了句：做官，不去了，不去了，你趕緊回吧，我也要出門了。官場朋友問：你要去哪？黃公望答：當道士！黃公望門也不鎖，拂身而去，從此浪跡天涯。那一天起，黃公望便開始向人生莽原出發，與過去的生活徹底決裂。他不再討好誰，也不再將時間浪費在無聊的人、無聊的事上，他過極簡的生活，並有乘風破浪的氣勢。一個人真正的成熟，是從懂得認識自我開始的。在古代，50歲已是人生暮年，也許等待黃公望的除了死亡，也就剩下死亡了。可死亡從來不是人生最可怕的事情，人生最可怕的事是人未老，心已死，心死了，時間也會跟著死了。對於黃公望來說，他的人生盛宴才僅僅是剛剛開始！02黃公望學畫畫，想到了就立馬去學。他來到大畫家王蒙那裡，王蒙是大畫家趙孟頫的外甥，棄官隱居於浙江餘杭的黃鶴山。王蒙一看黃公望都年過半百了。就擺手說：你都五十了，還學什麼呢？太晚了，回去吧！黃公望並不在意，悶頭就學，在任何人看來，這都是不可能完成的事。可是黃公望卻偏偏在紙張上出發了。他每天坐在一塊大石頭上，盯著對面的山看，一看就是幾個小時，眼都不眨。幾個月過後，黃公望畫畫大有長進。王蒙不解，跟著他身後去看。每次都看到黃公望坐在大石頭上紋絲不動，像個死人。後來實在忍不住了就問：「你每天都坐在大石頭上，幹什麼呢？」黃公望說：我在看山看水啊，觀察鶯飛草長，江流潺潺，漁人晚歸。王蒙說了句：那你繼續看吧！之後的29年里，黃公望走遍山川，遊歷大江，走哪看哪，極度專注，沒有人知道他去過哪裡，好像他的行蹤是一個永恆的謎。但是只要他安靜下來，整個世界好像都是和他無關的。03元朝至正七年，這一年黃公望整整79歲。那是一個秋天，落葉繽紛。黃公望和師弟無用，從松江遊歷到浙江富陽。只見富春江面，江面如練、漁歌唱晚，他跟無用說：我不走了，我留下來畫畫。無用說：你自己留下來，沒有人照顧你怎麼辦？黃公望一個人坐下，氣定閒神。不管無用師弟如何勸他，他也紋絲不動。無用師弟只好一個人獨自雲遊去了。79歲的黃公望在富陽住下，每天都是一個人，孤零零地到富春江邊看山看水。一天中午，黃公望來到城東面的鸛山磯頭，坐在富春江邊的礁石上，拿出紙筆，對著江岸開始作畫。突然背後有人一把將他推入江中。推他的人是黃公望以前的上司張閭的外甥汪其達。當年黃公望在監獄里供出了張閭的罪行，汪其達懷恨在心，這恨一裝心裡便是30年。查到黃公望的行蹤後，就偷偷下了毒手，要致黃公望於死地。黃公望掉進江裡，差點沒命，這時正好有一個樵夫路過，扔了擔子跳入江中，把黃公望救了起來。樵夫古道熱腸，跟他說：既然有人要害你，你這麼大年齡了，又不能自保，我家住在江邊的山上，你住我家吧。黃公望步履蹣跚，跟著樵夫踏上了沿江而下的驛道，走了不到十里路，來到一個叫廟山塢的山溝裡。當登上一道山梁，眼前出現了一片凸起的平地，零星住著七八戶人家。此處三面環山，一面臨江，酷似一隻淘米的竹編筲箕。黃公望舉目四望，此處山巒起伏，林木蔥籠，江水如練。整個富春江盡收眼底，景致奇美！04黃公望就此住下，一住就是四年。這四年里，天一亮，黃公望就戴著竹笠，穿著芒鞋出門，沿江走數十里，風雨無阻。遇到好景就停下來畫，心隨念走，身隨緣走，在他刪繁就簡的人生里，所到之處皆為風景。人真正的成熟，就是明白每天發生在我們身邊的99%的事情，對於我們和別人而言，都是毫無意義的。黃公望就是這樣的人，他只把全部的精力放在自己關心、傾注的1%的美好事物上。周圍的人看著黃公望都說：這個老人，都快死的年紀了。每天還活得匆匆忙忙，何必呢？而對於黃公望來說，死是一件並不著急的事，他每天快要忙死了，忙著做自己該做的事。總是有畫不完的畫，寫不完的字，走不完的路，看不完的景。他是真忙，忙死了！除了畫畫，黃公望常常接濟村裡人。有一次，他拿出一幅畫，落款「大痴道人」，讓樵夫帶到城裡去賣，並囑咐：沒有十兩銀子不要出手。樵夫一聽，這張皺巴巴的紙要賣十兩銀子，覺得這老人准是想錢想瘋了。當他來到集市，鋪開那張紙。立馬有買家過來，掏出十兩銀子，買了就走。樵夫很吃驚，自己就是砍一年的柴，也掙不到十兩銀子啊。這以後，黃公望每兩三個月就讓樵夫去賣一幅，賣畫所得全部接濟村民。這個村被黃公望的畫生生包養成了小康之村。05黃公望80歲那年，開始正式畫《富春山居圖》。他要在這副畫中講述一條河流的一生，他要在這幅畫中，講述時代和人類的悲喜。對於別人來說，畫如此大畫，本來就是艱難的，更何況是一個80歲耄耋老人呢。可對於黃公望來說，他做每件事從不管別人如何評價，我高興，我開心，這就夠了，我就是要在紙上出發。雖然我已80歲，難道就應該「泯然於眾」，內心的感受才是這個世界上最重要的事。富春江的四面，有十座山峰，峰峰形狀不同，幾百棵樹木，棵棵姿態迥異。黃公望踏遍了富春江兩岸，背著畫卷帶著乾糧一路前行。漁舟唱晚，樵夫晚歸，山林寂靜，流水無痕都變成了他人生的注腳。在中國歷史上，從來沒有一個人用了四年，和河流真正的對話。對話中，可以說富春江讀懂了黃公望，黃公望也讀懂了富春江。《富春山居圖·無用師卷》局部06四年之後，黃公望84歲，被後世稱為"中國十大傳世名畫"之一的《富春山居圖》全部完成。在這幅畫里，有蘇東坡想看的「遠山長、雲山亂、曉山青」，也有屈原想看到的滄浪之水，可以濯吾纓。黃公望彷彿聽到河流喜悅的聲音。也聽到了河流哭泣的聲音，聽到自己科考時的得意，也同樣聽到了他46歲時坐牢的痛苦。畫中，黃公望把人藏在山水之中，畫里有8個人，一般的人只能找到5個。在黃公望看來，人在山水之中，不需要被別人看到，領悟與回顧，人的一生，其實就是也無風雨也無晴。600多年前，80歲的黃公望用了一生只做了一件事，就是完成自我。和我們普通人相比，黃公望也許是苦悶的，沒有燈紅酒綠，也沒有推杯換盞的聲色犬馬，而人的生命中最承受不起的不是勞苦、不是疲憊，而是輕浮，輕浮得沒有生命的重量、沒有生命的價值。黃公望也是幸福的，在這副「遠山長、雲山亂、曉山青」的畫里，他找到了整個世界。現實生活里，我們常常聽別人說自己年齡大了，無法前行。其實真正牽絆自己前行的原因不是年齡大了，而是懶惰和懷疑。真正要出發的人，隨時出發，便會海闊天空。作家三毛說：「等待和猶豫是這個世界上最無情的殺手。」你一直在等一個最合適的時機做你想做的事，然後又一直在猶豫中虛度時光。試想一下，當我們在80歲的時候，還有沒有勇氣為自己準備新的追求，還有沒有勇氣做選擇，還能不能真的堅持做一件「不死不休」的事兒？前半卷《富春山居圖·剩山圖》尺幅：縱31.8釐米，橫51.4釐米後半卷《富春山居圖·無用師卷》全卷尺幅：縱33釐米，橫636.9釐米07當黃公望將《富川山居圖》畫完，他長舒一口氣，重重將筆扔入江中，長吁這一生，我完成了。這些年，他的師弟無用到處找他，公元1353年，無用師弟終跟隨著賣畫的樵夫找到了黃公望。當看到巧奪天工的《富春山居圖》時，無用師弟熱淚縱橫。而喜極而泣的黃公望則不發一言，悄然在畫卷題字，舉手將自己用了全部生命完成的《富春山居圖》，贈予無用師弟。四年的嘔心瀝血，黃公望毫不在意，與其獲取浮名，不如一場君子之交。與現在的人相比，黃公望才是真的灑脫，也是真的曠達，他像是一個種花的人，種下、施肥、然後用數年之久等待花開，花開一瞬，他卻將花摘下，舉手贈予他人。真正的曠達就是享受追求的過程，而從不在意結果的得失。真正的灑脫是廣廈萬間，我夜眠不過七尺，良田千頃，我日食不過三餐。我想要的很少，心滿意足，這就足夠了。一年後，黃公望長笑而逝。至今依然可以想到，663年前，一位元朝的老人離世，在離世時，臉上一定無比安詳，面帶微笑。他的一生毫無遺憾地走了！08故事講完了嗎？並沒有！黃公望離世之後，這副畫的經歷更加離奇。明朝的某年某月，這幅畫到了江南四大才子沈周手裡，沈周視為珍寶，可在一個深夜，畫作竟不翼而飛，然後就在歷史上徹底消失了。又過了一百五十年，順治七年（1650年），《富春山居圖》突然出現在著名收藏家吳洪裕手上，在他收藏上萬件藏品中，唯獨只愛《富春山居圖》。把畫看得比命還重。病逝之前，奄奄一息的吳洪裕躺在床上，吃力地向家人吐出一個字： 「燒！」家人看著吳洪裕最後一口氣都咽不下去，只好當他的面開始燒《富春山居圖》，就在畫投入火盆的時候，侄子吳靜庵趕到，一把畫將畫從火盆中拽了出來。可惜這幅畫已被燒成兩截，前半截，稱之為《剩山圖》，後半截稱之為《無用師卷》。兩幅畫輾轉多位藏家手中，歲月沈浮，在民間若隱若現。1938年，《剩山圖》進入浙江博物館。1948年，《無用師卷》輾轉到達台灣。從此《富春山居圖》前後兩截分隔兩地。2011年6月1日，距離吳洪裕燒畫那一年，整整過去了361年。《富春山居圖》的兩截，《無用師卷》和《剩山圖》才在分別之後，正式在台北故宮博物院重新遇見。兩岸的文化人說這叫： 「山水合璧」！這一切，就像一個人的命運，生死別離，天涯斷腸，就如杜甫詩：人生不相見，動如參與商。故事到此講完了，講故事的人最有心，聽故事的人總動情。複製品《富春山居圖·剩山圖》和《富春山居圖·無用師卷》疊在一起合成一卷的局部圖原畫有《富春山居圖·無用師卷》右半部分在裝裱時加上題詞，兩卷無法合一09600多年過去，當年80歲的黃公望在富春江畔駐足，然後用了整整用了4年，只做了一件事。今天，學會了如何生存的我們，卻遠沒有學會如何生活。我們迷失在了手段裡，卻忘了不論多大的事業，真正的目的是為了生活。如何才能找到自己，其實答案就在黃公望的《富春山居圖》里。今天我們學習黃公望，是學習選擇。生活有兩條路，一條是社會要求我們走的，一條是我們自己想走的，你只有堅定內心的選擇，並奔赴向前，才能活出真正的那個自己。今天我們學習黃公望，是學習等待。在匆忙的生活中，試著放緩自己的腳步，讓等待變成一種心態，一種態度，只有坦蕩如水時，你才能看到最美的東西。今天我們學習黃公望，是學習灑脫。讓自己灑脫地安靜下來，聆聽自己的心跳與呼吸，我相信，只有這樣，你的生命走出去時才不會慌張。今天我們學習黃公望，是學習尋覓。若你還算年輕，你還敢不敢沸騰一下血液，綁緊鞋帶重新上路，敢不敢勇敢一點兒面對自己，去尋覓那些能讓自己內心強大的力量？然後，此生無憾。https://youtu.be/dUPYM9qipiISent from my iPhone
Juha Nieminen <nospam@thanks.invalid>: Jun 28 05:12AM
> I didn't see Boltar's comment because he's in my kill file.
> And you're pretty close now, again.
> Just a heads up.
You are going to killfile me because I'm quoting Bjarne Stroustrup?
| David Brown <david.brown@hesbynett.no>: Jun 28 10:39AM +0200
On 27/06/18 22:54, Alf P. Steinbach wrote:
>> cases it is common enough - for the sort of usage you have here, it /is/
>> obscure.
> How can a single ?: be obscure?
It is a matter of how you use it - it is not the ?: operator itself that
is hard. "(a < b) ? b : a" is fine. Your monstrosity is not.
> Beginners learn it, very early on, and you say some experienced
> programmers you've encountered find it challenging?
Beginners learn the syntax for ?:, and then a fair proportion promptly
forget about it and don't use it in normal code. However, I don't claim
many programmers would find something like the "maximum" ?: example to
be difficult. I am saying that the code /you/ wrote, with it's unusual
syntax, its use of poorly-understood lifetime rules, and unhelpful
layout is obscure, hard to understand, and easy to get wrong.
Good code is /clear/. It is clear what the code does, and what the code
does not do. The layout should reflect the logic of the code.
As to what experienced programmers would think about it - just read the
replies you have got in this thread. There are plenty of experienced
C++ programmers here - none of them think this is a good way to write
code, several have asked what it does, and others have simply not
bothered to even try to figure it out. The most positive response you
got was from me - that it is an interesting experiment, but not
something for real code.
> I find that claim hard to believe.
I am not sure what your normal programming environment is - maybe you
write your code alone. You have a very odd style, and are perhaps a
poor judge of what other people find comfortable in their coding. In
any coding review I have seen, your typical c.l.c++ code would be
rejected outright - reviewers would assume it is obvious where the
problems lie.
This does not mean your code is wrong - or even that there is a problem
with your style. It means it is significantly different from normal
styles - enough to be difficult and error-prone for many people to
interpret, and enough to be seen as different merely for the sake of
being different or appearing clever. Personally, I think it is good
sometimes to see such variation, and it can help us all learn - but I
would hate to have to /work/ with your code.
To balance this, it is clear that all programmers have a style and a
view of "normal programming styles" that is heavily influenced by the
type of work they do. That applies to me as well as anyone else.
> evident, one expects such an expression to just compute a boolean value.
> But
> 1. it isn't /always/ bad to do that with boolean expressions, and
There are a few idioms that rely on non-execution of parts of
expression, like "p && foo(*p)". As a C or C++ programmer, you need to
be familiar with these sorts of things to understand other people's code.
That does not mean it is a good idea to /write/ them. And coding
standards that are concerned with quality code, ban them. Here are a
couple of rules from MISRA (yes, I know MISRA has its faults):
Rule 12.3: The comma operator should not be used.
Rule 13.5: The right hand operand of a logical && or || operator shall
not contain persistent side effects.
This allows things like "x = p && cos(p);", but not "p && printf(*p)".
The point is that if someone reads quickly over the code and assumes
that the right-hand operand is evaluated in some cases when it is not,
it does not affect the logic of the code.
Having said that, there can certainly be places where this kind of thing
/can/ be appropriate. Deep within library code, you sometimes need code
constructs that are unusual, complicated, or take a long time to
understand. There is plenty in the implementation of the C++ standard
library that is beyond the comprehension of most C++ programmers.
> 2. a choice expression isn't like a boolean expression.
It is in this sense.
> operations that indicate success/failure via boolean returns:
> // A. OK for me
> const bool success = a() and b() and c() and d() and e();
Functions called "a", "b", etc., are not okay for me in real code - they
would have longer names. So this would have to be spread across many
lines - not okay. And real code would likely have parameters, and
probably some code between the function calls.
You are mistaking a hypothetical example with real code.
> Again, compare that to
> // OK for me
> const bool success = a() and b() and c() and d() and e();
There are many other ways to do this:
bool success = true;
if (success) success &= a();
if (success) success &= b();
if (success) success &= c();
if (success) success &= d();
if (success) success &= e();
or:
bool doAll() {
if (!a()) return false;
if (!b()) return false;
if (!c()) return false;
if (!d()) return false;
if (!e()) return false;
return true;
}
const bool success = doAll();
or:
bool success = false;
do {
if (!a()) break;
if (!b()) break;
if (!c()) break;
if (!d()) break;
if (!e()) break;
success = true;
} while (false);
> never allow short-circuit expressions that have side effects." appears
> to mean that the coding standards that you regard as decent, require the
> fantastic ugliness and awkwardness of (B) or (C) above.
No, it merely means you can imagine beauty in unrealistic examples, but
can't imagine good ways to implement real code.
> Regarding (2), that a choice expression isn't like a boolean expression,
> choice expressions are IME much more commonly used for side effects than
> boolean expressions are, especially where a result value is used.
And it would be, IME, an even worse idea to rely on side-effects and
lack thereof in a conditional expression compared to a logical one.
(If the gcc extension of statement expressions were to be included in
standard C and C++, it would allow you to express some of these things
neatly and clearly.)
>> would be a /good/ way to write it.
> Yes, considering all possibilities is often useful.
> If for nothing else, one might learn something from the exercise. :)
That is what we are doing here!
>> give new ideas. Writing it in actual serious code is "smart-arse",
>> which is no longer a complement.
> I don't get what's fancy or "smart" about it.
Ah, so you haven't learned enough yet :-)
>> coding practice.
> But what is it that's Greek to you, or that you suspect would be Greek
> to most others, in the code?
I mean like making "a Π b" be an intersection operator for sets.
> and `goto` a common cleanup.
> We use it because it's easier to understand and analyze, to prove
> correctness of, due to the simple guarantees.
Yes, of course - it is better to write code with lower risks of bugs
than to write code that makes it easier to find the bugs.
| PoorOldAlFSaysMrBoltar@sadsack.com: Jun 28 09:22AM
On Wed, 27 Jun 2018 21:45:47 +0200
>On 27.06.2018 15:41, MrBoltarToYou@galactic.com wrote:
>> snip
>Your third identify to be killfiled by me.
It really makes little odds, I write my posts in vi and editing the From:
line takes seconds. You might end up with a very big kill file. Assuming you
actually use one and its not all just bluster.
| Manfred <noname@invalid.add>: Jun 28 01:59PM +0200
On 6/28/2018 10:39 AM, David Brown wrote:
> if (success) success &= c();
> if (success) success &= d();
> if (success) success &= e();
Since &= is a bitwise operator, I'd rewrite this as:
bool success = true;
success = success && a();
success = success && b();
success = success && c();
success = success && d();
success = success && e();
But still I'd prefer Alf's expression, possibly split across multiple lines:
const bool success = a() and
b() and
c() and
d() and
e();
Which incidentally keeps the const qualifier (which is something I value)
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 28 04:53PM +0200
On 28.06.2018 10:39, David Brown wrote:
>> How can a single ?: be obscure?
> It is a matter of how you use it - it is not the ?: operator itself that
> is hard. "(a < b) ? b : a" is fine. Your monstrosity is not.
Well, let's investigate at what point you, or the programmers you
imagine, lose comprehension.
1. (s == "blah"? 1 : 2)
2. (s == "blah"? DerivedA{} : DerivedB{})
3. (s == "blah? A{}.x : B{}.x)
Has the conditional turned into a somewhat incomprehensible monstrosity
already in 2, or is it the use of a data member, as in 3, that makes
their eyes glaze over?
I hadn't ever dreamed that current programmers have such difficulties.
But I'm learning. And maybe we can nail this more precisely. ;-)
> [snip]
Cheers!,
- Alf
| Bart <bc@freeuk.com>: Jun 28 07:03PM +0100
On 28/06/2018 15:53, Alf P. Steinbach wrote:
> their eyes glaze over?
> I hadn't ever dreamed that current programmers have such difficulties.
> But I'm learning. And maybe we can nail this more precisely. ;-)
I think this is the expression involved:
(args[1] == "--faux-text"? With_faux_text{}._ :
With_stream_detection{}._), app::run();
When I first glanced at this, I assumed it was in this form:
(A ? B : C, D);
With the D, as I thought, belonging to the C as I assumed that this was
one ?: term only, not a ?: term then something else. Actually it's like
this:
(A ? B : C), D;
That is, it evaluates B or C then executes D. At least, you do use
parentheses around the ?: which is rare in C code.
That your version is confusing might be something to do with it using 18
punctuation tokens, 22 punctation characters, 5 underlines, 3 hyphens,
and long indentifier names that look more like comments.
Now, ?: is used when you want to evaluate either x or y, and need to
immediately use the result of that within an expression. If you don't
need to use the actual value, just the side-effects, then you shouldn't
use ?:, as you would just being using it to avoid writing a proper
if-else statement.
The same argument applies to the comma operator; you use it when you
really need to evaluate one expression inside another, and not just to
be able to write:
X, Y;
instead of:
{X; Y;}
If you apply those guidelines, then your example becomes:
if (args[1] == "--faux-text")
With_faux_text{}._;
else
With_stream_detection{}._);
app::run();
Now you have form and indentation to help you see the structure. This
could with ?: and comma too:
(args[1] == "--faux-text"
? With_faux_text{}._ :
: With_stream_detection{}._),
app::run();
but it's not as good as just writing it properly.
--
bart
| David Brown <david.brown@hesbynett.no>: Jun 28 10:10PM +0200
On 28/06/18 16:53, Alf P. Steinbach wrote:
> their eyes glaze over?
> I hadn't ever dreamed that current programmers have such difficulties.
> But I'm learning. And maybe we can nail this more precisely. ;-)
I think you'll have a lot of difficulty trying to get a precise point
here - this is not a binary issue. The "maximum" example is easy, your
original code is hard, and in between there is a sliding scale. It
takes experience and a good understanding of other programmers to be
able to tell if code is /too/ hard - and it will depend massively on the
details of the code, the type of problem you are solving, and of course
the programmers who are looking at the code. There is no black and
white answer here - sorry.
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 28 12:56AM +0100
On 27 Jun 2018 20:29:34 GMT
> auto f();
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
I think this is a bit of a side issue. My view is that you should
instead avoid C++14 deduced return types where you actually know what
the return type is, except in the case of short lambda expressions, as
a matter of good form and making your code intelligible. This is apart
from the documentation difficulties to which you refer.
Where you don't necessarily know what the return type is, this was
rather more self-documenting with C++11. With C++11 when deducing
return types you had to have a trailing return type specified using a
decltype expression (or std::result_of) except in the case of single
statement lambda expressions (I think, it's going back a bit now).
Doxygen does correctly document that form for you. There is nothing to
stop you doing that with C++14 also, but this sort-of offends the DRY
principle since it is duplicative.
I have only mainly used auto with C++14 deduced return types in cases,
say in template code, where you do not actually know what the return
type is in advance. This is often coupled with the use of decltype on
the function having that deduced return type[1], because the function
is used for compile time metaprogramming and is never actually executed
at all.
Usually such functions with deduced return types are not part of the
public API anyway. Where they are, I think the documentation should
explain the position.
Chris
[1] This is decltype applied to the function application itself, in
order to generate a type. It is not the same as using decltype in a
C++11 style auto return type function declaration.
| Sam <sam@email-scan.com>: Jun 27 05:14PM -0400
Stefan Ram writes:
> auto f();
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
Avoiding a very useful, new language feature only because a documentation
tool can't deal with it doesn't seem like a good reason to me.
With the increased complexity of C++, only an actual C++ compiler can fully
understand C++ code. This is not the only part of modern C++ that doxygen
doesn't quite pick up.
I find doxygen very useful, and I use it a lot. I do not take into
consideration doxygen's limitations when writing code. I only review
doxygen's output after the fact; and make whatever manual fixes and tweaks
to doxygen's output that can be reasonably done.
| Juha Nieminen <nospam@thanks.invalid>: Jun 28 05:20AM
> ought to define an interface (that's the I) but auto depends on the
> implementation details. With something having an official API it should
> be vice versa, implementation should depend on the interface.
Note that using 'auto' in an API might sometimes be justified.
More particularly as a synonym for "none-of-your-business type".
I'm not joking. The most prominent example of this would be
the actual type of a lambda. It's quite literally "none of your
business". The programmer shouldn't concern himself about what
the actual type of a lambda is, hence it's always used as 'auto'.
The actual underlying type is unspecified, and up to the compiler,
and code using lambda should never try to use that type explicitly.
| David Brown <david.brown@hesbynett.no>: Jun 28 10:48AM +0200
On 27/06/18 22:29, Stefan Ram wrote:
> auto f();
> is hardly helpful. So should we avoid the auto return type
> for functions which are part of an API for this reason?
No, you should avoid having the auto return type in an API because it is
a daft thing to have in an API. An API should be specific, and say
/exactly/ what it returns. (In cases where that is impossible, such as
in some template functions, you need to question your coding structure
and API design before resorting to auto.)
"auto" is extremely convenient for local functions - static functions,
anonymous namespaces, private methods, etc. It is not something you
would want in an API. That applies to functions, variables, consts, etc.
| boltar@cylonHQ.com: Jun 28 09:40AM
On Wed, 27 Jun 2018 17:14:59 -0400
>With the increased complexity of C++, only an actual C++ compiler can fully
>understand C++ code. This is not the only part of modern C++ that doxygen
>doesn't quite pick up.
IMO the C++ syntax has now jumped the shark, its far to complex and rivals
Perl in its hideousnous. Originally it was commented that uglies such as
"virtual func() = 0" instead of "pure virtual func()" were because extra
keywords may break older programs that use them as names elsewhere. Then
we had new keywords such as override, final, explicit etc added anyway making
that argument moot. Then things got work and IMO the syntax reached its
nadir with the "[=/&]() -> <return type> { }" horror of lambda functions.
We have std::function. Why the hell didn't they simply introduce std::lambda
with a similar syntax?
eg: std::lambda<int((<local scoped vars>,(parameters)> { }
Or just do what other languages do and use the same syntax as primary functions
eg:
func(int mylambda(a,b,c) { }) or similar?
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 28 03:20PM +0100
On Thu, 28 Jun 2018 09:40:42 +0000 (UTC)
> Perl in its hideousnous. Originally it was commented that uglies such as
> "virtual func() = 0" instead of "pure virtual func()" were because extra
> keywords may break older programs that use them as names elsewhere.
A pure function means something completely different. That would be a
very poor choice of words, quite apart from needing a new keyword.
> Then
> we had new keywords such as override, final, explicit etc added anyway making
> that argument moot.
The argument is never moot. Presumably it was felt that the advantages
of having override, final and explicit as keywords outweighed the
potential for breakage, which would have been very small.
> We have std::function. Why the hell didn't they simply introduce std::lambda
> with a similar syntax?
> eg: std::lambda<int((<local scoped vars>,(parameters)> { }
A comma separating the captured variables from parameters, when
parameters are already separated by commas? Or are you inventing
a new meaning for parentheses (it is not clear because yours are
unbalanced). This syntax is hopeless. I prefer what we have.
> Or just do what other languages do and use the same syntax as primary functions
> eg:
> func(int mylambda(a,b,c) { }) or similar?
Because C++ language rules require you to find some way of identifying
the captured variables and whether the capture is to be by reference or
by value. To try to introduce automatic lexical closures as in
some other languages would have been a significant alteration to C++ and
wouldn't have worked. Languages which do have that generally work on
the basis that numbers and characters (so called "immediate" values) are
copied by value and any other object is copied by reference.
I think you are too easily offended by language syntax. Try another
language - there are plenty to choose from.
| boltar@cylonHQ.com: Jun 28 02:34PM
On Thu, 28 Jun 2018 15:20:20 +0100
>> "virtual func() = 0" instead of "pure virtual func()" were because extra
>> keywords may break older programs that use them as names elsewhere.
>A pure function means something completely different. That would be a
It does? Please enlighten us because in C++ the "= 0" on the end definately
means pure virtual. Perhaps you're getting confused with another language.
>The argument is never moot. Presumably it was felt that the advantages
>of having override, final and explicit as keywords outweighed the
>potential for breakage, which would have been very small.
Ditto "pure".
>> eg: std::lambda<int((<local scoped vars>,(parameters)> { }
>A comma separating the captured variables from parameters, when
>parameters are already separated by commas? Or are you inventing
My mistake, I meant to write ";" as used in for().
>a new meaning for parentheses (it is not clear because yours are
>unbalanced). This syntax is hopeless. I prefer what we have.
Presumably you think the std::function syntax is hopeless too then.
>I think you are too easily offended by language syntax. Try another
I'm offended by hacks, which is what C++ seems to be descending into.
>language - there are plenty to choose from.
Most are flavour of the month with little real traction and any language take a
long time to become proficient in anyway. I have better things to do with my
time than start from scratch.
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 28 03:58PM +0100
On Thu, 28 Jun 2018 14:34:30 +0000 (UTC)
> >A pure function means something completely different. That would be a
> It does? Please enlighten us because in C++ the "= 0" on the end definately
> means pure virtual. Perhaps you're getting confused with another language.
Look it up, and give yourself a broader background. If 'pure' were to
be used as a keyword, it would be to mark that a function is without
side effects, not to indicate that it is a virtual function without
implementation. Various languages have a 'pure' keyword, such as D; I
would not especially support its introduction in C++ but it should be
left alone for that use in case in the future others decide otherwise
as it may possibly have optimization benefits; it should not be expended
to give effect to your proposal.
> >of having override, final and explicit as keywords outweighed the
> >potential for breakage, which would have been very small.
> Ditto "pure".
No - see above. Your proposition that having 'overide, final and
explicit' as keywords means a free for all for any other half-baked
keyword anyone on a newsgroup thinks should be used, because it is now
"moot", is ridiculous. It is even more ridiculous when 'pure' already
has a well accepted and different meaning.
> >a new meaning for parentheses (it is not clear because yours are
> >unbalanced). This syntax is hopeless. I prefer what we have.
> Presumably you think the std::function syntax is hopeless too then.
You are missing the point. It does not make closures, and the syntax
of std::function does not provide for it to do so. If you want to have
a closure with std::function you have to construct it specifically with
a lambda expression, std::bind or the like. In fact, you have
deliberately snipped the part of my post which previously explained this
to you.
> Most are flavour of the month with little real traction and any language take a
> long time to become proficient in anyway. I have better things to do with my
> time than start from scratch.
Broadening your knowledge would help you avoid the temptation to think
that you know it all when it is apparent that you do not.
| boltar@cylonHQ.com: Jun 28 03:06PM
On Thu, 28 Jun 2018 15:58:45 +0100
>be used as a keyword, it would be to mark that a function is without
>side effects, not to indicate that it is a virtual function without
>implementation. Various languages have a 'pure' keyword, such as D; I
In C++ that is the definition of pure. This discussion is about C++ not
the general definition of pure virtuals as you see it.
>> Ditto "pure".
>No - see above. Your proposition that having 'overide, final and
Yes.
>"moot", is ridiculous. It is even more ridiculous when 'pure' already
>has a well accepted and different meaning.
Not in C++.
>Broadening your knowledge would help you avoid the temptation to think
>that you know it all when it is apparent that you do not.
Spare me your feeble attempts at being patronising, they're falling flat.
I suggest you get your own clue.
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 28 04:25PM +0100
On Thu, 28 Jun 2018 15:06:27 +0000 (UTC)
> >implementation. Various languages have a 'pure' keyword, such as D; I
> In C++ that is the definition of pure. This discussion is about C++ not
> the general definition of pure virtuals as you see it.
Pure functions are rarely virtual. Anyone with minimal knowledge of
computer science knows what a pure function is.
> >that you know it all when it is apparent that you do not.
> Spare me your feeble attempts at being patronising, they're falling flat.
> I suggest you get your own clue.
I don't need to be patronizing. You seem clueless, and you do it all
for yourself. I genuinely was suggesting that you need to widen your
experience in order to help deal with that.
| boltar@cylonHQ.com: Jun 28 03:34PM
On Thu, 28 Jun 2018 16:25:23 +0100
>> the general definition of pure virtuals as you see it.
>Pure functions are rarely virtual. Anyone with minimal knowledge of
>computer science knows what a pure function is.
We're not talking about the mathematical definition of pure, we're talking
about the c++ definition of pure virtuals which mean something else entirely.
Either you're being pedantic for the sake of it or you're just another
aspie unable to follow normal discussion.
>I don't need to be patronizing. You seem clueless, and you do it all
>for yourself. I genuinely was suggesting that you need to widen your
>experience in order to help deal with that.
Do carry on, I'll get the popcorn! Your attempts at this are highly amusing :)
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jun 28 04:58PM +0100
On Thu, 28 Jun 2018 15:34:15 +0000 (UTC)
> about the c++ definition of pure virtuals which mean something else entirely.
> Either you're being pedantic for the sake of it or you're just another
> aspie unable to follow normal discussion.
If I were, that would be a totally inappropriate remark to make. Ad
hominem remarks of that kind would just be an indication that you have
lost the argument. So you seem not only to be lacking understanding
about C++, but to be unpleasant and lacking understanding about C++.
Anyway, you carry on with your fixation with pure virtual functions.
Better informed people would want to reserve any 'pure' keyword to
denote pure functions.
| legalize+jeeves@mail.xmission.com (Richard): Jun 28 04:15PM
[Please do not mail me a copy of your followup]
Sam <sam@email-scan.com> spake the secret code
>With the increased complexity of C++, only an actual C++ compiler can fully
>understand C++ code. This is not the only part of modern C++ that doxygen
>doesn't quite pick up.
Use DoxyPress instead; it uses clang to parse.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
|
|
