Saturday, November 5, 2022

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

"Öö Tiib" <ootiib@hot.ee>: Nov 05 06:24AM -0700

On Friday, 4 November 2022 at 21:12:23 UTC+2, Bonita Montero wrote:
> when you have an operating system that overcommits the appended
> memory pages aren't even assigned to physical pages until you
> write-touch them.
 
Plain wrong third time. That is not what resize is required to do. If you
omit the value parameter then it is required to default construct it and
then copy construct the result. Can be billions of times if you resized
to billions of elements.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 05 03:51PM +0100

Am 05.11.2022 um 14:24 schrieb Öö Tiib:
 
> Plain wrong third time. That is not what resize is required to do.
 
That depends on what you want. If you want the appended elements not to
be default-initialized because you overwrite the element yourself later
or you don't initialize it at all because you want partitially complete
pages which arent assigned to phyisical memory (unter Linux these pages
arent even reseved from swap with overcommitting) my ndi_t union is the
right thing.
The class only works if the encapsulated type has a trivial destructor
which is restricted by a concept to prevent to do the wrong things with
my union.
"Öö Tiib" <ootiib@hot.ee>: Nov 05 09:44AM -0700

On Saturday, 5 November 2022 at 16:51:35 UTC+2, Bonita Montero wrote:
> Am 05.11.2022 um 14:24 schrieb Öö Tiib:
 
> > Plain wrong third time. That is not what resize is required to do.
 
> That depends on what you want.
 
Nope. If a function is not required by standard to call your mutilated
default constructor then it does not start to call it (and optimize away)
because you want. Your wishes are irrelevant.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 05 06:11PM +0100

Am 05.11.2022 um 17:44 schrieb Öö Tiib:
 
 
> Nope. If a function is not required by standard to call your mutilated
> default constructor then it does not start to call it (and optimize away)
> because you want. Your wishes are irrelevant.
 
Of course the default-construction loop on the appended elements
is optimized away, that's what my ndi_t<>-union is for; this saves
CPU time.
You simply don't understand the purpose.
"Öö Tiib" <ootiib@hot.ee>: Nov 05 04:03PM -0700

On Saturday, 5 November 2022 at 19:11:47 UTC+2, Bonita Montero wrote:
 
> Of course the default-construction loop on the appended elements
> is optimized away, that's what my ndi_t<>-union is for; this saves
> CPU time.
 
The resize has never been required to have default construction loop
in it; resize is required to have loop of copy initialization.
 
> You simply don't understand the purpose.
 
I perfectly understand that you wish that there is default construction
loop in vector resize, just that it is not so in our reality.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 05 02:12PM -0500

On 11/3/2022 4:25 PM, Chris M. Thomasson wrote:
 
> Heck, add current experience. Like a log in a resume. Include a link in
> the "short" version to a longer version that records your journey in the
> porting process.
 
I haven't touched my resume since 1989. It is fairly out of date.
 
Lynn
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 05 02:20PM -0700

On 11/5/2022 12:12 PM, Lynn McGuire wrote:
>> in the "short" version to a longer version that records your journey
>> in the porting process.
 
> I haven't touched my resume since 1989.  It is fairly out of date.
 
Shit happens. Well, go ahead and update the file. :^)
Vir Campestris <vir.campestris@invalid.invalid>: Nov 05 09:42PM

On 03/11/2022 19:30, Lynn McGuire wrote:
> jobs even at my age of 62.
 
> Hat tip to:
>   https://www.codeproject.com/script/Mailouts/View.aspx?mlid=16845
 
It got one drier. I quit in April (UK tax year). I wasn't earning 500k,
but I reckon I have enough put away for the rest of my life.
 
It's a balance between running out of money, and running out of health :(
 
There was an article in today's paper about the growing number of people
becoming economically inactive. Including early retirees. The tax system
over here doesn't help much mind - it's discouraging when the government
gets more of your earnings when you do.
 
And anyway ... why am I still reading this newsgroup? <g>
 
Andy
Vir Campestris <vir.campestris@invalid.invalid>: Nov 05 09:34PM

On 04/11/2022 13:47, Scott Lurndal wrote:
>> 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.
 
I don't like it because it's longer. But sometimes it is better. You
know exactly what it will do.
 
>> programmers never learn out of this bad habit.
 
> 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.
 
You had a card punch? You didn't have to shade in the fields with a 6B
pencil? Luxury...
 
I too learned back in the bad old days. These days I can touch type on a
nice light keyboard I can use for hours. Not like the ASR33 keyboard
that really needed two fingers to press the keys.
 
The world is in some ways a better place.
 
Andy
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 05 03:16PM -0500

In converting my F77 code to C++, I am wondering how to do implied do
loops on write statements in C / C++ ?
 
write (oufile, 54555) (xyz (i), i = 1, ncp)
54555 format ('xyz=', (1x, g14.7), /)
 
Thanks,
Lynn
Michael S <already5chosen@yahoo.com>: Nov 05 01:29PM -0700

On Saturday, November 5, 2022 at 10:17:05 PM UTC+2, Lynn McGuire wrote:
> 54555 format ('xyz=', (1x, g14.7), /)
 
> Thanks,
> Lynn
 
There is no direct equivalent in C++ .
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.
Bonita Montero <Bonita.Montero@gmail.com>: Nov 05 09:35PM +0100

Am 05.11.2022 um 21:29 schrieb Michael S:
 
> 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.
 
I use for_each sometimes when it's shorter.
Michael S <already5chosen@yahoo.com>: Nov 05 10:16AM -0700

On Friday, November 4, 2022 at 10:18:05 PM UTC+2, Lynn McGuire wrote:
 
> https://sdtimes.com/software-development/google-takes-on-c-technical-debt-with-new-successor-language-carbon/
 
> Good night, these people are prolific.
 
> Lynn
 
Already discussed here:
https://groups.google.com/g/comp.lang.c++/c/Hr7q-C1c4gI
It's not the first time you're doing it.
Lynn McGuire <lynnmcguire5@gmail.com>: Nov 05 02:01PM -0500

On 11/5/2022 12:16 PM, Michael S wrote:
 
> Already discussed here:
> https://groups.google.com/g/comp.lang.c++/c/Hr7q-C1c4gI
> It's not the first time you're doing it.
 
Sorry, I did not remember that.
 
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)