Date: Sat, 23 Oct 2021 21:06:18 +0200
On Sat, Oct 23, 2021, 20:24 Marcin Jaczewski via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> sob., 23 paź 2021 o 19:47 Gennaro Prota via Std-Discussion
> <std-discussion_at_[hidden]> napisał(a):
> >
> > On Mon, Oct 11, 2021, 21:01 Jason McKesson via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> >>
> >> On Mon, Oct 11, 2021 at 1:59 PM Gennaro Prota via Std-Discussion
> >> <std-discussion_at_[hidden]> wrote:
> >> >
> >> >
> >> >
> >> >
> >> > On Mon, Oct 11, 2021, 08:54 Anubhav Guleria via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> >> >>
> >> >> Thanks for clarifying.
> >> >>
> >> >> Any specific reason why container's pop_back method can't check for
> >> >> current size and if it is 0 then make the pop operation a no-op?
> >> >
> >> >
> >> > You'll find that C and C++ people are, with very few exceptions,
> fixated with micro-optimizations (a known anti-pattern).
> >>
> >> Point of order:
> >>
> >> Micro-optimization as an anti-pattern is only a legitimate argument
> >> when you're talking about an application *as a whole* (or at the very
> >> least, large-scale systems that have relatively minimal interaction
> >> with the outside world). If you're writing an application, you should
> >> concern yourself with the application's performance as a whole.
> >>
> >> Libraries are a different story, *especially* low-level utility
> >> libraries. Such libraries have two properties that matter in this
> >> context: they solve very specific problems, and if they cause a
> >> performance issue in the application that uses it, the maker of that
> >> application *cannot fix it*.
> >>
> >> When you're writing a piece of software for a specific purpose within
> >> a specific application, avoiding micro-optimizations makes sense. When
> >> you're writing a tool for other people to use, and you cannot predict
> >> which performance issues matter to which ones of your users, then you
> >> need to *assume* that these optimizations matter. Because if you don't
> >> make that assumption, and you're *wrong* for a particular user... they
> >> can't fix the problem *you* created.
> >>
> >> Not without ditching your library and building their own. Which means
> >> that your library failed at its job.
> >>
> >> It's the difference between worrying about the weight of a hammer and
> >> worrying about the weight of the shovel at the end of the excavator. A
> >> few grams of weight on a hammer can matter a lot for how many times
> >> you can swing it before it gets tiring. But a few grams in a shovel is
> >> irrelevant to the fuel performance of an excavator.
> >>
> >> Makers of low-level tools need to think about things that makers of
> >> high-level tools don't. And vice-versa. It is a mistake to apply rules
> >> meant for one use case to the other.
> >
> >
> > A classical argument I've heard many times. But it's an argument of
> immaturity, in my book. Paraphrasing Alan Perlis, if someone says he wants
> to make their library suitable for every application, give them a lollipop.
> >
> Why does everyone still use C++ where is there C# (or Java) that is a
> "better" language that removes all bad aspects of C++?
> Because it's immature to think that this does not go without costs,
> C++ is "bad" because it needs to be, even more,
> many still stick to C where it is even less "robust" and they have
> many valid reasons to do so.
>
The only technical reason to use C is the lack of a C++ compiler for your
platform. All the other reasons are skill-related (lack of competent
people), political or psychological ("C is faster").
> The point is that "optimization", as they call it, comes almost always at
> the expense of the most important factors, i.e. robustness and
> maintainability. If you can get speed without impacting those, or
> development time and cost, then fine. Otherwise, I call it "pessimization".
> >
> No this is the most perfect solution for every one, because if it is
> not robust for you, then you can trivially fix it by creating simple
> warpers that have robust checks, this can be easily done by a student.
>
Students have a lot of time in their hands. If you think that, in a
commercial environment, you have time to write the most basic
infrastructure, then you have never worked in one. And why should I write
or rewrite everything, anyway...
Writing a fast and performant structure from scratch is something that
> only a couple of people are capable of.
I see some megalomania, here :-). Don't assume that you or the C++
committee have more skills than others.
This is why std should support
> this version, not one that can be easily created based on it.
>
Define "easily". Does it include "on time and in budget" and "not requiring
a specialist" (which is harder to find and costs more)? And, yes, in case
you are wondering, I'm a specialist.
> So, serve the majority of users with a robust and responsible tool,
> leaving those with special needs handle them on their own, rather than
> serving the former badly for the sake of the few of the latter.
> >
> Again its easier to make a robust tool based on "sharp" tool than
> doing this in the opposite way.
> If C++ would not have performance edge then it should be abandoned.
>
> Beside for the whole gaming industry many std classes are TOO robust
> and they even roll more "sharp" classes to have one or two frames
> more.
> Half of C++ users drop exceptions because of its costs,
Out of ignorance.
and you ask to add more costs?
>
Yes. That should be the default. In most cases, it's not even a "cost".
> (But I'm not interested in a long discussion about this. This is
> something psychological, and convincing those who hold such positions to
> the contrary is extremely difficult, even if the evidence of the
> error-ridden software they produce should actually convince them without
> external intervention, if only they asked questions about the why's and
> were honest with themselves.)
> >
> Why do you not choose another language that follows your goals?
I use other languages, too.
Many
> there choosed C++ because of how it is and what tradeoff it does.
>
Most "choosers" do so out of a psychological drive ("another language would
be "slow").
P.S.: This is my last post in this thread. As I said, I don't mean to waste
my time convincing people who don't want to be convinced.
std-discussion_at_[hidden]> wrote:
> sob., 23 paź 2021 o 19:47 Gennaro Prota via Std-Discussion
> <std-discussion_at_[hidden]> napisał(a):
> >
> > On Mon, Oct 11, 2021, 21:01 Jason McKesson via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> >>
> >> On Mon, Oct 11, 2021 at 1:59 PM Gennaro Prota via Std-Discussion
> >> <std-discussion_at_[hidden]> wrote:
> >> >
> >> >
> >> >
> >> >
> >> > On Mon, Oct 11, 2021, 08:54 Anubhav Guleria via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
> >> >>
> >> >> Thanks for clarifying.
> >> >>
> >> >> Any specific reason why container's pop_back method can't check for
> >> >> current size and if it is 0 then make the pop operation a no-op?
> >> >
> >> >
> >> > You'll find that C and C++ people are, with very few exceptions,
> fixated with micro-optimizations (a known anti-pattern).
> >>
> >> Point of order:
> >>
> >> Micro-optimization as an anti-pattern is only a legitimate argument
> >> when you're talking about an application *as a whole* (or at the very
> >> least, large-scale systems that have relatively minimal interaction
> >> with the outside world). If you're writing an application, you should
> >> concern yourself with the application's performance as a whole.
> >>
> >> Libraries are a different story, *especially* low-level utility
> >> libraries. Such libraries have two properties that matter in this
> >> context: they solve very specific problems, and if they cause a
> >> performance issue in the application that uses it, the maker of that
> >> application *cannot fix it*.
> >>
> >> When you're writing a piece of software for a specific purpose within
> >> a specific application, avoiding micro-optimizations makes sense. When
> >> you're writing a tool for other people to use, and you cannot predict
> >> which performance issues matter to which ones of your users, then you
> >> need to *assume* that these optimizations matter. Because if you don't
> >> make that assumption, and you're *wrong* for a particular user... they
> >> can't fix the problem *you* created.
> >>
> >> Not without ditching your library and building their own. Which means
> >> that your library failed at its job.
> >>
> >> It's the difference between worrying about the weight of a hammer and
> >> worrying about the weight of the shovel at the end of the excavator. A
> >> few grams of weight on a hammer can matter a lot for how many times
> >> you can swing it before it gets tiring. But a few grams in a shovel is
> >> irrelevant to the fuel performance of an excavator.
> >>
> >> Makers of low-level tools need to think about things that makers of
> >> high-level tools don't. And vice-versa. It is a mistake to apply rules
> >> meant for one use case to the other.
> >
> >
> > A classical argument I've heard many times. But it's an argument of
> immaturity, in my book. Paraphrasing Alan Perlis, if someone says he wants
> to make their library suitable for every application, give them a lollipop.
> >
> Why does everyone still use C++ where is there C# (or Java) that is a
> "better" language that removes all bad aspects of C++?
> Because it's immature to think that this does not go without costs,
> C++ is "bad" because it needs to be, even more,
> many still stick to C where it is even less "robust" and they have
> many valid reasons to do so.
>
The only technical reason to use C is the lack of a C++ compiler for your
platform. All the other reasons are skill-related (lack of competent
people), political or psychological ("C is faster").
> The point is that "optimization", as they call it, comes almost always at
> the expense of the most important factors, i.e. robustness and
> maintainability. If you can get speed without impacting those, or
> development time and cost, then fine. Otherwise, I call it "pessimization".
> >
> No this is the most perfect solution for every one, because if it is
> not robust for you, then you can trivially fix it by creating simple
> warpers that have robust checks, this can be easily done by a student.
>
Students have a lot of time in their hands. If you think that, in a
commercial environment, you have time to write the most basic
infrastructure, then you have never worked in one. And why should I write
or rewrite everything, anyway...
Writing a fast and performant structure from scratch is something that
> only a couple of people are capable of.
I see some megalomania, here :-). Don't assume that you or the C++
committee have more skills than others.
This is why std should support
> this version, not one that can be easily created based on it.
>
Define "easily". Does it include "on time and in budget" and "not requiring
a specialist" (which is harder to find and costs more)? And, yes, in case
you are wondering, I'm a specialist.
> So, serve the majority of users with a robust and responsible tool,
> leaving those with special needs handle them on their own, rather than
> serving the former badly for the sake of the few of the latter.
> >
> Again its easier to make a robust tool based on "sharp" tool than
> doing this in the opposite way.
> If C++ would not have performance edge then it should be abandoned.
>
> Beside for the whole gaming industry many std classes are TOO robust
> and they even roll more "sharp" classes to have one or two frames
> more.
> Half of C++ users drop exceptions because of its costs,
Out of ignorance.
and you ask to add more costs?
>
Yes. That should be the default. In most cases, it's not even a "cost".
> (But I'm not interested in a long discussion about this. This is
> something psychological, and convincing those who hold such positions to
> the contrary is extremely difficult, even if the evidence of the
> error-ridden software they produce should actually convince them without
> external intervention, if only they asked questions about the why's and
> were honest with themselves.)
> >
> Why do you not choose another language that follows your goals?
I use other languages, too.
Many
> there choosed C++ because of how it is and what tradeoff it does.
>
Most "choosers" do so out of a psychological drive ("another language would
be "slow").
P.S.: This is my last post in this thread. As I said, I don't mean to waste
my time convincing people who don't want to be convinced.
-- Gennaro Prota https://about.me/gennaro
Received on 2021-10-23 14:06:31