Thursday, December 8, 2022

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

Lynn McGuire <lynnmcguire5@gmail.com>: Dec 08 01:45PM -0600

"C++ overtakes Java in language popularity index"

https://www.infoworld.com/article/3682141/c-plus-plus-overtakes-java-in-language-popularity-index.html
 
"C++ ranks higher than Java in the Tiobe language popularity index for
the first time ever, dating back to 2001. Java slipped to a new low in
the latest edition of the index."
 
"The December 2002 Tiobe Programming Community Index has C++, ranked
third, surpassing Java, ranked fourth. It is the first time in the
history of the index that Java has not ranked in the index's top three
languages."
 
C (16.56%) and C++ (11.94%) together are 28.5%.
 
Lynn
scott@slp53.sl.home (Scott Lurndal): Dec 08 08:12PM


>"C++ ranks higher than Java in the Tiobe language popularity index for
>the first time ever, dating back to 2001. Java slipped to a new low in
>the latest edition of the index."
 
That's because of the high-quality interactive java documentation
(javadocs); The "popularity index" is primarily derived from
search statistics - a java developer seldom needs to search for
something; javadocs are usually sufficient.
 
Most of these surveys aren't worth the electrons conveying them
to your screen anyway.
Jack Lemmon <invalid@invalid.net>: Dec 08 09:25PM

On 08/12/2022 20:12, Scott Lurndal wrote:
 
> Most of these surveys aren't worth the electrons conveying them
> to your screen anyway.
 
Hold on. You shouldn't be saying this here. These surveys helps Lynn
McGuire write something here to keep him busy. Let him enjoy posting
these craps.
 
The alternative is to read about UFO, Religion or somebody's Halt
nonsense.
Bo Persson <bo@bo-persson.se>: Dec 08 11:17PM +0100

On 2022-12-08 at 20:45, Lynn McGuire wrote:
> history of the index that Java has not ranked in the index's top three
> languages."
 
> C (16.56%) and C++ (11.94%) together are 28.5%.
 
Considering that Java is at 11.85%, I wouldn't consider this a landslide
victory and a historic moment.
 
I might do a search for "Java Java Java programming" and restore the
previous result. It's that close.
Muttley@dastardlyhq.com: Dec 08 09:48AM

eg:
 
template<typename... T>
auto sum(T&&... args)
{
if (typeid(T) == typeid(string)) { do something }
return (args + ...);
}
 
However doing typeid on T gives
 
error: expression contains unexpanded parameter pack 'T'
 
in clang.
 
Is there a way to get the type inside the function?
Juha Nieminen <nospam@thanks.invalid>: Dec 08 12:18PM


> error: expression contains unexpanded parameter pack 'T'
 
> in clang.
 
> Is there a way to get the type inside the function?
 
The problem is that T there is not a type, but a parameter pack.
You can't 'typeid(T)' when T is a parameter pack (what would that
even mean? A parameter pack is essentially a bunch of types).
 
If you want to iterate through all the types in that parameter
pack and do one thing or another depending on a particular type,
you'll need to do it in the more "traditional" C++11 way of
iterating parameter packs. In other words, something along the
lines of:
 
void doSomething(const std::string& s) { /* ... */ }
 
template<typename T>
void doSomething(const T&) {}
 
template<typename First>
auto sum(First&& first) { return first; }
 
template<typename First, typename... Rest>
auto sum(First&& first, Rest&&... rest)
{
doSomething(first);
return first + sum(std::forward<Rest>(rest)...);
}
"Öö Tiib" <ootiib@hot.ee>: Dec 08 04:45AM -0800


> error: expression contains unexpanded parameter pack 'T'
 
> in clang.
 
> Is there a way to get the type inside the function?
 
There are too lot of ways but I usually check the types in enable_if
as I've used to see that and all compilers can already process that.
If needed I make checking templates myself.
 
#include <iostream>
#include <string>
 
// make checking for char array type
template <class> struct is_bounded_char_array : std::false_type {};
template <size_t N> struct is_bounded_char_array<char[N]> : std::true_type {};
 
// if not std::string, char* and char array
template<typename T,
std::enable_if_t<
!std::is_same_v<std::string, T>
&& !std::is_same_v<char*, T>
&& !is_bounded_char_array<T>{}
, bool> = true>
// return whatever it is without processing
auto process_value(T const& v) {return v;}
 
// for things disabled above return result of string to double conversion
// or whatever your "do something" means
double process_value(std::string const& s) { return std::stod(s); }
 
// now your sum is simple to write
template<typename... T>
auto sum(T&&... args) {return (process_value(args) + ...); }
 
// and demo should output 10
int main()
{
char arr[] = "1";
char* ptr = arr;
std::cout << sum(ptr, 2, "3.0", std::string("4")) << "\n";
}
Muttley@dastardlyhq.com: Dec 08 03:41PM

On Thu, 8 Dec 2022 12:18:52 -0000 (UTC)
> doSomething(first);
> return first + sum(std::forward<Rest>(rest)...);
>}
 
Thats just variadic templates with a slightly different syntax. AFAIK the
point of folds is not having to manually iterate the arguments yourself as
with 2011 which is little better than C's varargs (and probably less efficient
due to recursion vs pointer incrementing).
Muttley@dastardlyhq.com: Dec 08 03:45PM

On Thu, 8 Dec 2022 04:45:54 -0800 (PST)
> , bool> = true>
>// return whatever it is without processing
>auto process_value(T const& v) {return v;}
 
Clearly you know more about the dustier corners of C++ than me. enable_if is
the only one of those tests I've heard of.
"Öö Tiib" <ootiib@hot.ee>: Dec 08 01:59PM -0800

> >auto process_value(T const& v) {return v;}
 
> Clearly you know more about the dustier corners of C++ than me. enable_if is
> the only one of those tests I've heard of.
 
Oh there are quite lot of those checks in C++ metaprogramming.
<https://en.cppreference.com/w/cpp/meta> is good reference of those.
I often do not remember what standard was one or other added but
some important things are still built with older compilers so then
I look from there.
 
It is good site but tricky to support them ... as I don't need
much geeky merchantise where their "support" link leads.:D
Juha Nieminen <nospam@thanks.invalid>: Dec 08 07:52AM

>> loops (or use any smart pointers for that matter)?
 
> It really rears its ugly head when iterating large linked lists of
> nodes... Read mostly, write rather rarely.
 
I don't see how iterating a linked list requires copying or assigning
smart pointers. Unless you are using the smart pointers as the next/prev
pointers of each node themselves. In which case you run into a recursive
reference counting situation, which I don't see how that's very feasible.
 
 
> Big time. Have you ever studied up on RCU? That is one of the reasons it
> was created in the first place: to get rid of memory barriers on the
> read side of the algorithm.
 
In scenarios that don't require the last clock cycles squeezed out of
them it's extremely important to squeeze the last clock cycles out?
 
I don't often like to quote the way-too-often-wrongly-quoted and
way-too-often-completely-misunderstood "early optimization is the
root of all evil", but in this case that it applies.
 
(In its original context, when Donald Knuth wrote that, he was saying
that your optimization efforts should be concentrated on the 3% of the
code where it actually matters. Something that most people don't know
about the quote. But it does apply here perfectly.)
Paavo Helde <eesnimi@osa.pri.ee>: Dec 08 01:38PM +0200

07.12.2022 22:48 Chris M. Thomasson kirjutas:
 
>> If code that takes 0.01% of the total runtime
>> gets 1% slower... how much will it slow down the overall program?
>> Do the math.
 
My aim is to allow the program to scale safely to many-core machines.
Even if some synchronization overhead is small today when running on 10
cores in parallel, it does not mean it will remain small when run on a
100-core or 1000-core machine, in some not so distant future.
 
> collection does pretty damn good, but not as good as RCU...
 
> The membars take a big toll, especially the god damn #StoreLoad barrier
> in SMR (aka, hazard pointers).
 
My current approach is to use single-threaded data structures as much as
possible, so that the running threads would not disturb each other at
all. But this creates other challenges like a need for deep copies, and
a need to recalculate same things in different threads, on those copies.
 
It looks like if I want to use another approach with keeping more data
in shared use I will indeed need to learn more about atomics and RCU.
Tim Rentsch <tr.17687@z991.linuxsc.com>: Dec 08 05:50AM -0800

Juha Nieminen <nospam@thanks.invalid> writes:
 
[...]
 
> I don't often like to quote the way-too-often-wrongly-quoted and
> way-too-often-completely-misunderstood "early optimization is the
> root of all evil", [...]
 
Amusing that this comment wrongly quotes the original.
Michael S <already5chosen@yahoo.com>: Dec 08 01:30PM -0800

On Thursday, December 8, 2022 at 3:50:43 PM UTC+2, Tim Rentsch wrote:
> > way-too-often-completely-misunderstood "early optimization is the
> > root of all evil", [...]
 
> Amusing that this comment wrongly quotes the original.
 
premature - ennenaikaista, ennenaikainen
early - aikaisin, aikainen
All words appear to have the same root 'aika'==time.
If I am going to believe google translate then 'ennenaikaista' means
literally 'before early time'. So, may be, for person that thinks
in Finnish it is natural to translate it back to English like 'early'.
 
It is not just Finnish.
It two languages that I speak most, common translation of
'premature' is 'before time' and 'too early'.
Neither of the languages derives it from 'mature'.
Now, 'immature' is completely different story. This word is
translated rather close to original. But Knuth said 'premature'
rather than 'immature' and that provokes difficulties in translation.
Juha Nieminen <nospam@thanks.invalid>: Dec 08 12:31PM

During the last few years I have had to read an inordinate amount of
code written by other people. It has really given me a big insight on
what makes code more and less readable and understandable. For example,
I could write an entire book on naming conventions alone, and how they
can make the code so much more readable, or make it almost inscrutable.
 
But another thing I have really learned to hate is the overuse of the
'auto' keyword. I have always opposed its needless overuse, but this
couple of years of reading other people's code has really confirmed
and cemented my previous opinion on it.
 
Some C++ programmers do not use 'auto' merely to save some typing,
as some kind of convenience feature. They go their way to use it
pretty much everywhere they can, even when it doesn't actually save
any typing or make anything more convenient. They use it like it were
the generic variable declaration keyword in many other languages
(quite typically "var").
 
The problem in using 'auto' everywhere, from the perspective of someone
who is reading the code, is that it hides the type in question. When
you see something like:
 
auto foobar = someFunction(a, b);
 
it's a complete mystery what that return type is, and thus the reader
(ie. me) has no idea what it actually is, what it does, and how it's
used. Could be an 'int', could be a 'double', could be a 'std::string',
or could be a custom type declared somewhere else in the program. That
line alone doesn't clarify. Quite often even subsequent lines of code
don't necessarily clarify.
 
It just makes code so much harder to read when this crucial information
has been hidden from you. This is not really what "information hiding"
should be about.
 
"Yada yada! Just use an IDE like everybody else does!"
 
Even putting aside the fact that well-written code shouldn't rely on the
reader using an IDE to understand it, there are many situations where
you don't have a fancy IDE to tell you what that type is, or where it
can be found, such as for example when reading and reviewing the code
in gitlab. Try reviewing code when you can't even see what the types
being used are.
 
Man, have I learned to hate the overuse of 'auto'...
Bo Persson <bo@bo-persson.se>: Dec 08 03:25PM +0100

On 2022-12-08 at 13:31, Juha Nieminen wrote:
> who is reading the code, is that it hides the type in question. When
> you see something like:
 
> auto foobar = someFunction(a, b);
 
Of course "overuse" is always bad, by definition. :-)
 
But here the problem could also be the use of names such as foobar and
someFunction. Why do they not tell what is happening?!
 
When I see code like
 
auto iter = container.begin();
 
I know that auto means "some kind of iterator", and don't really care
about exactly which one it is.
 
And if it is
 
auto size = user_name.size();
 
it doesn't help a bit if auto is replaced by size_type, because what
type is size_type **really**?!
 
Perhaps if we see auto as an automatic typedef, we can hate it less?
Muttley@dastardlyhq.com: Dec 08 03:48PM

On Thu, 8 Dec 2022 12:31:48 -0000 (UTC)
>any typing or make anything more convenient. They use it like it were
>the generic variable declaration keyword in many other languages
>(quite typically "var").
 
To be fair you could use the same argument about templating. Many times
I've seem a template function thats only ever used for 2 different types.
"Öö Tiib" <ootiib@hot.ee>: Dec 08 07:59AM -0800

On Thursday, 8 December 2022 at 14:32:04 UTC+2, Juha Nieminen wrote:
> in gitlab. Try reviewing code when you can't even see what the types
> being used are.
 
> Man, have I learned to hate the overuse of 'auto'...
 
Yes but it is tedious. Some types are *LONG*, especially what templates
can return. Some are not possible to express. Like in functional
programming:
 
auto ret_fun() { return [](int x) { return x; }; }
auto& int_returner = ret_fun();
 
Should I wrap the return value into std::function<int(int)> to have it possible
to express its type? Is that free or brings some overhead? What if there
is combo of templates that accept as arguments and return lambdas?
Mr Flibble <flibble@reddwarf.jmc.corp>: Dec 08 07:29PM

On Thu, 08 Dec 2022 15:48:08 +0000, Muttley wrote:
 
 
> To be fair you could use the same argument about templating. Many times
> I've seem a template function thats only ever used for 2 different
> types.
 
You should use a template if there are N types where N > 1, and guess
what? 2 > 1. Why? Because code duplication is bad even if there is only
one duplicate. You seem to be fractally wrong about most things.
 
/Flibble
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 08 01:44AM -0600

On 12/6/2022 11:42 PM, Lynn McGuire wrote:
 
> Something like "std::vector <std::string> formulas [max_ncp];"
 
> Thanks,
> Lynn
 
Thanks all !
 
Lynn
Juha Nieminen <nospam@thanks.invalid>: Dec 08 07:58AM

>> needs to grow.
 
> Not any more. Nowadays a factor like 1.5 is more popular, meaning
> something like 18 allocations for 1000 push_back()-s.
 
The more the reason to do the initial reserve if you know the number of
elements that will be added.
 
> This is from MSVC++19:
 
I believe both libstdc++ (used by default by gcc) and libc++ (used by
default by clang) double the size. I doubt they are going to change
any time soon.
 
Obviously there are advantages and disadvantages in each percentage.
Juha Nieminen <nospam@thanks.invalid>: Dec 08 08:03AM

>> Now I am wondering if I should be using std::array instead of std::vector.
 
> Only if the size of the vector will never change after it's created
 
Also, you need to know the size at compile time, which isn't a trivial
restriction.
 
If the size is determined at compile time, std::array is *almost* always
a more efficient solution than std::vector.
 
*Almost* always. There are situations where std::vector can actually be
the more efficient solution. One such situation is if you find the need
to move the vector around a lot (ie. with its move constructor/assignment
operator).
 
Also, extremely large arrays (megabytes or more) might be better allocated
with std::vector, as a C-style array / std::array may start exhibiting some
problems when it becomes too large. (Heaven forbid you create one on the
stack!)
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)