Wednesday, July 20, 2022

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

Cholo Lennon <chololennon@hotmail.com>: Jul 20 06:42PM -0300

I am learning Rust. One missing C++/Java feature is function
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".
 
This surprised me because I consider it very useful. I really hate
having to code multiple functions with different names and almost the
same functionality. I suffered this in Python (its solution based in
decorators is not the best), and also in Typescript (its solution based
in several prototypes for a single function is really awful).
 
What is your opinion about the function overloading as an
"anti-pattern"? is it?
 
Disclaimer: "Overloading" where only types differ (but the number of
parameters are the same) is possible in Rust using generic traits,
something like the following:
 
struct MyPrinter;
 
trait Printer<T> {
fn print(&self, value: T);
}
 
impl Printer<i32> for MyPrinter {
fn print(&self, value: i32) {
println!("Value: {}", value);
}
}
 
impl Printer<&str> for MyPrinter {
fn print(&self, value: &str) {
println!("Value: {}", value);
}
}
 
fn main() {
let foo = MyPrinter;
 
foo.print(10);
foo.print("Hello");
}
 
 
--
Cholo Lennon
Bs.As.
ARG
Cholo Lennon <chololennon@hotmail.com>: Jul 19 11:08PM -0300

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/
Muttley@dastardlyhq.com: Jul 20 08:29AM

On Tue, 19 Jul 2022 23:08:04 -0300
>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/
 
IOW they've realised no one outside Google gives a damn about Go so they're
trying again. The only language that has a chance of replacing C is Rust but
apparently its object model is a bit limited so no idea if it could replace C++
yet.
Juha Nieminen <nospam@thanks.invalid>: Jul 20 09:49AM

> 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/
 
So what's the count for the number of "better than C++, to replace it"
languages now?
 
I have lost the count a couple of decades ago.
 
(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?)
Cholo Lennon <chololennon@hotmail.com>: Jul 20 04:38PM -0300

> trying again. The only language that has a chance of replacing C is Rust but
> apparently its object model is a bit limited so no idea if it could replace C++
> yet.
 
I thought the same, that Rust could be the replacement for C/C++. I like
Rust, but I am not an expert on it to have a strong opinion, especially
about the integration with C/C++. Here the explanation "why not Rust"
from them:
 
https://github.com/carbon-language/carbon-lang/blob/trunk/docs/project/faq.md#why-not-rust
 
--
Cholo Lennon
Bs.As.
ARG
Cholo Lennon <chololennon@hotmail.com>: Jul 20 04:50PM -0300

On 7/20/22 6: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?)
 
Totally agree. A lot of "new" programming languages have advertised
themselves as a C++ successor/replacement, but all of them failed to
accomplish that goal.
 
My concern is that research efforts, and the community of developers,
are split, again, due to another new "promising" language.
 
--
Cholo Lennon
Bs.As.
ARG
Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Jul 20 02:38PM -0700

On Wednesday, 20 July 2022 at 20:38:26 UTC+1, Cholo Lennon wrote:
> Rust, but I am not an expert on it to have a strong opinion, especially
> about the integration with C/C++. Here the explanation "why not Rust"
> from them:
 
What would be telling is if language designers promised "a new Rust" rather
than "a new C++".
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 20 02:38PM -0700

On 7/20/2022 2: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?)
 
Fwiw, I was playing around with Unity that uses C# as a main means to
develop games. However, they sure do have a rather robust C binding into
their render logic and explain that they did it in order to be able to
exploit the efficiency of C wrt performance critical code.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 19 04:41PM -0700

On 7/16/2022 6:32 PM, Malcolm McLean wrote:
> (the move assignment was implemented as a pointer swap).
 
 
> It not really a case of UB. It's about the implied contract the move assignment
> operator makes.
 
Okay. That makes sense. Thank you.
Anthony Capobianco <kiiwy112@gmail.com>: Jul 20 05:11AM -0700

On Friday, July 15, 2022 at 2:02:28 PM UTC+2, Juha Nieminen wrote:
> moved, isn't it quite a misnomer?
 
> std::to_rvalue() might be more cryptic, but at least it would
> express much better what it's actually doing.
 
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.
Paavo Helde <eesnimi@osa.pri.ee>: Jul 20 03:26PM +0300

20.07.2022 15:11 Anthony Capobianco kirjutas:
 
> 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.
 
+1
Andrey Tarasevich <andreytarasevich@hotmail.com>: Jul 20 01:08PM -0700

On 7/15/2022 5:02 AM, Juha Nieminen wrote:
 
> But should it really depend on anything? Isn't that statement
> expressing the desire to *move* the contents of 'v2' into 'v1',
> thus leaving 'v2' empty?
 
No.
 
From the very beginning the concept of "moving" in C++ was designed
with the following axiom in mind:
 
Good-old classic copying is also a form of moving. Moving is a wider
concept, an extension of copying. Copying in that sense is a "laziest"
form of moving. ("Laziest" is a sense that it requires the last amount
of learning: i.e. one can just keep copying as before, and call it "moving")
 
It is very important to understand that in C++ full-blown, completely
non-destructive copying also qualifies as moving.
 
--
Best regards,
Andrey
"gdo...@gmail.com" <gdotone@gmail.com>: Jul 19 05:18PM -0700

fibble: what are they then. show everyone how smart you are.
list example, reasons, discussions, point of view.
I mean just show "me" how smart you are.
Mr Flibble <flibble@reddwarf.jmc.corp>: Jul 20 01:21AM +0100

On Tue, 19 Jul 2022 17:18:15 -0700 (PDT)
 
> fibble: what are they then. show everyone how smart you are.
> list example, reasons, discussions, point of view.
> I mean just show "me" how smart you are.
 
I don't have to show everyone how smart I am but perhaps you do: the
smart thing to do would be to read a book or two and/or a *decent*
online reference.
 
/Flibble
Manfred <noname@add.invalid>: Jul 20 03:06AM +0200

> is this one of those things where the committee had nothing better to do? ok, maybe I haven't got to the point where I see the demand for such, but I will be open-minded and use it when I see an opportunity.
 
> prevents ..., more intuitive ..., easier to type than ..., more expressive than ..., solves the problem of ..., well I'm sure I'll see all of that at some point.
 
Short answer: to facilitate compile time evaluation.
Bonita Montero <Bonita.Montero@gmail.com>: Jul 20 03:24AM +0200

Am 20.07.2022 um 03:06 schrieb Manfred:
>> expressive than ..., solves the problem of ..., well I'm sure I'll see
>> all of that at some point.
 
> Short answer: to facilitate compile time evaluation.
 
The problem with compile-time evaluation is that this might cost
a lot of CPU-time if the compiler does that at any place. So the
developer suggests the compiler where this might be appropriate.
David Brown <david.brown@hesbynett.no>: Jul 20 09:27AM +0200


> prevents ..., more intuitive ..., easier to type than ..., more
> expressive than ..., solves the problem of ..., well I'm sure I'll
> see all of that at some point.
 
A useful reference for C++ is cppreference.com. This should be your
starting point for information about a C++ feature - it is technical and
precise, but more readable than the standards and it makes it clear how
things change between C++ standards :
 
<https://en.cppreference.com/w/cpp/language/constexpr>
 
Of course, that is just the technical details - it doesn't cover the
question of if, and why, people use constexpr.
 
 
Basically, a "constexpr" function is one which /can/ be evaluated at
compile time, to give a "core constant expression" result. And a
"constexpr" variable is one which is definitely known and fixed at
compile time.
 
Suppose you want some arrays whose sizes are square numbers - maybe you
want to put matrices in there. You can write :
 
int xs1[16];
 
You can also write :
 
int xs2[4 * 4];
 
Then you think a helper function is a good idea - perhaps you will
generalise things later :
 
int square(int x) { return x * x; }
 
int xs3[square(5)];
 
Suddenly, this won't compile - even though it is "obvious" that the size
of the array is fixed.
 
The answer is to make "square" a constexpr function:
 
constexpr int square(int x) { return x * x; }
 
The function body has not changed, but you have now said that /if/ the
values passed to it are "core constant expressions", so is the result of
the function. (You can still use it with variables, in which case it
acts like a normal run-time function.)
 
Now the declaration for "xs3" is fine, because "square(5)" is a
compile-time constant.
 
 
For a variable, if you make it "constexpr", then you are insisting that
the compiler figures out its initialisation at compile time, and you are
guaranteeing that no one can try to change its value (no cheating with
const_cast<> and the like).
 
So this makes "constexpr int n = 10;" useful in more contexts than
"const int n = 10;" would be. For example, where in C you might have had :
 
#define MAX_NO_OF_WHATSITS 100
 
you now have :
 
constexpr int max_no_of_whatsits = 100;
 
 
Probably the biggest difference comes with templates and more advanced
metaprogramming - constexpr lets you simplify the code a good deal, and
can be used in template parameters, "if constexpr" statements, concepts,
noexcept specifiers, etc.
 
You can also use constexpr variables and functions for pre-computing
tables or other values, for more efficient runtime code, for switch
labels, and various other places where you need a "real" constant.
Muttley@dastardlyhq.com: Jul 20 08:23AM

On Wed, 20 Jul 2022 03:06:18 +0200
>than ..., solves the problem of ..., well I'm sure I'll see all of that at
>some point.
 
>Short answer: to facilitate compile time evaluation.
 
IME ever constexpr I've seen could have been evaluated by the developer
directly and just been a hard coded const/macro. Constexprs are generally a
solution looking for a problem.
Juha Nieminen <nospam@thanks.invalid>: Jul 20 09:46AM

> is this one of those things where the committee had nothing better to do? ok, maybe I haven't got to the point where I see the demand for such, but I will be open-minded and use it when I see an opportunity.
 
> prevents ..., more intuitive ..., easier to type than ..., more expressive than ..., solves the problem of ..., well I'm sure I'll see all of that at some point.
 
constexpr alleviates a serendipitous problem that manifested itself all the
way back in the early days of C++98 (perhaps even before).
 
You see, the template mechanism was originally designed to merely allow
writing generic classes and generic functions, where you just implement the
class or function once, but it can be used for any type (that's compatible
with the implementation): The compiler automatically generates a version
of the implementation where the types have been replaced. Thus it's much
easier to use the same code for multiple types (and the code is ostensibly
as optimized for that type as possible).
 
However, it was quite soon discovered that, serendipitously, the C++
template mechanism could be used for a limited form of compile-time
programming. The template mechanism almost forms a "language within
a language", where using its own peculiar syntax you can do all kinds
of calculations at compile time. The so-called "template metaprogramming"
paradigm was born.
 
It was soon developed into a surprisingly complex "sub-language" of C++.
You could have linked lists, with all typical list operations (appending,
splicing, splitting, traversing, etc.) and you could do all sorts of
calculations, all at compile time.
 
The problem? Because templates were never designed for this from
the ground up, the syntax is not optimal for this, and "template
metaprogramming" programs tend to be very obfuscated, complicated and
hard to understand. There's also the problem that what you can do with
them is very limited. They are also quite heavy for the compiler to
evaluate (and, in some cases, could require an enormous amount of RAM
because complex "template metaprograms" effectively result in
ginormously long type declarations that may take even megabytes of RAM.)
 
Thus a better solution was devised for C++11: constexpr.
 
constexpr allows using C++'s own "normal" syntax, rather than the
complicated template syntax, in order to do those same calculations
much easier. In addition, constexpr code is easier to read, supports
things that template metaprogramming doesn't (such as floating point
calculations), and is much more efficient for the compiler to evaluate
and (usually) requires significantly less RAM. Plus, the exact same code
can be also used at runtime in addition to compile time, so it's yet
again one thing where code repetition is avoided.
David Brown <david.brown@hesbynett.no>: Jul 20 01:04PM +0200


> IME ever constexpr I've seen could have been evaluated by the developer
> directly and just been a hard coded const/macro. Constexprs are generally a
> solution looking for a problem.
 
Many things could be calculated by the developer and hardcoded into
software. But we usually don't do that, when the programming language
provides a way to handle it. When you use "sizeof" in a memcpy or
allocation function, it is not because the developer is incapable of
figuring out the size of the type. It is because using "sizeof" makes
code clearer, easier to change, maintain or re-use, easier to port, and
less likely to be wrong.
 
The same logic applies to other compile-time calculations. Let the
computer do what the computer is good at, leaving the programmer to do
what he/she is better at.
Muttley@dastardlyhq.com: Jul 20 03:12PM

On Wed, 20 Jul 2022 13:04:57 +0200
 
>The same logic applies to other compile-time calculations. Let the
>computer do what the computer is good at, leaving the programmer to do
>what he/she is better at.
 
sizeof() makes it clear what you are doing. A constexpr is code that someone
will have to understand and/or manually execute to find what the value it
produces is. I'm not sure adding code to create const values aids code clarity
in any way.
Jim the Geordie <jim@jimXscott.co.uk>: Jul 20 12:49AM +0100

In article <tb6ujm$3hi4a$1@paganini.bofh.team>, invalid@invalid.net
says...
> > settings. For some groups at random...)
 
> Perhaps you should post this to Thunderbird Newsgroup where they might
> tell you what your mistakes. Thunderbird is pretty robust newsreader.
 
Or try Gravity
 
--
Jim the Geordie
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jul 20 01:27AM +0100

>> something has changed over the years.
 
> That's odd. I use Gnus, and it inserts this header line:
 
> 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.
 
--
Ben.
Manfred <noname@add.invalid>: Jul 20 03:09AM +0200

On 7/20/2022 2:27 AM, 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.
 
That makes sense. I guess the entertaining part, now, is figuring out
how to turn it back on..
Jack Lemmon <invalid@invalid.net>: Jul 19 07:50PM +0100

On 18/07/2022 22:03, Vir Campestris wrote:
 
> (I'm using Thunderbird which has developed a really annoying bug. It
> hides all threads, not just the unread ones, and forgets the sort
> settings. For some groups at random...)
 
Perhaps you should post this to Thunderbird Newsgroup where they might
tell you what your mistakes. Thunderbird is pretty robust newsreader.
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)