Saturday, December 17, 2022

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

Muttley@dastardlyhq.com: Dec 17 10:18AM

On Fri, 16 Dec 2022 14:03:18 -0600
 
>Those single digit mpg days are way past for F-150s. My 2019 F-150 4x4
>3.5L dual turbo V6 with the 4 inch lift kit gets 16 - 17 mpg around
>town, 20 mpg at 70 mph, and 18 mpg at 80 mph (it is a brick after all).
 
20mpg in 2022? BFD. My 14 year old tired diesel can do 35mpg at that speed
(admittedly UK gallons so probably ~ 30-32 US). Modern cars can do much better.
 
Though I suppose it begs the question of why americans feel the need to drive
around in absurdly large utility vehicles. Insecurity perhaps or maybe posing.
But thats an argument for another newsgroup.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 02:27AM -0800


> Though I suppose it begs the question of why americans feel the need to drive
> around in absurdly large utility vehicles. Insecurity perhaps or maybe posing.
> But thats an argument for another newsgroup.
 
Ever had to tow a big boat before?
Muttley@dastardlyhq.com: Dec 17 10:42AM

On Sat, 17 Dec 2022 02:27:30 -0800
>posing.
>> But thats an argument for another newsgroup.
 
>Ever had to tow a big boat before?
 
Tow your megayacht every day do you? Ever heard of hire vehicles?
scott@slp53.sl.home (Scott Lurndal): Dec 17 04:05PM

>> around in absurdly large utility vehicles. Insecurity perhaps or maybe posing.
>> But thats an argument for another newsgroup.
 
>Ever had to tow a big boat before?
 
Something that perhaps 15% of non-commercial pickup truck owners actually do.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 01:15PM -0800

On 12/17/2022 8:05 AM, Scott Lurndal wrote:
>>> But thats an argument for another newsgroup.
 
>> Ever had to tow a big boat before?
 
> Something that perhaps 15% of non-commercial pickup truck owners actually do.
 
Towing a boat up and down to Lake Tahoe from Carson City, one needs a
vehicle than can do it.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 01:15PM -0800

>>> But thats an argument for another newsgroup.
 
>> Ever had to tow a big boat before?
 
> Tow your megayacht every day do you? Ever heard of hire vehicles?
 
megayacht? No. Fishing in Lake Tahoe is fun.
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 09:49PM

On Wed, 2022-12-14, Michael S wrote:
...
> may be, for above 5% of programming tasks. But in the post above I wrote
> specifically *modern* C++. My opinion about *modern* C++ and programming
> practices that accompany it is not particularly favorable.
 
What does "modern C++" mean to you?
 
There was a time, up until C++98 became established, when everyone
wrote their own container libraries, used Smalltalk-style inheritance
as much as possible, chased memory leaks and didn't get much actual
work done. To me "modern C++" is anything after that.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 16 09:41PM -0800

On 12/14/2022 11:53 PM, David Brown wrote:
 
> Yes, people do that kind of thing in C.  I've even seen things like :
 
> #define UL(id) (user_library_ ## id)
 
> and then "UL(foo)(123);" instead of "user_library_foo(123);"
 
Oh god. I have seen macro tricks before, chaos lib... Wiping sweat off
of brow... Have you seen that heap of genius? Wow. I have posted some
crazy macro shit on this group, or was it comp.lang.c... Have to do a
search. Sorry.
 
> language and stick mostly to the C-subset of C++, is that you have
> hierarchical naming that follows the structure of your code - you can
> have "using" locally in a function, unlike preprocessor hacks like these.
 
ct::vector_field
 
vs
 
ct_vector_field
 
I love C, but C++ namespaces are very great! Love them.
David Brown <david.brown@hesbynett.no>: Dec 17 03:34PM +0100

On 17/12/2022 06:41, Chris M. Thomasson wrote:
 
> vs
 
> ct_vector_field
 
> I love C, but C++ namespaces are very great! Love them.
 
And if the original namespace is actually "Chris_M_Thomasson_lib", you
can write:
 
namespace ct = Chris_M_Thomasson_lib;
 
and then :
 
ct::vector_field
 
rather than :
 
Chris_M_Thomasson_lib::vector_field
 
If you are going to be using "vector_field" a lot and you think it is
neater to have a local abbreviation, you can write :
 
using vf = ct::vector_field; // A type
 
or
 
constexpr auto vf = ct::vector_field; // A function
 
These abbreviations are much better than using pre-processor macros,
because the they are structured and specific. (It would be nicer,
perhaps, if there were a single way to handle different kinds of things,
instead of separate syntaxes for namespaces, functions and types.)
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 04:53PM

On Fri, 2022-12-09, Juha Nieminen wrote:
> the distinctively-named versions in your code unless there's an actual
> good reason to use the overloaded versions. Readability is more important
> than convenience.
 
There seems to be at least as many opinions on style as there are C++
programmers. Your first post in the thread could have been written by
me (except thankfully people around me haven't read too much Herb
Sutter, and don't overuse auto).
 
But for function names my taste is the opposite. The parameter list
is part of the function signature, and I take that into account when
choosing a name. I also like short names without redundant
information. So there's a lot of "find", "size", "empty" and so on.
If I have problems coming up with a name like that, the first thing I
do is check if I should review my set of types.
 
To me this isn't a maintenance problem: it's obvious at the call site
which one I mean. If it's not, then I haven't understood the calling
code well enough to have a reason to follow the call.
 
Tags lookup in Emacs doesn't like overloading, though[0]. And
yesterday learned that, surprisingly, my coworkers' fancy IDEs
don't like it either. Unfortunate ... but it's not enough to make me
reconsider.
 
/Jorgen
 
[0] Or maybe I haven't learned how to use it properly.
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 17 09:01PM

On Wed, 2022-12-14, Juha Nieminen wrote:
> lines of "tpl = l.p;" which says nothing. What's with this obsession
> with brevity? It makes code needlessly inscrutable and cryptic for
> absolutely no benefit.
 
To me, I think "test_point_right" and "tpr" would be equally useful
or useless, without knowledge about what a "test point" is and what
left/right means, in this context.
 
My main gripe about other people's code these days is that: how I can
read class after class, with no documentation of the /intent/ of the
code, or the metaphors, assumptions or the large-scale design. Just a
sentence or two -- that's all I ask for.
 
Sometimes when reading it feels like someone spent a lot of talent and
time designing a fairly good mechanical lock, and then threw away the
key.
 
...
> change what I am seeing. You are not going to make this code more readable
> no matter how many times you repeat that the cryptic acronyms are
> actually the ones that are more readable.
 
People's brains must simply be wired differently. I prefer short names
(I already like "tpr" and memorized its meaning) and yet I /do/ care
deeply about maintainability.
 
Perhaps they should test programmers, place them in one of a number of
different categories, and then never mix them in teams. But employers
wouldn't like it ... they have trouble enough getting /anyone/.
 
And perhaps mixing people who are quite similar would cause even /more/
problems.
 
And perhaps I would end up alone in my category[1], and find myself
unemployed.
 
/Jorgen
 
[1] Perhaps it's called [MPP]: maths/punk/poetry.
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 01:27PM -0800

On 12/17/2022 6:34 AM, David Brown wrote:
> because the they are structured and specific.  (It would be nicer,
> perhaps, if there were a single way to handle different kinds of things,
> instead of separate syntaxes for namespaces, functions and types.)
 
Agreed! These are some of the reasons why I love C++ namespaces.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 17 01:32PM -0800

On 12/17/2022 6:34 AM, David Brown wrote:
> because the they are structured and specific.  (It would be nicer,
> perhaps, if there were a single way to handle different kinds of things,
> instead of separate syntaxes for namespaces, functions and types.)
 
Iirc, I have some old posts that use namespace aliases.
 
namespace ct_exp = ct::experimental::ver_0_0_0_1
Mr Flibble <flibble@reddwarf.jmc.corp>: Dec 17 08:47PM

We need to accelerate investment in new nuclear build and green hydrogen
technologies to counter climate change. Greenpeace are wrong to dismiss
nuclear on the account of radioactive waste: radioactive waste already
exists and creating more of it doesn't make the problem significantly
worse or have any bearing on solving that problem. Just my two cents.
#climatecrisis #ClimateEmergency
Andrey Tarasevich <andreytarasevich@hotmail.com>: Dec 17 10:55AM -0800

On 12/14/2022 12:44 AM, Frederick Virchanza Gotham wrote:
> Is the behaviour undefined because of my use of 'forward' on Line #22?
 
No. Why would it be? The behavior of `std::forward<>` is well-specified.
Regardless of how and where you use it, it will simply behave in
accordance with its specification.
 
> Should 'forward' only be used with a so-called 'template parameter forwarding reference'?
 
Yes, it probably should. That's what it's for.
 
--
Best regards,
Andrey
Vernand Rormond <veromond55@gmail.com>: Dec 17 04:22AM -0800

This is the PDF eBook version for The Quinolones 3rd Edition by Vincent T. Andriole
(Download link for cheap price) https://booksca.ca/library/pdf-the-quinolones-3rd-edition-by-vincent-t-andriole/
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)