Monday, August 24, 2020

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

"Öö Tiib" <ootiib@hot.ee>: Aug 23 10:52PM -0700

On Monday, 24 August 2020 02:06:07 UTC+3, Mike Copeland wrote:
> iss >> skipws; // skip leading whitespace
> iss.str(wstr);
> string str = iss.str(); // leading whitespace NOT stripped
 
That skipws skips whitespace for following >> operators, not for
str().
<http://coliru.stacked-crooked.com/a/1c13e8a37c21fe11>
Vir Campestris <vir.campestris@invalid.invalid>: Aug 24 09:55PM +0100

On 24/08/2020 00:05, Mike Copeland wrote:
> My intent is to strip the leading whitespace from each text line.
> The code below doesn't work. Please advise. TIA
 
If all you want to do is slip the leading whitespace it would probably
be more efficient to scan for the first non-space character in your read
line, then output the rest of the line. Less in-memory copying.
 
Andy
boltar@nowhere.co.uk: Aug 24 08:36AM

On Sat, 22 Aug 2020 22:49:01 -0300
>(EOS, https://eos.io/ https://github.com/EOSIO) is built entirely in
>C++17... the blockchain nodes are coded in native C++. Each node runs a
>WASM virtual machine that executes smart contracts also coded in C++.
 
So what exactly is this "node", hardware or software and why does it run web
assembly inside a VM? Thats just ridiculous. Blockchain calculations are
highly complex and need the fastest speed possible - ie a proper optimised
binary. This sounds like some mickey mouse toy setup.
 
>And, BTW, there are a lot of good applications running inside a browser,
>even an operating system like Linux.
 
At about 1/100 the speed of a native program.
Bonita Montero <Bonita.Montero@gmail.com>: Aug 24 11:27AM +0200

> Sure, but in bloated code the "hot" spots are luke warm, ...
 
Source ?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 24 02:59AM -0700

On 8/21/2020 7:37 AM, Juha Nieminen wrote:
> (in this case) is about 16 kB, that's quite a huge chunk.
 
> Does std::regex really need to be that big? Is there really no way
> for them to optimize it to be smaller and faster to compile?
 
A tight personal parser can be a good thing. No Baggage.
Juha Nieminen <nospam@thanks.invalid>: Aug 24 10:47AM

>>And, BTW, there are a lot of good applications running inside a browser,
>>even an operating system like Linux.
 
> At about 1/100 the speed of a native program.
 
You seem to sill be living in the 90's. For quite a long time now most
browsers JIT-compile Javascript, making it approach native program
speeds. (It might not be exactly as fast as a highly-optimized
compiled C++ program, mainly due to the limitations of Javascript
itself, but it's not that far off either.)
 
In fact, Javascript can be *so* low-level bare-metal and
accurate-to-the-clock-cycle that the Spectre and Meltdown exploits,
which require an accurate clock cycle count between two instructions,
could be exploited in Javascript (which was the main reason why
those exploits were so extraordinarily and unusually serious, as you
could get exploited by simply visiting a web page, without the exploit
even having to rely on any sort of browser bug or security hole.)
 
And of course WebGL is javascript-based, and can run hardware-accelerated
3D games at almost native speed. Just make a search for such games and be
amazed at how fast they run inside the browser.
 
Your "at about 1/100 the speed of a native program" would need some serious
proof.
Juha Nieminen <nospam@thanks.invalid>: Aug 24 10:49AM

> A tight personal parser can be a good thing. No Baggage.
 
Writing a parser for even relatively simple input formats using C++98
(without any third-party libraries) can be quite laborious, time-consuming
and error-prone. Depending on the particular input format and how complex
the parsing needs to be, it can be even more laborious to make the parsing
even moderately efficient.
 
I know. I have experience.
boltartoyou@nuttyella.co.uk: Aug 24 11:05AM

On Mon, 24 Aug 2020 10:47:02 +0000 (UTC)
>speeds. (It might not be exactly as fast as a highly-optimized
>compiled C++ program, mainly due to the limitations of Javascript
>itself, but it's not that far off either.)
 
Next you'll be telling me node.js is a superb server side system because of
its speed and efficiency. Note I have worked somewhere that used it - it isn't.
 
>In fact, Javascript can be *so* low-level bare-metal and
>accurate-to-the-clock-cycle that the Spectre and Meltdown exploits,
 
Any flaw in javscript is simply a flaw in the API presented to it via the
C++ code the browser is written in.
 
>those exploits were so extraordinarily and unusually serious, as you
>could get exploited by simply visiting a web page, without the exploit
>even having to rely on any sort of browser bug or security hole.)
 
The fact that the javascript API allows this shows the unnecessary low
level activity shows the massive feature creep browsers have incurred.
 
>And of course WebGL is javascript-based, and can run hardware-accelerated
>3D games at almost native speed. Just make a search for such games and be
>amazed at how fast they run inside the browser.
 
I've played plenty of those games. Amazed isn't a word that occured to me
tbh when seeing some basic texture mapped 3D shapes being manipulated on a
3Ghz multi core machine and dedicated GPU.
Cholo Lennon <chololennon@hotmail.com>: Aug 24 12:35PM -0300

> assembly inside a VM? Thats just ridiculous. Blockchain calculations are
> highly complex and need the fastest speed possible - ie a proper optimised
> binary. This sounds like some mickey mouse toy setup.
 
Ridiculous? Micky mouse toy setup? C'mon, just read about it before
emitting an opinion, you look like a troll. EOS is the fastest
blockchain *in the world* (why? because of the protocol used, because of
C++ and because of its high performant WASM VM - 6/12x over other
implementations)
 
https://www.blocktivity.info/
 
EOS produces and validates blocks every 500 ms, in contrast, Ethereuem
does the same every 15 seconds, and Bitcoin every 10 minutes! (Yes, when
you pay something using bitcoins, you have to wait on average 10 minutes
for the transaction confirmation).
The VISA payment system manages almost 2000 transactions per seconds,
EOS is able to reach 5000 TPS now (it has an average of 3000). In
contrast Ethereum and Bitcoint (which are not prepared for real time
transactions) manage 15 TPS and 7 TPS respectively. Ethereum is
re-thinking its architecture to solve this problem and Bitcoin has a
"patch", the "Lightning network" (a kind of parallel network of
"unverified" transactions).
 
EOS implements the Delegated Proof of Stake protocol (*) where a group
of selected nodes (21) are the only ones allowed to produce blocks.
Those 21 are voted by users and other producers. All smart contracts (in
all blockchains) run inside a virtual machine. Why? Because smart
contracts are "restricted/constrained" code, you can't do whatever you
want in a smart contract. In the case of EOS, the blockchain controls de
CPU, memory and security of the smart contract. Blocks are produced at
native level by a producer node, but the transactions are validated at
WASM level by a smart contract written by users (there are also system
smart contracts but those are part of the blockchain core). EOS is like
a distributed operating system. Actually the user smart contracts are
known as "dApps" (distributed apps).
 
EOS is not a toy, it's a serious platform.
 
(*) Do not confuse with Proof of Work protocol (used by Ethereum and
Bitcoin among others) which requires a lot of CPU/energy (and, in order
to be productive, a specialized hardware) to solve a crypto problem in
order to validate a block)
 
--
Cholo Lennon
Bs.As.
ARG
boltar@nuttyella.co.uk: Aug 24 04:12PM

On Mon, 24 Aug 2020 12:35:44 -0300
>blockchain *in the world* (why? because of the protocol used, because of
>C++ and because of its high performant WASM VM - 6/12x over other
>implementations)
 
TL;DR
 
Software that requires speed doesn't use web assembly. Its speed is no doubt
despite them using it, not because of it. They've obviously just written some
highly efficient algorithms.
 
Not that I care about bitcoin in the slightest, its just another form of
financial speculation for the gullible and a currency for criminals.
Cholo Lennon <chololennon@hotmail.com>: Aug 24 01:20PM -0300

> highly efficient algorithms.
 
> Not that I care about bitcoin in the slightest, its just another form of
> financial speculation for the gullible and a currency for criminals.
 
Troll detected
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 24 12:09PM -0700

On 8/24/2020 3:47 AM, Juha Nieminen wrote:
> amazed at how fast they run inside the browser.
 
> Your "at about 1/100 the speed of a native program" would need some serious
> proof.
 
Love WebGL. Here is some of my work:
 
http://funwithfractals.atspace.cc/ct_gfield_test/3d_user/ct_wormhole_exp.html
Vir Campestris <vir.campestris@invalid.invalid>: Aug 24 09:53PM +0100

On 22/08/2020 09:42, Bonita Montero wrote:
>> down the program because it fills the code cache with irrelevant stuff!
 
> That's actually not relevant because i-caches are large enough to hold
> the hot-spots.
 
Well the guys at Microsoft told me that they compile with optimisation
for size. Because "A page fault can ruin your day".
 
I've got 32Gb on my dev machine, and 16 on this thing. If the code is
bigger I'll have less free to use as disc cache. Given that our compiled
code base is 144G I'm not going to fit it all into RAM any time soon.
 
Andy
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 24 09:02PM +0100

On Sat, 22 Aug 2020 16:56:50 -0400
 
> operator TT& () { return u.ui64; };
> operator const TT& () const { return u.ui64; };
> };
 
This has been discussed many times before. For the information of the
OP, type punning with a union as in the lo() and hi() methods above has
undefined behaviour in C++, although it is supported by gcc and clang.
You can only legally access the currently active member of the union in
C++ (it is different in C).
 
Using reinterpret_cast is far worse (if that is what the OP has
been trying to do) because that is not supported by either gcc or clang
without the no-strict-aliasing flag. A standard conforming approach is
to use std::memcpy, which is also as efficient as a union in practice
because it is a compiler built-in.
Vir Campestris <vir.campestris@invalid.invalid>: Aug 24 09:48PM +0100

On 22/08/2020 21:56, James Kuyper wrote:
 
> operator TT& () { return u.ui64; };
> operator const TT& () const { return u.ui64; };
> };
 
James, I admit I don't expect to find one anytime soon - but if your
compiler chooses to align uint32_t on 64-bit boundaries that's not going
to behave - specifically the copy constructor.
 
Or is there some corner of the spec I don't know that prohibits that?
 
Andy
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 23 09:02PM -0700

On 8/21/2020 10:48 PM, Mr Flibble wrote:
>>> https://www.youtube.com/watch?v=eIpcqNcoK60&feature=youtu.be
 
>> Nice work! :^)
 
> Thanks. I've updated the video: new URL: https://youtu.be/GBdnFjDQ8tg
 
In the last video did I see some easing functions wrt buttons moving?
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Aug 24 06:33PM +0100

On 24/08/2020 05:02, Chris M. Thomasson wrote:
 
>>> Nice work! :^)
 
>> Thanks. I've updated the video: new URL: https://youtu.be/GBdnFjDQ8tg
 
> In the last video did I see some easing functions wrt buttons moving?
 
Yes .. it is a test app. :)
 
/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," Byrne 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."
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Aug 24 12:06PM -0700

On 8/24/2020 10:33 AM, Mr Flibble wrote:
 
>>> Thanks. I've updated the video: new URL: https://youtu.be/GBdnFjDQ8tg
 
>> In the last video did I see some easing functions wrt buttons moving?
 
> Yes .. it is a test app. :)
 
Looks great. Btw, I need to code up a little library of easing functions
for some of my experiments. Here is one that would interesting to tweak:
 
https://youtu.be/hlHmOKvQVT4
 
Space spider? ;^)
"daniel...@gmail.com" <danielaparker@gmail.com>: Aug 23 06:19PM -0700

On Sunday, August 23, 2020 at 6:01:46 AM UTC-4, Tim Rentsch wrote:
> for a language to allow such conversions non-explicitly in some
> situations, but there is no question that such conversions (as
> C++ defines the respective value transformations) are type safe.
 
Wikipedia defines "type safety" as "the extent to which a programming
language discourages or prevents type errors". I think it would be
hard to argue that treating a bool as an integral type, with built-in
implicit conversions to numeric types, in any way discourages type
errors.
 
Daniel
Ben Bacarisse <ben.usenet@bsb.me.uk>: Aug 24 05:10PM +0100

>> C++ defines the respective value transformations) are type safe.
 
> Wikipedia defines "type safety" as "the extent to which a programming
> language discourages or prevents type errors".
 
The trouble is that is almost circular. Of course safety in a
programming language refers to preventing errors, so type safety is
about prevent type errors, but that does not say much about what a type
error really is.
 
There are some obvious ones. In BCPL one could write
 
x := 42;
x!10 := 0
 
(which is x = 42; x[10] = 42; in C and C++). That's likely to be a
serious error in anything but some very specialised code. But other
cases are less clear. Given
 
double d; int i;
 
both d = i and i = d are assignments with miss-matched types. Are they
both unsafe? Equally unsafe?
 
> hard to argue that treating a bool as an integral type, with built-in
> implicit conversions to numeric types, in any way discourages type
> errors.
 
I would be prepared to have go! Could you argue that this it /is/ a
type error? Conversion between arithmetic types are very common. Are
they all detrimental to type safety?
 
--
Ben.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 24 08:07PM +0200

On 24.08.2020 18:10, Ben Bacarisse wrote:
 
> I would be prepared to have go! Could you argue that this it /is/ a
> type error? Conversion between arithmetic types are very common. Are
> they all detrimental to type safety?
 
It's probably a good idea to use a bool wrapper type for function
results, and in general,
 
and equally true, it's probably impossible to convince more than maybe
one or two programmers in the world to do that, because C and C++
programmers are as a whole extremely conservative.
 
A wrapper can go like this:
 
template< class T >
static constexpr bool is_bool_ = std::is_same_v<T, bool>;
 
template< class Truth_class >
struct Truth_values_
{
static const Truth_class yes;
static const Truth_class no;
};
 
class Truth:
public Truth_values_<Truth>
{
bool m_value;
 
public:
/// \brief Implicit conversion to `bool` (only).
///
/// Implicit conversion to `bool` because that's needed for
template args.
/// Restricted via SFINAE because overload resolution, want
predictability.
template<
class Result,
class = Enable_if_<is_bool_<Result>>
 
constexpr operator Result() const noexcept { return m_value; }
 
/// \brief Construction from `bool` (only).
///
/// Construction SFINAE-restricted to `bool` argument.
template<
class Arg,
class = Enable_if_<is_bool_<Arg>>
 
constexpr Truth( const Arg value ) noexcept: m_value( value ) {}
};
 
template< class Truth_class >
const Truth_class Truth_values_<Truth_class>::yes = true;
 
template< class Truth_class >
const Truth_class Truth_values_<Truth_class>::no = false;
 
constexpr inline auto is_true( const Truth value )
-> Truth
{ return value; }
 
constexpr inline auto is_false( const Truth value )
-> Truth
{ return not value; }
 
constexpr inline auto operator+( const Truth value )
-> int
{ return 0 + !!value; }
 
constexpr inline auto operator!=( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs != !!rhs; }
 
constexpr inline auto operator<=( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs <= !!rhs; }
 
constexpr inline auto operator<( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs < !!rhs; }
 
constexpr inline auto operator==( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs == !!rhs; }
 
constexpr inline auto operator>=( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs >= !!rhs; }
 
constexpr inline auto operator>( const Truth lhs, const Truth rhs )
-> bool
{ return !!lhs > !!rhs; }
 
<url:
https://github.com/alf-p-steinbach/cppx-core-language/blob/master/source/cppx-core-language/types/Truth.hpp>
 
---
 
There is a question here also:
 
is there a possibly better way to declare the `Truth::yes` and
`Truth::no` constants?
 
The above "templated constant" trick feels Just Wrong™, but it was
evidently the best I could come up with at the time when I wrote that.
 
- Alf
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 24 02:09PM -0400

On 8/24/20 12:10 PM, Ben Bacarisse wrote:
> "daniel...@gmail.com" <danielaparker@gmail.com> writes:
...
 
> double d; int i;
 
> both d = i and i = d are assignments with miss-matched types. Are they
> both unsafe? Equally unsafe?
 
The integers are a subset of the real numbers, d = i is likely to put
into d a floating-point representation of exactly the same integer value
that was represented by i. If DBL_EPSILON*INT_MAX < 0, it's guaranteed
to do so.
i = d can overflow. However, if it doesn't, i will end up representing a
value that differs by no more than 1.0 from the value represented by d.
 
When you convert between boolean and arithmetic values, it's not even
meaningful to ask whether the result represents the same value as the
original - there's no overlap between the set {true, false} and the
integers..
 
 
> I would be prepared to have go! Could you argue that this it /is/ a
> type error? Conversion between arithmetic types are very common. Are
> they all detrimental to type safety?
 
The thing is, bool is an arithmetic type only by fiat. Conceptually,
true is no more of an arithmetic value than 'A' is, but C++ calls them
both arithmetic. A more type-safe version of C++ would require the use
of constructs such as
 
arithmetic_value != 0
 
and
 
boolean_value ? 1 : 0
 
to do the equivalent of C++'s implicit conversions.
Juha Nieminen <nospam@thanks.invalid>: Aug 24 06:22AM

> that's fine, but saying there are no requirements (or even
> "pretty much" no requirements) is at the very least open to
> debate.
 
What are the requirement that the standard imposes onto the layout of
bitfields inside a struct/class?
 
I freely admit that I have not read the standard in this regard, but it's
my understanding that there are no requirements about how many bits are
actually allocated for each bitfield, or the order in which consecutive
bitfields are stored in the struct. It probably doesn't even mandate that
the bits in one bitfield must be in consecutive bytes.
 
For example, suppose you have something like:
 
struct S
{
unsigned short a:3, b:11, c:2
};
 
While those bits take 16 bits in total, and thus would fit in 2 bytes,
as far as I know, there's no requirement that the compiler does so.
For all that the standard is concerned, a compiler could just as well
pack those values as:
 
00000aaa bbbbbbbb 00000bbb 000000cc
 
Another compiler might back them as:
 
000000cc 00000bbb bbbbbbbb 00000aaa
 
A third compiler might decide to pack them as:
 
000ccaaa bbbbbbbb 00000bbb
James Kuyper <jameskuyper@alumni.caltech.edu>: Aug 24 09:54AM -0400

On 8/24/20 2:22 AM, Juha Nieminen wrote:
...
> What are the requirement that the standard imposes onto the layout of
> bitfields inside a struct/class?
 
 
"An implementation may allocate any addressable storage unit large
enough to hold a bit-field. If enough space remains, a bit-field that
immediately follows another bit-field in a structure shall be packed
into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or
overlaps adjacent units is implementation-defined. The order of
allocation of bit-fields within a unit (high-order to low-order or
low-order to high-order) is implementation-defined. The alignment of the
addressable storage unit is unspecified.
 
A bit-field declaration with no declarator, but only a colon and a
width, indicates an unnamed bit-field. 126) As a special case, a bit
field structure member with a width of 0 indicates that no further
bit-field is to be packed into the unit in which the previous bit-field,
if any, was placed." (6.7.2.1 p11-12).
 
That's not enough specification to be of much use, but it's (barely)
enough to refute the claim that the standard impose no requirements.
ram@zedat.fu-berlin.de (Stefan Ram): Aug 24 12:30AM

> My intent is to strip the leading whitespace from each text line.
>The code below doesn't work. Please advise. TIA
 
#include <iostream>
#include <ostream>
#include <sstream>
#include <string>
 
using namespace ::std::literals;
 
auto arbitrary_string_stream()
{ return ::std::istringstream{ " this is a test "s }; }
 
void skip_whitespace( ::std::istringstream & s )
{ s >> ::std::ws; }
 
auto rest_of_line_from( ::std::istringstream & s )
{ auto t = ::std::string{};
::std::getline( s, t );
return t; }
 
int main()
{ auto s = arbitrary_string_stream();
skip_whitespace( s );
::std::cout << rest_of_line_from( s )<< '\n'; }
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)