Wednesday, July 31, 2019

Digest for comp.lang.c++@googlegroups.com - 23 updates in 3 topics

Bonita Montero <Bonita.Montero@gmail.com>: Jul 31 10:14AM +0200

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 01:25AM -0700

On 7/31/2019 1:14 AM, Bonita Montero wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
 
The One True Representation!
"Öö Tiib" <ootiib@hot.ee>: Jul 31 03:48AM -0700

On Wednesday, 31 July 2019 11:14:17 UTC+3, Bonita Montero wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
 
This feels like two major proposals. One is that all signed integers
should be two's complement and other is that signed integer overflow
should wrap.
 
Majority will be happy (or at least content) with both but about
second there will be likely a bit of opposition and controversy.
 
Most of such opposition will boil down to claim that signed
arithmetic should not overflow anyway in sane code and therefore
some optimizations where compiler did assume that it does not
overflow will be lost without any gain.
 
I agree that that signed arithmetic should not overflow
in good code but it seems hard to find (or to teach) programmers
who write good code in that respect. So there are often bugs with
it and so I would often prefer crash (or have SIGFPE raised)
instead of wrapping.
James Kuyper <jameskuyper@alumni.caltech.edu>: Jul 31 07:58AM -0400

On 7/31/19 4:25 AM, Chris M. Thomasson wrote:
> On 7/31/2019 1:14 AM, Bonita Montero wrote:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
 
> The One True Representation!
 
That document claims:
> It is extremely unlikely that there exist any significant code base> developed for two's complement machines that
> would actually work when run on a non-two's
> complement machine.
 
I consider that implausible, unless "developed for two's complement
machines" is defined as "developed with the deliberate intent of relying
on two's complement", in which case it becomes a trivial tautology.
 
Most of my code is intended to work regardless of how signs are
represented, and the discipline required to achieve that result is not
great: don't apply bit-wise operators (<< >> | & ~) to values of signed
types. Don't use type punning. Whenever doing calculations involving
signed integer types, make sure that the specific types chosen are big
enough to avoid overflow - and when a calculation cannot be guaranteed
to avoid overflow for all permitted values of its inputs, make sure the
calculation is not performed when the values are such that overflow
would occur.
 
I'm sure that there have to be at a least a few significant code bases
where such discipline has been followed - though I cannot identify any
specific ones.
Siri Cruise <chine.bleu@yahoo.com>: Jul 31 05:14AM -0700

In article <qhrvp4$i1c$1@dont-email.me>,
 
> I consider that implausible, unless "developed for two's complement
> machines" is defined as "developed with the deliberate intent of relying
> on two's complement", in which case it becomes a trivial tautology.
 
I programmed on CDC ones complement machines and CDC twos complement machines. I
never had a problem except -0.
 
> great: don't apply bit-wise operators (<< >> | & ~) to values of signed
> types. Don't use type punning. Whenever doing calculations involving
> signed integer types, make sure that the specific types chosen are big
 
It's difficult to run into differences. Even bit twiddling code on signed
numbers can work fairly transparently. -0 can be a problem, but only in
assembly. Compilers don't let you say -0 < +0.
 
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 31 02:59PM +0200

On 31.07.2019 10:25, Chris M. Thomasson wrote:
> On 7/31/2019 1:14 AM, Bonita Montero wrote:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
 
> The One True Representation!
 
As I recall from a novel I read, One True is a mean-spirited artifical
intelligence that takes over Earth and eventually Mars, with more or
less direct control over each individual human. It can convert any human
to an obedient slave by just saying a few words to the person. So it's
best not to create any opportunity where one might hear what it says.
 
Cheers!,
 
- Alf
David Brown <david.brown@hesbynett.no>: Jul 31 03:29PM +0200

On 31/07/2019 12:48, Öö Tiib wrote:
> should wrap.
 
> Majority will be happy (or at least content) with both but about
> second there will be likely a bit of opposition and controversy.
 
I doubt if anyone will mind about the first. Representation is
implementation specific, but since I think it is fair to say that any
system which will support modern C++ (or modern C) will have two's
complement representation, this is pretty much a no-brainer. It will
simplify several points in the standard and make some kinds of coding
simpler, while having no adverse effects that I can think of.
 
 
There will, I think, be quite a bit of opposition to the second. I am
certainly against it, for several reasons.
 
Some things that are currently implementation defined, such as the
conversion to signed types when the value is out of range, could
usefully and sensibly be defined as two's complement wrapping or modulo
arithmetic. That is what happens today in most (or all) compilers, and
would be a natural choice to stipulate in the standards along with the
representation.
 
> who write good code in that respect. So there are often bugs with
> it and so I would often prefer crash (or have SIGFPE raised)
> instead of wrapping.
 
I see a number of reasons why two's complement wrapping for signed
arithmetic is a bad idea.
 
1. It hinders optimisations. When you have division involved, you lose
several associative properties of integer arithmetic. And you lose all
sorts of basic identities that exist when you assume no overflow, such
as "x > y <=> (x + z) > (y + z)".
 
2. It makes alternative overflow behaviour wrong and non-conforming.
That means a compiler that has traps on overflows for safer coding or
during debugging, is suddenly no longer correct C++.
 
3. It gives broken and incorrect code a defined behaviour, making it
harder for compilers and static analysis tools to inform the programmer
and help find mistakes. Instead of being able to tell you that you've
overflowed your integer constant (or constexpr) calculations, you'd have
to put the compiler in non-conforming modes first.
 
4. Integer arithmetic that overflows is almost always in error - even if
the results are defined (by the language, compiler flags, etc.). If you
have a pile of 2147483647 apples and put another apple on the pile, a
result of -2147483648 is about the silliest answer you could possibly
give. Raising an error or saturating would be far more likely to be
correct.
 
5. It gives the impression that signed integer arithmetic is now "safe"
and can be carried out without as much care and attention as you had to
do when there were nasal demons lurking round the bend. This is, of
course, nonsense - it merely hides some classes of errors under the
carpet where they are harder to find.
 
 
So I am against defining the results of signed integer arithmetic
primarily for code safety and correctness reasons, and secondarily for
performance reasons.
Keith Thompson <kst-u@mib.org>: Jul 31 01:05PM -0700

> On Wednesday, 31 July 2019 11:14:17 UTC+3, Bonita Montero wrote:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html
 
The link is to:
p0907r0
Signed Integers are Two's Complement
Published Proposal, 9 February 2018
 
> who write good code in that respect. So there are often bugs with
> it and so I would often prefer crash (or have SIGFPE raised)
> instead of wrapping.
 
I have no particular objection to requiring two's complement for signed
integers. I don't think this proposal addresses padding bits or the
possibility that the most negative representation is a trap
representation, so would still be some rare variations to worry about.
 
Specifying wrapping behavior for signed integers could be a *big*
problem. In particular, this:
 
int n = INT_MAX + 1;
 
would probably not produce a warning. It's not required to do
so now, and compilers could produce warnings anyway, but making
INT_MAX + 1 well defined where it's currently almost certainly an
error would be confusing. More concretely, this:
 
constexpr int n = INT_MAX + 1;
 
is currently invalid and would become legal.
 
Requiring 2's-complement representation while leaving overflow
behavior alone would be a simpler and less controversial change.
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
"Öö Tiib" <ootiib@hot.ee>: Jul 31 02:22PM -0700

On Wednesday, 31 July 2019 16:30:21 UTC+3, David Brown wrote:
> > instead of wrapping.
 
> I see a number of reasons why two's complement wrapping for signed
> arithmetic is a bad idea.
 
I was almost certain that you are one who is against it considering
what you have written before.
 
> several associative properties of integer arithmetic. And you lose all
> sorts of basic identities that exist when you assume no overflow, such
> as "x > y <=> (x + z) > (y + z)".
 
That is true, (like I said), there are several optimizations that
assume that integer arithmetic does not overflow and it will be
tricky to indicate to compiler that it may do such optimizations
in conforming mode. But so ... solution is same as with your #2.
 
> 2. It makes alternative overflow behaviour wrong and non-conforming.
> That means a compiler that has traps on overflows for safer coding or
> during debugging, is suddenly no longer correct C++.
 
The compiler vendors have never cared that with certain options
their compiler is not conforming. Quite popular is to let to turn
off exceptions, to turn off RTTI and so on. I do not think that turning
off wrapping signed integers will be different in any way.
 
> and help find mistakes. Instead of being able to tell you that you've
> overflowed your integer constant (or constexpr) calculations, you'd have
> to put the compiler in non-conforming modes first.
 
Please elaborate. There are piles of warnings that a well-formed
program with fully well-defined behavior will receive with -Wall
and most warnings in -Wextra are such plus there are more warnings
I like that neither of those settings turns on. No non-conforming
modes are needed. So why should warning about potentially wrapping
integer suddenly cause different situation?
 
> result of -2147483648 is about the silliest answer you could possibly
> give. Raising an error or saturating would be far more likely to be
> correct.
 
That option I would also love like I said above.
 
> do when there were nasal demons lurking round the bend. This is, of
> course, nonsense - it merely hides some classes of errors under the
> carpet where they are harder to find.
 
It is frequently same with unsigned integers. On lot of cases when
these overflow then it is defect.
 
> So I am against defining the results of signed integer arithmetic
> primarily for code safety and correctness reasons, and secondarily for
> performance reasons.
 
But you put performance reason as #1 in above list. ;)
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 31 10:35PM

On Wed, 2019-07-31, James Kuyper wrote:
 
> I consider that implausible, unless "developed for two's complement
> machines" is defined as "developed with the deliberate intent of relying
> on two's complement", in which case it becomes a trivial tautology.
 
Yes. A really weird thing to write, now that you point it out.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Öö Tiib" <ootiib@hot.ee>: Jul 31 03:48PM -0700

On Wednesday, 31 July 2019 23:05:52 UTC+3, Keith Thompson wrote:
> error would be confusing. More concretely, this:
 
> constexpr int n = INT_MAX + 1;
 
> is currently invalid and would become legal.
 
I feel confused, either I misunderstand the point you are making
or have misread standard.
Right now (as with C++17) the std::numeric_limits<int>::is_modulo
has implementation-defined constexpr value. Yes?
That value can depend on compiler options if it is true
or false. Yes?
My reading of standard is that when it is true then INT_MAX + 1
is not undefined behavior. Do I misread?
Are you saying that it should be undefined behavior?
I read that the proposal was to make it true always and that I'm
also unsure if it is good idea.
Daniel <danielaparker@gmail.com>: Jul 31 07:10AM -0700

The cppreference documentation doesn't identify any exceptions.
 
https://en.cppreference.com/w/cpp/container/map/contains
 
Thanks,
Daniel
Bo Persson <bo@bo-persson.se>: Jul 31 06:12PM +0200

On 2019-07-31 at 16:10, Daniel wrote:
 
> https://en.cppreference.com/w/cpp/container/map/contains
 
> Thanks,
> Daniel
 
The function itself is perhaps unlikely to throw any exceptions, but any
comparisons would use the Compare template parameter which is not
limited to noexcept operations.
 
 
Bo Persson
"Öö Tiib" <ootiib@hot.ee>: Jul 31 02:55PM -0700

On Wednesday, 31 July 2019 17:10:24 UTC+3, Daniel wrote:
> The cppreference documentation doesn't identify any exceptions.
 
> https://en.cppreference.com/w/cpp/container/map/contains
 
Hmm? Be constructive. How you suggest to define it then?
Let me try ...
 
bool contains( const Key& key ) const
noexcept(noexcept(key_comp()(key, key)));
 
That? Does that work?
 
Note that contains() is C++2020 map feature and C++2020 standard does
not exist yet. I don't even understand why to add it since it does
exactly same thing that std::map::count() already does. However
if it is possible to add such noexcept specifications then these
should perhaps be added to *lot* of other functions as well.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 30 11:08PM -0700

On 7/30/2019 7:32 AM, Fred Killet wrote:
> price. However, WINDOWS programmers have the advantage to integrate
> geodetic functions as a DLL. That is already possible from 500 euros.
> Fred
 
shared object files on Linux should work fine.
Paavo Helde <myfirstname@osa.pri.ee>: Jul 31 10:36AM +0300

On 31.07.2019 9:08, Chris M. Thomasson wrote:
>> geodetic functions as a DLL. That is already possible from 500 euros.
>> Fred
 
> shared object files on Linux should work fine.
 
It takes some knowledge and experience to prepare a binary C++ .so which
would work on most Linuxes, especially if it is using a lot of
third-party libraries. The default model in Linux is to use the
system-installed C++ runtimes, but there have been ABI-breaking changes
in those runtimes, so one just cannot compile a .so on a random Linux
box and hope it will work everywhere. Third-party libraries with C++
interfaces will add many complications, one could either use
system-installed ones or package them together with your own .so, both
approaches have serious drawbacks.
 
In short, the easiest way to install custom software (not included in
package manager repos) in Linux is to build it directly on the target box.
"Öö Tiib" <ootiib@hot.ee>: Jul 31 12:36AM -0700

On Wednesday, 31 July 2019 09:08:19 UTC+3, Chris M. Thomasson wrote:
> > geodetic functions as a DLL. That is already possible from 500 euros.
> > Fred
 
> shared object files on Linux should work fine.
 
Who knows. Majority of Windows DLL-s have actually kind of language
agnostic service interface that provides remote process call objects
(COM). COM might simplify linking to C#, Visual basic
or Ms access but is not easily portable to other platforms.
Bonita Montero <Bonita.Montero@gmail.com>: Jul 31 10:15AM +0200

>> geodetic functions as a DLL. That is already possible from 500 euros.
>> Fred
 
> shared object files on Linux should work fine.
 
Maybe he estimates that there will be no customers with Linux?
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 01:18AM -0700

On 7/31/2019 12:36 AM, Paavo Helde wrote:
> approaches have serious drawbacks.
 
> In short, the easiest way to install custom software (not included in
> package manager repos) in Linux is to build it directly on the target box.
 
Humm... It would be wise to create the shared object API using C. The
guts can be C++, exceptions aside for a moment... but the API would be
all in C. A little C++ wrapping up the C shared API would work. Sound a
little better? Plugin interface.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 01:22AM -0700

On 7/31/2019 1:15 AM, Bonita Montero wrote:
>>> Fred
 
>> shared object files on Linux should work fine.
 
> Maybe he estimates that there will be no customers with Linux?
 
Perhaps. Afaict, he can do it with OpenGL for rendering, C for
interface, C++ for guts? Humm...
Paavo Helde <myfirstname@osa.pri.ee>: Jul 31 11:52AM +0300

On 31.07.2019 11:18, Chris M. Thomasson wrote:
> guts can be C++, exceptions aside for a moment... but the API would be
> all in C. A little C++ wrapping up the C shared API would work. Sound a
> little better? Plugin interface.
 
Yes, this is a good approach for some C++ libraries, but requires extra
work and may hinder performance. Another good approach is to create
header-only libraries, so there is no .so to link to.
"Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Jul 31 02:14AM -0700

On 7/31/2019 1:52 AM, Paavo Helde wrote:
 
> Yes, this is a good approach for some C++ libraries, but requires extra
> work and may hinder performance. Another good approach is to create
> header-only libraries, so there is no .so to link to.
 
Agreed. Sometimes, its hard to beat a pure header based lib. I am quite
fond of GLM:
 
https://glm.g-truc.net/0.9.2/api/a00001.html
 
;^)
Manfred <noname@add.invalid>: Jul 31 02:44PM +0200

On 7/31/2019 9:36 AM, Paavo Helde wrote:
> approaches have serious drawbacks.
 
> In short, the easiest way to install custom software (not included in
> package manager repos) in Linux is to build it directly on the target box.
 
There is always the possibility for the vendor to provide binary
packages for major distros.
For the vendor this is considerably harder than delivering sources,
nonetheless the process can be fairly automated, at the advantage of not
having to disclose the source code - which in this case appears to be
worth an order of magnitude difference in price.
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.

Fwd: 2018-2029年月历

   





Subject: 2018-2029年月历

Tuesday, July 30, 2019

Digest for comp.lang.c++@googlegroups.com - 15 updates in 3 topics

Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 30 07:22AM -0700


> Therefore some kind of right-to-left sequencing is part
> of the semantics the assignment already always had, in
> any language.
 
This summary sentence is utter nonsense.
Keith Thompson <kst-u@mib.org>: Jul 30 01:08PM -0700

>> of the semantics the assignment already always had, in
>> any language.
 
> This summary sentence is utter nonsense.
 
What does the phrase "This summary sentence" refer to?
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
killet@killetsoft.de: Jul 30 01:18AM -0700

Hi,
 
who develops programs with geodetic functionality like coordinate transformations, datum shifts or distance calculations, can use geodetic functions from my Geodetic Development Tool GeoDLL. The Dynamic Link Library can easily be used with most of the modern programming languages like C, C++, C#, Basic, Delphi, Pascal, Java, Fortran, xSharp, MS-Office and others to add geodetic functionality to own applications. For many programming languages ​Interfaces and Examples are available.
 
GeoDLL is a Geodetic Development Tool or a Geodetic Function Library for worldwide 2D and 3D Coordinate Transformations and Datum Shifts with highest accuracy and for calculating Meridian Convergence and many Extra Parameters. Furthermore: Helmert and Molodensky Parameters, NTv2, HARN, INSPIRE, EPSG, Digital Elevation Model (DEM), distance and Time Zone calculations and much more. GeoDLL is available as 32Bit and 64Bit DLL and as C / C++ source code.
 
The DLL is very fast, save and compact thanks to the consistent development in C / C++ with Microsoft Visual Studio. The geodetic functions are available in 32bit and 64bit architecture. All functions are prepared for multithreading and server operating.
 
You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm
Notes about the NTv2 support can be found here: https://www.killetsoft.de/p_gdln_e.htm
Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm
 
Fred
Email: info_at_killetsoft.de
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 30 12:44PM +0200


> You find a free downloadable test version on https://www.killetsoft.de/p_gdla_e.htm
> Notes about the NTv2 support can be found here: https://www.killetsoft.de/p_gdln_e.htm
> Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm
 
Sounds nice but I don't understand why a geodetic library needs to be
Windows-specific?
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jul 30 05:42AM -0700

On Tuesday, 30 July 2019 13:45:11 UTC+3, Alf P. Steinbach wrote:
> > Report on the quality of the coordinate transformations: https://www.killetsoft.de/t_1705_e.htm
 
> Sounds nice but I don't understand why a geodetic library needs to be
> Windows-specific?
 
It was likely just spam and poster does not read replies. Cursory
eyeballing the site finds indications that perhaps they just hope
you buy the codes and do porting yourself:
 
"GDLLSOURCE GeoDLL complete C++ source code of all groups EUR 4000.00"
by https://www.killetsoft.de/p_prei_e.htm#geodll
 
"The source is extensively written in ANSI-C++, so that the migration to arbitrary operating systems and hardware platforms is possible with minor modifications."
by https://www.killetsoft.de/p_gdla_e.htm
Fred Killet <info_nospam_@killetsoft.de>: Jul 30 04:32PM +0200

Yes, 20000 lines of source code with geodetic functions have their
price. However, WINDOWS programmers have the advantage to integrate
geodetic functions as a DLL. That is already possible from 500 euros.
Fred
Jorgen Grahn <grahn+nntp@snipabacken.se>: Jul 30 06:11PM

On Tue, 2019-07-30, Öö Tiib wrote:
> On Tuesday, 30 July 2019 13:45:11 UTC+3, Alf P. Steinbach wrote:
...
 
> It was likely just spam and poster does not read replies. Cursory
> eyeballing the site finds indications that perhaps they just hope
> you buy the codes and do porting yourself:
 
I have a feeling there's a good ecosystem around libproj, QGis and so
on for Free Software-oriented people ... although my experience is
limited to conversions between coordinate systems, using libproj.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Sam <sam@email-scan.com>: Jul 29 08:51PM -0400

Bonita Montero writes:
 
> tion returns a pointer to the next state function. I.e I would
> write: "while( (fn = state->*fn()) != nullptr );". I see no way
> to define the type of fn since it is recursive.
 
Correct, but you can get pretty close, something like this:
Sam <sam@email-scan.com>: Jul 29 08:52PM -0400

Bonita Montero writes:
 
> tion returns a pointer to the next state function. I.e I would
> write: "while( (fn = state->*fn()) != nullptr );". I see no way
> to define the type of fn since it is recursive.
 
Correct, but you can get pretty close, something like this:
 
#include <iostream>
 
class state_machine {
 
public:
 
struct next_state_ret;
 
typedef next_state_ret (state_machine::*next_state)();
 
struct next_state_ret {
 
next_state_ret (state_machine::*stateptr)()=nullptr;
 
operator bool() const
{
return stateptr != nullptr;
}
};
 
inline next_state_ret transition(next_state_ret current_state)
{
return (this->*(current_state.stateptr))();
}
 
static next_state_ret initial_state()
{
return {&state_machine::initial};
}
 
next_state_ret initial()
{
std::cout << "Initial state" << std::endl;
return { &state_machine::state1 };
}
 
next_state_ret state1()
{
std::cout << "State 1" << std::endl;
return { &state_machine::state2 };
}
 
next_state_ret state2()
{
std::cout << "State 2" << std::endl;
return { nullptr };
}
};
 
int main()
{
state_machine sm;
 
auto state=sm.initial_state();
 
while (state)
{
state=sm.transition(state);
}
return 0;
}
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 30 01:58PM +0100

On Mon, 29 Jul 2019 13:49:47 +0200
> tion returns a pointer to the next state function. I.e I would
> write: "while( (fn = state->*fn()) != nullptr );". I see no way
> to define the type of fn since it is recursive.
 
Are you after some kind of lazy list (aka streams)? If so I have
stream/node classes with macros and supporting functions (including
stream_take()/stream_for_each() functions which are analogous to your
while block), which I can post: if so do you want the stream also to
memoize or just act lazily?
 
But you may be after something else.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 30 07:31AM -0700

> std::cout << "B: " << param << '\n';
> return DoSomethingA;
> }
 
Did you not understand the question? Your "solution"
doesn't do anything like what he is asking for.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 30 08:03AM -0700

> a more dynamic language like Python, but have to be rewritten with
> some indirection for a language with strong static type checking
> like C++.
 
The problem here is not strong static type checking but the lack
of recursive types in C++. A language can have recursive types
and also have strong static type checking.
 
> the textual simplicity of the source code. Since it doesn't give
> that textual simplicity in C++, it's not a good way in C++. It's
> doable, just not in any practical way.
 
That depends on what is meant by "practical". It can be done
like this:
 
#include <iostream>
 
class State {
using Nexter = ...;
 
public:
State(){}
Nexter r0(){ return &State::r1; }
Nexter r1(){ return &State::r2; }
Nexter r2(){ return &State::rn; }
Nexter rn(){ return 0; }
};
 
void
run_state_machine(){
State *s = new State;
 
for( auto f = &State::r0; f; f = (s->*f)() ){
::std::cout << "Got one\n";
}
}
 
with a fairly short (five-ish lines) elaboration for the "...".
Personally I think this approach offers a fairly nice textual
simplicity, and is eminently practical.
 
If someone thinks five lines of overhead is too much, the "..."
can be made into a template, giving
 
using Nexter = WrapMemberFunctionPointer< State >;
 
which provides an even nicer source text.
"Rick C. Hodgin" <rick.c.hodgin@gmail.com>: Jul 30 11:20AM -0400

On 7/30/2019 11:03 AM, Tim Rentsch wrote:
> ::std::cout << "Got one\n";
> }
> }
 
 
A better solution might be a state machine that can iterate N
times setup at instantiation, and then optionally reset when
exhausted so it can be re-entered the second time (untested,
but generally speaking this concept should work):
 
 
#include <iostream>
 
class State
{
using Nexter = ...;
 
public:
State(int nStateCount)
{
nState_ = -1;
nStateMax_ = max(1, nStateCount);
}
 
Nexter next(bool lReset = false)
{
if (++nState < nStateMax)
return &this->next; // Return self
 
// When we get here, we're done with this state traversal
if (lReset)
nState = -1; // Prepare for the next one
 
// Indicate this state is exhausted
return null;
}
 
void reset(int nState = -1)
{
nState_ = max(-1, min(nState, nStateMax));
}
 
int state(void) { return nState_; }
int max(void) { return nStateMax_; }
 
private:
int nState_;
int nStateMax_;
};
 
void run_state_machine()
{
State* s = new State(4);
...
 
--
Rick C. Hodgin
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 30 06:00PM +0200

On 30.07.2019 17:03, Tim Rentsch wrote:
>> that textual simplicity in C++, it's not a good way in C++. It's
>> doable, just not in any practical way.
 
> That depends on what is meant by "practical".
 
Short and clear source code and reasonably good efficiency.
 
 
> ::std::cout << "Got one\n";
> }
> }
 
Yes, that's mainly the basic technique I had in mind: an extra level of
indirection, the solution to every computer science problem.
 
Nit-picks: (1) a State instance doesn't actually hold state, yet the
member functions are not `static`, and (2) there's a needless dynamic
allocation and memory leak.
 
Fixing those issue, it can go like this (in practice one would have some
input argument to each function, so it can decide which state to go to):
 
 
class State
{
struct Nexter
{
using Func = auto() -> Nexter;
Func* m_p_func;
 
operator Func* () const { return m_p_func; }
Nexter( Func* const f ): m_p_func( f ) {}
};
 
State() = delete;
 
public:
static auto r0() -> Nexter { return &State::r1; }
static auto r1() -> Nexter { return &State::r2; }
static auto r2() -> Nexter { return &State::rn; }
static auto rn() -> Nexter { return nullptr; }
};
 
#include <iostream>
using namespace std;
 
auto main() -> int
{
for( auto f = &State::r0; f; f = f() ) {
cout << "State " << reinterpret_cast<void const*>( f ) <<
"." << endl;
}
}
 
Here the reinterpret_cast is only conditionally supported by the
standard (since C++11, in order to support Posix), so it's not 100%
portable. I guess that on a Harvard architecture it won't compile. But
then one would have more labor-intensive problems to deal with...
 
 
> with a fairly short (five-ish lines) elaboration for the "...".
 
Not sure what you're thinking of there?
 
 
> can be made into a template, giving
 
> using Nexter = WrapMemberFunctionPointer< State >;
 
> which provides an even nicer source text.
 
Well, to my mind the indirection adds complexity so that even though the
code is short it's not IMO /clear/, and for debugging it's not so clear
which state one is in, just by looking at a function address.
 
But, subjective opinion. ;-)
 
 
Cheers!,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Jul 30 09:22AM -0700

On Tuesday, 30 July 2019 17:32:11 UTC+3, Tim Rentsch wrote:
> > are you trying to achieve.
 
> Did you not understand the question? Your "solution"
> doesn't do anything like what he is asking for.
 
Yes, I tried to express that doubt. Can't you read?
Your habit to answer in useless manner starts to feel
strange. Additionally ... I suspect that Bonita is she.
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.

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

avanzini.mattia@gmail.com: Jul 29 04:28PM -0700

How i can see the script of a .exe file? i have the permissions to see it but idk how to do that
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.programming.threads+unsubscribe@googlegroups.com.

Monday, July 29, 2019

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

ram@zedat.fu-berlin.de (Stefan Ram): Jul 29 04:10PM

>I think she is inspired by (possibly someone else who is inspired by) an
>article by the Go language creator.
 
One context where one would like to return a variant with
either a pointer to the active function or a sentinel value
is a trampoline (which can be used to user-implement TCO in
languages without it).
ram@zedat.fu-berlin.de (Stefan Ram): Jul 29 08:13PM

Supersedes: <trampoline-20190729170836@ram.dialup.fu-berlin.de>
[PS]
 
>I think she is inspired by (possibly someone else who is inspired by) an
>article by the Go language creator.
 
One context where one would like to return a variant with
either a pointer to the active function or a sentinel value
is a trampoline (which can be used to user-implement TCO in
languages without it).
 
PS: The above is not entirely correct. Actually, one wants
to return a newly created function for trampolining. Sorry!
Juha Nieminen <nospam@thanks.invalid>: Jul 29 02:25PM

> Surely it would have been better to not introduce a new keyword, and
> rather add another meaning for static. ;-)
 
Well, they used 'class' for strong enums, so "typedef class"?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 29 06:00PM +0200

On 29.07.2019 16:25, Juha Nieminen wrote:
>> Surely it would have been better to not introduce a new keyword, and
>> rather add another meaning for static. ;-)
 
> Well, they used 'class' for strong enums, so "typedef class"?
 
Sounds nice but that syntax already has a meaning.
 
On the third hand, `auto` also already had a meaning.
 
 
Cheers!,
 
- Alf
Bonita Montero <Bonita.Montero@gmail.com>: Jul 29 01:49PM +0200

I need a class-function / method that returns a function-pointer
to the same type of class-function. How do I implement this? I
need this to have a kind of state-machine where each state-func-
tion returns a pointer to the next state function. I.e I would
write: "while( (fn = state->*fn()) != nullptr );". I see no way
to define the type of fn since it is recursive.
"Öö Tiib" <ootiib@hot.ee>: Jul 29 06:30AM -0700

On Monday, 29 July 2019 14:49:58 UTC+3, Bonita Montero wrote:
> tion returns a pointer to the next state function. I.e I would
> write: "while( (fn = state->*fn()) != nullptr );". I see no way
> to define the type of fn since it is recursive.
 
Perhaps there are no way to make a function that return function
pointer of its own type. However I do not understand the need
of it. There is state and there is its handler and if you
really need conversions between state and handler then you may
make conversion constructors/operators ... but in my humble
opinion it feels a bit messy and confusing. Here is example:
 
#include <iostream>
 
// state
class State
{
public:
using Handler = State (*)(int);

State(Handler h)
:handler_(h)
{ }

operator Handler() {return handler_;}

private:
Handler handler_;
};

// example handlers
State DoSomethingA(int param);

State DoSomethingB(int param);

// example of usage
int main()
{
State::Handler s(DoSomethingA(0));
s = s(1);
s = s(2);
s = s(3);
s = s(4);
}

// implementations of handlers
State DoSomethingA(int param)
{
std::cout << "A: " << param << '\n';
return DoSomethingB;
}

State DoSomethingB(int param)
{
std::cout << "B: " << param << '\n';
return DoSomethingA;
}
 
If it does miss what you asked for then post actual
example code what are your handlers and what usage
are you trying to achieve.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 29 05:59PM +0200

On 29.07.2019 15:30, Öö Tiib wrote:
 
> Perhaps there are no way to make a function that return function
> pointer of its own type. However I do not understand the need
> of it.
 
I think she is inspired by (possibly someone else who is inspired by) an
article by the Go language creator.
 
As I recall his examples work nicely in Go, or assembly language, or a
more dynamic language like Python, but have to be rewritten with some
indirection for a language with strong static type checking like C++.
 
The reason for doing it that way, in languages where it's simple, is the
textual simplicity of the source code. Since it doesn't give that
textual simplicity in C++, it's not a good way in C++. It's doable, just
not in any practical way.
 
 
Cheers!,
 
- Alf
guinness.tony@gmail.com: Jul 29 01:16AM -0700


> But i need to understand if loads with older stores to the same location have total order in relaxed memory model of ARM CPU ?
 
> And i need to know if stores to the same location have total order in relaxed memory model of ARM CPU ?
 
> And i need to understand if stores with older loads to the same location have total order in relaxed memory model of ARM CPU ?
 
RTFM.
 
And stop spamming comp.programming.threads
Juha Nieminen <nospam@thanks.invalid>: Jul 29 02:26PM


>> And i need to understand if stores with older loads to the same location have total order in relaxed memory model of ARM CPU ?
 
> RTFM.
 
> And stop spamming comp.programming.threads
 
I would not classify asking on-topic questions as "spamming".
Bonita Montero <Bonita.Montero@gmail.com>: Jul 29 04:32PM +0200

>> And stop spamming comp.programming.threads
 
> I would not classify asking on-topic questions as "spamming".
 
Posting a lot of redundant stuff which no one would read because
there s nothing new in it is spamming. And there is a substantial
part of his postings which is not related to threading.
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.

Sunday, July 28, 2019

Digest for comp.lang.c++@googlegroups.com - 1 update in 1 topic

aminer68@gmail.com: Jul 28 10:35AM -0700

Hello,
 
 
Question about ARM relaxed memory model..
 
I was just reading the following webpage about memory ordering:
 
https://en.wikipedia.org/wiki/Memory_ordering
 
 
But i need to understand if loads with older stores to the same location have total order in relaxed memory model of ARM CPU ?
 
And i need to know if stores to the same location have total order in relaxed memory model of ARM CPU ?
 
And i need to understand if stores with older loads to the same location have total order in relaxed memory model of ARM CPU ?
 
Thank you,
Amine Moulay Ramdane.
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.

Saturday, July 27, 2019

Hi Remember Me ?????

Driver took this picture when I was walking with a walker.
Recent visit to my Primary Physician I told him I feel weak in my legs and
he ordered me do more regular walking and proscribed me Physical Therapy.
Staying home is really comfortable and I become lazy and lazier, did not
know that my osteoporosis is getting worse. I don't feel anything wrong,
what's what scares me. Several times a week, 40-50 minutes with a couple
of breaks, walking in the hospital where my doctor is is really a good
choice in this weather. Air conditioned, with drinking water and clean
lady's rooms and resting areas. And above all, my driver walks with me. No
complaint!!!

How are you all ????? It is hard not to remember you . . . .
. . Hope to receive some pictures from you, together or whatever, the more
the better.

Enough for now, good night !!!!



P.S. I must have missed some old friends or if your email address changed.
Wish to hear from you soon.

Digest for comp.lang.c++@googlegroups.com - 2 updates in 1 topic

Manfred <noname@add.invalid>: Jul 27 06:23PM +0200

On 7/26/2019 10:34 PM, Thiago Adams wrote:
 
> HRESULT F() { ... return FALSE; }
> The value 0 means OK (S_OK) in HRESULT
> This code compiles without error or warning.
 
And S_FALSE is 1 :)
 
But VARIANT_TRUE is -1, and VARIANT_FALSE is 0 :))
 
Expecting consistency is a lost cause in the MS world, so back to the
original point, stuff like strong-typedefs may be useful to enforce
consistency, but not in Windows programming.
David Brown <david.brown@hesbynett.no>: Jul 27 10:41PM +0200

On 26/07/2019 22:21, Bart wrote:
 
>> I think strong-typedefs are useful.  In windows HRESULT and BOOL can
>> be mixed causing errors, for instance.
 
> HRESULT is defined as 'long', an int, so not that much can go wrong.
 
Lots and lots can go wrong with a type like that being just a typedef
for an int or a long int.
 
> It's also intended to hold a result, which can be 'bool'.
 
> But it's also misnamed as it is not a handle, which generally are
> pointers; those can't be mixed up with bools.
 
Handles are sometimes implemented with pointers, sometimes with integer
indexes or other ways of storing data. The point of a handle type is it
should be different from pointers or anything else - it should be more
abstract, and with limited features. You should not be able to
dereference it like a pointer - you should be able to receive it from an
allocation function, pass it around to other API functions, and hand it
in to a deallocation function. Sensible handle types in C are always
strong types - a struct (or even a union) in C, a struct, class or
strong enum in C++.
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.

Digest for comp.programming.threads@googlegroups.com - 1 update in 1 topic

aminer68@gmail.com: Jul 26 07:27AM -0700

Hello,
 
 
"How to Simulate 1000 Cores
 
Our experiments show that the simulator can scale up to 1024 cores with an average simulation speed overhead of only 30% with respect to the single-core simulation."
 
Read more here:
 
https://www.hpl.hp.com/techreports/2008/HPL-2008-190.pdf
 
 
 
Thank you,
Amine Moulay Ramdane.
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.programming.threads+unsubscribe@googlegroups.com.

Friday, July 26, 2019

Digest for comp.lang.c++@googlegroups.com - 9 updates in 1 topic

Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 26 03:42PM +0100

By far and away the best C++20 feature is strong typedefs: we have been
waiting so long for this feature and it has finally arrived:
 
strong typedef int wibble_t;
 
void foo(int i) {}
void foo(wibble_t w) {} // this overload is called! \o/
 
wibble_t w = 42;
foo(w);
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
Thiago Adams <thiago.adams@gmail.com>: Jul 26 09:23AM -0700

On Friday, July 26, 2019 at 11:42:21 AM UTC-3, Mr Flibble wrote:
> By far and away the best C++20 feature is strong typedefs: we have been
> waiting so long for this feature and it has finally arrived:
 
> strong typedef int wibble_t;
 
Where did you hear about it?
Is this a joke?
Robert Wessel <robertwessel2@yahoo.com>: Jul 26 11:58AM -0500

On Fri, 26 Jul 2019 15:42:09 +0100, Mr Flibble
>void foo(wibble_t w) {} // this overload is called! \o/
 
>wibble_t w = 42;
>foo(w);
 
 
Surely it would have been better to not introduce a new keyword, and
rather add another meaning for static. ;-)
Bonita Montero <Bonita.Montero@gmail.com>: Jul 26 07:41PM +0200

Am 26.07.2019 um 16:42 schrieb Mr Flibble:
> By far and away the best C++20 feature is strong typedefs:
> we have been waiting so long for this feature and it has finally arrived:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
I think this is a very special feature and not many have waited
for this.
Keith Thompson <kst-u@mib.org>: Jul 26 11:19AM -0700


>> strong typedef int wibble_t;
 
> Where did you hear about it?
> Is this a joke?
 
It's not a joke, but only because jokes are funny.
 
There is no "strong typedef" feature in C++, and no such feature will be
in C++20.
 
Apparently Boost has something called BOOST_STRONG_TYPEDEF, which has
some limitations.
 
There have been proposals for strong typedefs. See, for example,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf
 
(If I've missed something, and such a feature is proposed for C++20,
please provide a citation.)
 
(Recall that typedef does not define a new type, just a new name for an
existing type.)
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
Thiago Adams <thiago.adams@gmail.com>: Jul 26 12:24PM -0700

On Friday, July 26, 2019 at 3:19:33 PM UTC-3, Keith Thompson wrote:
> please provide a citation.)
 
> (Recall that typedef does not define a new type, just a new name for an
> existing type.)
 
I didn't find any c++ proposal for this feature and then I thought
it was a joke.
 
I think strong-typedefs are useful. In windows HRESULT and BOOL can
be mixed causing errors, for instance.
 
Some static analysis have this feature implemented:
 
https://www.gimpel.com/html/strong.htm
Bart <bc@freeuk.com>: Jul 26 09:21PM +0100

On 26/07/2019 20:24, Thiago Adams wrote:
> it was a joke.
 
> I think strong-typedefs are useful. In windows HRESULT and BOOL can
> be mixed causing errors, for instance.
 
HRESULT is defined as 'long', an int, so not that much can go wrong.
It's also intended to hold a result, which can be 'bool'.
 
But it's also misnamed as it is not a handle, which generally are
pointers; those can't be mixed up with bools.
 
 
> Some static analysis have this feature implemented:
 
> https://www.gimpel.com/html/strong.htm
 
That helps explain why Pascal could be such a pain to write. When you
have a million little integer types, all different, and that must match
exactly as well being able to interact, then life is necessarily more
difficult.
 
It's never that bad in real life: we don't use a different kind of
number to index floors in a building, compared with pages in a book for
example, but how many times does that cause a problem? In code, we can
write:
 
int page_number, floor_number
 
to help out.
Thiago Adams <thiago.adams@gmail.com>: Jul 26 01:34PM -0700

On Friday, July 26, 2019 at 5:22:14 PM UTC-3, Bart wrote:
> > be mixed causing errors, for instance.
 
> HRESULT is defined as 'long', an int, so not that much can go wrong.
> It's also intended to hold a result, which can be 'bool'.
 
if I remember correctly the error is something like this:
 
HRESULT F() { ... return FALSE; }
The value 0 means OK (S_OK) in HRESULT
This code compiles without error or warning.
 
 
> write:
 
> int page_number, floor_number
 
> to help out.
 
If I had this feature I would not use for each type in the world.
I would not use for kilos or meters (unless maybe doing some
rocket code) because this increases the mental load to understand
the program. If you read 'int meters' you have two good information.
if you read 'Meters meters' you need to known exactly what is Meters.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 27 12:03AM +0100

On 26/07/2019 17:58, Robert Wessel wrote:
>> foo(w);
 
> Surely it would have been better to not introduce a new keyword, and
> rather add another meaning for static. ;-)
 
Great minds think alike: I was going to subsequently reply that my post
would have been more credible if I used "static" instead of "strong" due
to the dearth of contextual meanings for the "static" keyword. :D
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."
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.