Saturday, June 30, 2018

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

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
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)