Thursday, July 21, 2022

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

Lynn McGuire <lynnmcguire5@gmail.com>: Jul 20 07:22PM -0500

On 7/20/2022 4:42 PM, Cholo Lennon wrote:
> Cholo Lennon
> Bs.As.
> ARG
 
I use function overloading extensively in my C++ code code. Works
great and it is useful to have the same name with different arguments in
many classes. Here is one of my helper functions, tuple:
 
std::vector <int> tuple ();
std::vector <int> tuple (int int1);
std::vector <int> tuple (int int1, int int2);
std::vector <int> tuple (int int1, int int2, int int3);
std::vector <int> tuple (int int1, int int2, int int3, int int4);
std::vector <int> tuple (int int1, int int2, int int3, int int4, int int5);
std::vector <int> tuple (int int1, int int2, int int3, int int4, int
int5, int int6);
std::vector <int> tuple (int int1, int int2, int int3, int int4, int
int5, int int6, int int7);
std::vector <int> tuple (int int1, int int2, int int3, int int4, int
int5, int int6, int int7, int int8);
std::vector <int> tuple (int int1, int int2, int int3, int int4, int
int5, int int6, int int7, int int8, int int9);
std::vector <int> tuple (int int1, int int2, int int3, int int4, int
int5, int int6, int int7, int int8, int int9, int int10);
 
and so on to int60. I also have tupleString and tupleTuple.
 
I also have the following methods in my DesValue class:
 
virtual void setValue (int aValue);
virtual void setValue (double aValue);
virtual void setValue (char * aValue);
virtual void setValue (std::string &aValue);
virtual void setValue (std::vector <int> aValue);
virtual void setValue (std::vector <double> aValue);
virtual void setValue (std::vector <std::string> aValue);
virtual void setString ( std::string aString );
virtual void setString ( std::vector <std::string> aString );
 
Lynn
Gawr Gura <gawrgura@mail.hololive.com>: Jul 20 10:44PM -0700

On 7/20/22 17:22, Lynn McGuire wrote:
>    virtual void setString ( std::string aString );
>    virtual void setString ( std::vector <std::string> aString );
 
> Lynn
 
Is there a specific reason you've chosen to implement your tuple
function out to 60 elements rather than using a std::vector list
initializer?
Juha Nieminen <nospam@thanks.invalid>: Jul 21 05:45AM

> overloading. One of the explanations of this decision is that "function
> overloading is an anti-pattern", because, among other things, "it leads
> to less readable and understandable code".
 
Any language feature can be misused and "lead to less readable and
understandable code". Heck, *function names* can be very easily used to
write incomprehensible code (and believe me I have experience on that,
having had to read a boatload of code made by other people... code that
uses *extremely* poor function and variable name choices. That alone
makes a lot of code ten times harder to understand than it would have to.)
 
I assume that Rust doesn't have support for generic code, then? Because
function overloading is what makes generic code work.
 
I suppose generic code could still be written without function overloading,
but it would be extraordinarily limited. Heck, the arithmetic and comparison
operators supported by the vast majority of languages are "overloaded
functions" of sort (and are part of what makes generic code work). I assume
Rust has different arithmetic types, and operators like + and - work on
all of them, and you don't have to specify different function names for
different types in order to eg. add them or subtract them.
 
User-defined overloaded functions aren't much different from overloaded
operators. It's a bit artificial to deliberately limit the overloading of
functions when the language already has overloading of operators built in.
 
How do you print things in Rust, if it doesn't support function overloading?
Or does it make an exception for itself, for its own elementary functions?
Paavo Helde <eesnimi@osa.pri.ee>: Jul 21 09:04AM +0300

21.07.2022 00:42 Cholo Lennon kirjutas:
> in several prototypes for a single function is really awful).
 
> What is your opinion about the function overloading as an
> "anti-pattern"? is it?
 
Function overloading is great for simple utility functions where one
immediately understands what it is expected to do, and it basically does
the same thing in all overloads.
 
Function overloading becomes anti-pattern when the overloads do
different things. For example, there are processing stages where a
function processes some parameters, then calls another function with the
same name and partially processed parameters. This may create confusion,
especially if I search the codebase for the function name and it is not
immediately obvious which overload is called where. Better to add
suffixes to the names like "stage1" and "stage2" if one cannot think of
better names.
 
If the functions are not related at all and have the same name just "by
coincidence", then it surprisingly becomes easier because then usually
it is obvious at the call site which overload is used.
 
Yes I know there is an IDE command "go to definition" and sometimes this
is even working. Still, the less confusion, the better.
Juha Nieminen <nospam@thanks.invalid>: Jul 21 07:16AM

> immediately obvious which overload is called where. Better to add
> suffixes to the names like "stage1" and "stage2" if one cannot think of
> better names.
 
I have to deal in the past with production code bases where function
overloading was heavily abused (in more or less a manner of "I'm going
to overload this function name because I can", rather than it making sense),
and it made the code that used those overloaded functions extraordinarily
confusing to read.
 
For example, the code would be full of function calls of the form
"convert(a, b);" and that's it. Not very informative, plus there was like
nine billion overloaded versions of that function for different types of
first and second parameter, doing almost every possible thing under the
sun (eg. converting from an int, unsigned, long, unsigned long, float,
double, etc. to a std::string or to a std::wstring, with the corresponding
overloaded versions doing the conversion in the other direction. And that
was just one set of conversions. There were many more, including conversions
between string encodings. All named "convert()", with different types
and amounts of parameters.)
 
In fact, the very fact that the function name didn't even tell if it
was converting from the first parameter to the second or the other
way around made the code really obfuscated to read.
 
And the thing was, absolutely nowhere in the code was there any advantage
in the function being overloaded. In other words, at no point in the
codebase was there any sort of template or abstracted type that would
have benefited from that 'convert()' function being overloaded.
 
If I were to refactor all that code, I would create unique names for
all those functions, clearly stating the types and the direction of
conversion, like:
 
convert_to_int_from_charp(a, b);
convert_to_int_from_string(a, b);
convert_to_string_from_int(a, b);
 
and so on. If, and only if, the need appears for an overloaded version
of some of those functions, then they can be implemented *in addition*
to those more explicit names (the overloaded versions just calling the
more explicitly named versions), for example like:
 
void convert_to_value_from_string(int, const std::string&);
void convert_to_value_from_string(double, const std::string&);
 
etc. Only in the absolute extreme need would I resort to a completely
overloaded name that encompasses all those conversions. Even then I would
still use a name clearer than just 'convert()', even if it's just
something like 'convert_to_value_from_value()' (to indicate which
parameter is the destination and which is the source.)
 
(And no, I most definitely do not subscribe to the "brevity over clarity"
principle of programming. The more code written by other people I have
to deal with, the less I subscribe to the principle. When I have to read
other people's code, I really get an appreciation for clearly named
functions and variables, which are not only clearly named but also
follow a clear consistent naming pattern and convention, rather than
different patterns and conventions being wildly mixed, even within
the same source file.)
 
That being said (and as I mentioned in my other reply to this thread),
function overloading most definitely has its use, especially in
generic code.
Lynn McGuire <lynnmcguire5@gmail.com>: Jul 21 04:17PM -0500

On 7/21/2022 12:44 AM, Gawr Gura wrote:
 
> Is there a specific reason you've chosen to implement your tuple
> function out to 60 elements rather than using a std::vector list
> initializer?
 
I came to C++ from Smalltalk. Tuple was a standard class and function
and was easy to convert using my handwritten converter.
 
Lynn
Lynn McGuire <lynnmcguire5@gmail.com>: Jul 21 04:22PM -0500

On 7/21/2022 2:16 AM, Juha Nieminen wrote:
 
> That being said (and as I mentioned in my other reply to this thread),
> function overloading most definitely has its use, especially in
> generic code.
 
Another one of my favorites are my asString methods.
 
std::string asString ();
std::string asString (void * val);
std::string asString (int val);
std::string asString (long val);
std::string asString (unsigned int val);
std::string asString (double val);
std::string asString (unsigned long val);
std::string asString (const char *val);
std::string asString (int val, const char * conversion);
std::string asString (long val, const char * conversion);
std::string asString (unsigned int val, const char * conversion);
std::string asString (unsigned long val, const char * conversion);
std::string asString (double val, const char * conversion);
std::string asString (long long val);
 
Lynn
Manfred <noname@add.invalid>: Jul 21 01:29AM +0200

On 7/20/2022 11:49 AM, Juha Nieminen wrote:
 
> (To be fair, a couple of those "better than C++" languages have become
> successful on their own right. They have still failed to replace C++,
> though. Maybe the hundreth time is the charm?)
 
One major problem I see with all those wannabe C++ successor is that C++
has built a foundation that is several decades long, which counts for
reliability and stability of the language (until the committee will
manage to ruin this by keeping on doing what they are doing as of late)
These qualities are very valuable in projects and organizations where
product quality matters.
 
In order to gain a comparable level of recognition, a successor of C++
would have to be building a similar foundation, and die along the way.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 21 01:06AM +0100

On Thu, 21 Jul 2022 01:29:08 +0200
> product quality matters.
 
> In order to gain a comparable level of recognition, a successor of C++
> would have to be building a similar foundation, and die along the way.
 
Indeed, as Keynes said "In the long run we are all dead". No one knows
what language people (if they then exist) will be programming in in 100
years time.
 
I don't know how "official" Carbon is at Google. Despite Google's
forays into things like Go, its codebase is heavily invested in C++.
The thing I take from this is that there is some level of organisation
within that company that is dissatisfied with C++'s evolution. Whether
this is a transient phenomenen, some cry for solace, or something more
long lasting remains to be seen.
David Brown <david.brown@hesbynett.no>: Jul 21 04:01PM +0200

On 21/07/2022 02:06, Chris Vine wrote:
 
> Indeed, as Keynes said "In the long run we are all dead". No one knows
> what language people (if they then exist) will be programming in in 100
> years time.
 
We know some of it. We'll still have C, Cobol, and a bit of Fortran :-)
 
> I don't know how "official" Carbon is at Google. Despite Google's
> forays into things like Go, its codebase is heavily invested in C++.
 
These sorts of things are "bluesky" research for Google. They are
willing to finance them in the hope that they pay off, but they won't
bet the company on them.
 
> within that company that is dissatisfied with C++'s evolution. Whether
> this is a transient phenomenen, some cry for solace, or something more
> long lasting remains to be seen.
 
They are not the first developers to realise that C++ is not perfect!
Muttley@dastardlyhq.com: Jul 21 03:01PM

On Thu, 21 Jul 2022 16:01:54 +0200
>> what language people (if they then exist) will be programming in in 100
>> years time.
 
>We know some of it. We'll still have C, Cobol, and a bit of Fortran :-)
 
It'll depend heavily on how hardware evolves and I suspect the hardware
that exists in 100 years will bear little to no resemblence to what we
have now either in physical construction or logical operation. Perhaps it'll
be quantum, perhaps it'll be something that hasn't even been thought of yet.
 
>> this is a transient phenomenen, some cry for solace, or something more
>> long lasting remains to be seen.
 
>They are not the first developers to realise that C++ is not perfect!
 
https://pmac-agpc.ca/project-management-tree-swing-story
 
Number 12 is how C++ started out, Number 6 is what C++ should be, Number 3 is
what the steering committee have created in the last 10 years.
"gdo...@gmail.com" <gdotone@gmail.com>: Jul 21 08:45AM -0700

great name for a language.
David Brown <david.brown@hesbynett.no>: Jul 21 06:52PM +0200

> that exists in 100 years will bear little to no resemblence to what we
> have now either in physical construction or logical operation. Perhaps it'll
> be quantum, perhaps it'll be something that hasn't even been thought of yet.
 
C, Cobol and Fortran have been around for 50 years or more, and are all
still in serious use. Other languages come and go - and some have come,
but haven't gone yet (like C++). So the best guess we have as to the
languages of the future, is these apparently ever-lasting languages. (I
don't claim they will be the /only/ languages, or even the most popular
ones - just that they'll still be around and in use.)
 
Quantum computers are an expensive excuse to play with cool toys. I
think it is unlikely that they will ever actually be cost-effective for
solving real-world problems (as distinct from completely artificial ones
invented just to suit quantum computers). They /might/ turn out to be
helpful for certain specific optimisation problems. But for "everyday"
computing, they haven't a chance, and never will do.
 
(Feel free to contact me in a hundred years if I turn out to be wrong!)
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 21 12:39PM -0700

> that exists in 100 years will bear little to no resemblence to what we
> have now either in physical construction or logical operation. Perhaps it'll
> be quantum, perhaps it'll be something that hasn't even been thought of yet.
[...]
 
Wrt quantum... Check this out, Q#:
 
https://en.wikipedia.org/wiki/Q_Sharp
 
;^)
"gdo...@gmail.com" <gdotone@gmail.com>: Jul 21 12:42PM -0700

> helpful for certain specific optimisation problems. But for "everyday"
> computing, they haven't a chance, and never will do.
 
> (Feel free to contact me in a hundred years if I turn out to be wrong!)
 
it's a date. lol, 2122, July 21.
we will be wearing quantum watches synced to our quantum eye glasses and contact lenses.
πŸ˜‚
we will never forget another face or fact. it will always appear before us. cool right.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 21 12:45PM -0700

> we will be wearing quantum watches synced to our quantum eye glasses and contact lenses.
> πŸ˜‚
> we will never forget another face or fact. it will always appear before us. cool right.
 
LOL! Internet on demand. The mere act of a thought will flood the brain
with search results... ;^)
Michael S <already5chosen@yahoo.com>: Jul 21 01:17PM -0700

On Wednesday, July 20, 2022 at 5:08:24 AM UTC+3, Cholo Lennon wrote:
> Carbon, the latest programming language to be built within Google, was
> unveiled today as an experimental successor to C++...
 
> https://9to5google.com/2022/07/19/carbon-programming-language-google-cpp/
 
Sound like they don't have and don't plan to have BDFL.
Which mean mediocrity at best and irrelevance at worst.
Luckily, with google's weight behind them, worst case is not very likely,
"Fred. Zwarts" <F.Zwarts@KVI.nl>: Jul 21 09:47AM +0200

Op 20.jul..2022 om 14:11 schreef Anthony Capobianco:
 
> The name of the function doesn't describe what it does, it describes the intent of a dev using it.
> You use it when you intend to move something. If you only intend to make it an rvalue reference, then you can cast it.
> The intent is different. The compiler doesn't care what you call it, your coworkers might.
 
That is in general difficult to implement, because it is not the dev
using the function who give it a name, but the dev creating the function
who defines the name. When creating a function it might not be clear in
how many ways it can be used. Sometimes functions are used in unexpected
ways, not foreseen when creating the function. Therefore, when creating
a function, one usually give it a name according to what it does. If it
has a name according to its intended use, it may become very confusing
when it is used for other purposes.
That said, in this case it seems that it is very improbable that
std::move will be used for other purposes than moving.
Juha Nieminen <nospam@thanks.invalid>: Jul 21 09:05AM


> The name of the function doesn't describe what it does, it describes the intent of a dev using it.
> You use it when you intend to move something. If you only intend to make it an rvalue reference, then you can cast it.
> The intent is different. The compiler doesn't care what you call it, your coworkers might.
 
I think that the name 'std::move()' breaks more clarity conventions than
that.
 
'move()', as a verb, would indicate that the function itself does something,
in this case, that it does the moving. It would be completely concordant
with myriads of other such functions, like std::sort() (which itself does
the sorting), std::find() (which itself does the finding), std::copy()
(which itself does the copying) and so on.
 
Particularly that last one is extremely telling: Compare "std::copy()"
to "std::move()". They both sound, by their name, extraordinarily
closely related. It sounds like the former copies stuff from one
place to another (doing it itself), while the latter moves stuff
from one place to another (likewise doing it itself).
 
It would be highly bizarre if "std::copy()" would mean "this doesn't
actually copy anything, it just casts the parameter in such a manner
that it becomes copyable".
 
If the latter thing were needed, certainly it would be named something
clearer, like for example std::make_copyable(), or std::cast_to_copyable()
or something along those lines. Not just std::copy().
 
Likewise it would be highly bizarre if "std::sort()" did no sorting but
instead just somehow cast the parameter into something that can be sorted.
 
std::move() is extraordinarily unique among all standard library functions
in that it breaks this fundamental naming convention. Certainly someone
who knows well what std::copy() does but doesn't know what std::move()
does (but knows about move semantics) would assume that the latter does
the same thing as the former, but moving the elements instead of copying
them.
 
It can't even be a question of "move" being a short name. The standard
library doesn't shy away from using very long names if needed. Take for
example:
 
std::filesystem::recursive_directory_iterator::disable_recursion_pending()
Paavo Helde <eesnimi@osa.pri.ee>: Jul 21 01:12PM +0300

21.07.2022 12:05 Juha Nieminen kirjutas:
 
 
> Likewise it would be highly bizarre if "std::sort()" did no sorting but
> instead just somehow cast the parameter into something that can be sorted.
 
Yes, but e.g. std::unique() does not actually make a vector to contain
unique values. Like std::move(), it is only intended to be used as one
step toward the goal.
 
If moving was done by e.g. static_cast<T&&>(x), then each such code line
would need a comment a la "moving the value". Think of std::move() as a
replacement of this comment.
red floyd <no.spam.here@its.invalid>: Jul 21 01:09PM -0700

On 7/21/2022 2:05 AM, Juha Nieminen wrote:
> library doesn't shy away from using very long names if needed. Take for
> example:
 
> std::filesystem::recursive_directory_iterator::disable_recursion_pending()
 
Probably better would have been std::moveable() instead of std:move.
hester holt <hesterholt12@gmail.com>: Jul 21 12:47PM -0700

This is the PDF eBook version for Pathology of the Hard Dental Tissues By Albert Schuurs
(Download link for cheap price) https://booksca.ca/library/pdf-pathology-of-the-hard-dental-tissues-by-albert-schuurs/
olcott <NoOne@NoWhere.com>: Jul 21 02:11PM -0500

On 7/19/2022 7:27 PM, Ben Bacarisse wrote:
 
>> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
 
> I think I turned it off... I've been fiddling with Gnus/Emacs for
> years.
 
*I addressed your plea*
 
*Can you please begin reviewing my work again on comp.theory?*
*I just got out of the hospital I was very sick*
I will post the full C source-code of the halt decider.
 
Primarily I want it addressed as software engineering.
H(P,P)==0 is correct even if H is not a computable function.
 
Only after it is *fully reviewed* at the software engineering
level (which might be a breakthrough in the field of termination
analysis) then I want it reviewed as a computable function.
 
 
 
--
Copyright 2022 Pete Olcott
 
"Talent hits a target no one else can hit;
Genius hits a target no one else can see."
Arthur Schopenhauer
Bonita Montero <Bonita.Montero@gmail.com>: Jul 21 12:30PM +0200

#if defined(_WIN32)
#include <Windows.h>
#elif defined(__unix__)
#include <pthread.h>
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)