Sunday, November 6, 2022

Digest for comp.lang.c++@googlegroups.com - 9 updates in 5 topics

Opus <ifonly@youknew.org>: Nov 06 08:53PM +0100

Le 04/11/2022 à 06:06, Lynn McGuire a écrit :
> I forgot to add I would prefer a portable way if possible.  I suspect
> that is not possible though below the second resolution.
 
You're asking specifically on Windows, and then you now want a portable
solution. There isn't. But you could write your own compatibility layer,
calling either Windows API functions or POSIX functions. This isn't
rocket science. I've done that long ago and keep reusing it. There may
of course be many third-party code/libraries doing just that if you
don't want to do it yourself.
 
IME, using performance counters on Windows is the only sure way of
getting proper resolution. Any third-party code will use them in one way
or another. Why not do that yourself, it'll be only a few lines of code
to write a compatibility layer.
Michael S <already5chosen@yahoo.com>: Nov 06 02:30PM -0800

On Sunday, November 6, 2022 at 9:54:11 PM UTC+2, Opus wrote:
> getting proper resolution. Any third-party code will use them in one way
> or another. Why not do that yourself, it'll be only a few lines of code
> to write a compatibility layer.
 
Why do it it yourself?
I don't find it very likely that compatibility layer consisting of few lines
of code written by non-specialist will do a better job than compatibility
layer provided by standard C++ library, in particular one in
std::chrono::stable_clock.
Michael S <already5chosen@yahoo.com>: Nov 06 02:41PM -0800

On Saturday, November 5, 2022 at 12:35:30 AM UTC+2, Lynn McGuire wrote:
> The problem is multiple instances of the same program creating the same
> name files.
 
> Lynn
 
If you decided to keep ideas of your old code* then using __rdtsc() is hand
down better than anything else. Of course, don't convert result of
__rdtsc() to microseconds, use the number in its entirety. This way you still
would not get 100% guarantee against name conflicts between multiple
instances, but probability of conflict will be 3-6 orders of magnitude lower
than any other time-based method.
------------
* - IMHO, you should not. Posters here suggested at least two better solutions
and can suggest more. BTW, are you sure that with modern memory
capacity you still need temporary files at all?
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 06 11:55AM -0800

On 11/3/2022 12:30 PM, Lynn McGuire wrote:
> jobs even at my age of 62.
 
> Hat tip to:
>   https://www.codeproject.com/script/Mailouts/View.aspx?mlid=16845
 
Fwiw, I am good at C. I know C++, but do not yet totally understand some
of its more "modern" features, so to speak. I know enough C++ to code up
synchronization algorithms ala atomic and membars, but feel more at
_home_, in C.
James Kuyper <jameskuyper@alumni.caltech.edu>: Nov 06 03:25AM -0500

On 11/4/22 09:47, Scott Lurndal wrote:
> Juha Nieminen <nospam@thanks.invalid> writes:
..
>> static_cast is because it's longer. That's it. No other reason.
 
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.
 
It's advantage over the plain c-style cast lies in what it won't do: it
won't do any of the things for which const_cast<> or reinterpret_cast<>
are needed instead. It also won't do what dynamic_cast<> does, but
that's also true of the c-style cast.
Particularly in a language that allows overloading and template type
parameters, the consequences of a c-style cast can be hard to
anticipate. The named casts help ensure that only the desired type of
change can occur without triggering a mandatory diagnostic.
 
 
> Some of us learned by punching programs on cards and on 110 baud
> teletypes on computers
> with 4k words of memory. Brevity was to be celebrated.
 
In 1974 my high school provided computer programming classes, when
almost no one else did, because an alumnus donated a long-obsolete IBM
1620 with a Fortran I compiler, using punched cards and a teletype. It
being a decimal machine, I seem to recall it had 10000 decimal digits of
memory.
 
While I learned touch typing at an early age, I was always prone to
errors. On punched cards, that meant a lot of wasted cards. Cards that
were correctly punched were a precious resource for me. I took to using
some really bad policies when writing my programs. I used very short
generic variable names, allowing me to re-use them for very different
purposes in different programs. If I typed a variable name incorrectly
on my first try, that incorrect spelling became the new correct spelling
for the variable. I gave statements widely spaced statement numbers,
allowing me to insert new statements between them.
 
I dropped all of these absurd policies like hot potatoes the instant I
started working on a computer which allowed me to save and edit programs.
Paavo Helde <eesnimi@osa.pri.ee>: Nov 06 05:34PM +0200

04.11.2022 15:47 Scott Lurndal kirjutas:
>> static_cast is because it's longer. That's it. No other reason.
 
> Actually, I don't like it because it doesn't add anything useful over
> a plain c-style cast.
 
But it does. If I get e.g. constness wrong in my casting, a C-style cast
won't bat an eye whereas static_cast will complain loudly. Ditto for
many other mistakes which I might make. If you never make any mistakes
when typing code, then it does not matter, but for me it does.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 06:19AM +0100

Am 06.11.2022 um 00:03 schrieb Öö Tiib:
 
> The resize has never been required to have default construction loop
> in it; resize is required to have loop of copy initialization.
 
https://en.cppreference.com/w/cpp/container/vector/resize
 
"additional default-inserted elements are appended".
 
> I perfectly understand that you wish that there is default construction
> loop in vector resize, just that it is not so in our reality.
 
You're a idiot.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 06 10:34AM +0100

I've written a little program to demonstrate the advantage of my ndi_t
union:
 
#include <iostream>
#include <vector>
#include <chrono>
#include <cmath>
#include <sstream>
#include "ndi_t.h"
 
using namespace std;
using namespace chrono;
 
int main()
{
auto bench = []<typename T, typename Touch>( T t, Touch touch ) -> double
requires requires( Touch touch, vector<T> &vt ) { { touch( vt ) }; }
{
constexpr size_t N = (size_t)1 << 30;
vector<T> vt;
auto start = high_resolution_clock::now();
vt.resize( N );
touch( vt );
return (double)duration_cast<nanoseconds>(high_resolution_clock::now()
- start).count() / 1.0e6;
};
auto ndiTouch = []( vector<ndi_t<char>> &ndiVec )
{
for( size_t i = 0; i < ndiVec.size(); ndiVec[i] = 0, i += 0x1000 );
};
double
tChar = bench( char(), []( vector<char> const & ) {} ),
tNdi = bench( ndi_t<char>(), []( vector<ndi_t<char>> const & ) {} ),
tNdiTouch = bench( ndi_t<char>(), ndiTouch );
cout << "char: " << tChar << "ms" << endl;
cout << "ndi_t<char>: " << tNdi << "ms" << endl;
cout << "ndi_t<char> (touch): " << tNdiTouch << "ms" << endl;
}
 
It benchmarks the time to resize a char-vector to one GB. My ndi_t
union is about 30.000 times faster on my Linux computer. This is
while such large allocations aren't pooled by your memory allocator
but directly fetched from the kernel in multiples of pages. If this
pages aren't touched they remain unassigned to actual physical memory.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 05 07:04PM -0500

On 11/5/2022 3:29 PM, Michael S wrote:
> You can use non-direct equivalents like like std::for_each(),
> but if you value your sanity, please do not.
> Just write explicit for() loop.
 
That is what I do now.
 
Thanks,
Lynn
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)