"Modern C++ Won't Save Us" by alex_gaynor

[Lynn McGuire]

"Modern C++ Won't Save Us" by alex_gaynor
https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

Neither will Rust or Swift.

Lynn

[Richard]

[Please do not mail me a copy of your followup]

Lynn McGuire <lynnmc...@gmail.com> spake the secret code
<q9o4mr$a7q$1...@dont-email.me> thusly:

>"Modern C++ Won't Save Us" by alex_gaynor
> https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/

Snore. Nothing new here.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[Mel]

Rust is nice but you can't do almost anything in safe Rust. Tell mi
how to pass reference to object while in same time calling member
function of contaning interface in safe Rust. Needed because Rust
doesn't have inheritance.

--
Press any key to continue or any other to quit

[Öö Tiib]

The std::string_view is performance optimization so I would
reject its usage in review unless it is performance issue under work
(that I won't give to novices anyway).

However for "std::optional<std::unique_ptr<int>>" in code I would
suggest to end the work contract. Either it was deliberate sabotage
or the author is totally net negative moron, anything that such
people touch turns into awfully inefficient and unmaintainable poop.

[blt_a...@jby0d1iimwxs9a3.org]

To sum up the original article it seems to say that because some people cut
themselves using real knives everyone should be forced to use plastic knives
even though it make take 3 times longer to cut your food. This argument is
getting really old and tired, especially when the (usually a) kid making the
argument seems to think memory safety is the only thing that matters wrt a
programming language. Taking it to its logical conclusion we should all
just revert to using BASIC.

To paraphrase something I read on slashdot - C and C++ are engineering tools,
not toys for children. You're expected to know what you're doing when you use
them.

[Manfred]

Also the example about references with lambda looks perverse to me.
Such usage of references to show use-after-free denotes lack of
knowledge of what C++ references are meant for, and possibly confusion
with practice of GC languages like C# and Java.

[Öö Tiib]

Most examples in article are novice errors. Exactly, one who does
not understand pointers and references and/or does not know what
responsibilities are left upon programmers in C++ may do something
like that. If static analyze does not reject it then an address sanitizer
will crash the tests. Other team members can explain to neophyte
what is wrong there, why and how it must be done instead. But with
perfectly pointless things (on so many levels) like
"std::optional<std::unique_ptr<int>>" I have no idea from where
to start. It just must be sarcasm, joke, sabotage, mental illness ... ?
What to do there? :(

[Öö Tiib]

The other programming languages are actually not toys in
any sense. Python for example performs about 30 times
worse than C++ (in my tests) and C# performs about 4
times worse.

OTOH the C and C++ programmers whose algorithms I can't
outperform using Python I consider "experienced" and whom
I can't beat with C# are "experts" for me.

[blt...@8xmamvr98iep9ojq59cw3.gov]

On Thu, 25 Apr 2019 00:30:32 -0700 (PDT)
=?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
>On Wednesday, 24 April 2019 19:22:21 UTC+3, blt_a...@jby0d1iimwxs9a3.org
>wrote:

>> To paraphrase something I read on slashdot - C and C++ are engineering tools,
>
>> not toys for children. You're expected to know what you're doing when you use
>
>> them.
>
>The other programming languages are actually not toys in
>any sense. Python for example performs about 30 times
>worse than C++ (in my tests) and C# performs about 4
>times worse.

No, they're not toys. But its horse for course. Python is great for small to
medium projects where absolute performance doesn't matter. But no sane person
would - for example - ever write a real time trade clearing system in it.

[Richard]

[Please do not mail me a copy of your followup]

blt_a...@jby0d1iimwxs9a3.org spake the secret code
<q9q2ff$1iq2$1...@gioia.aioe.org> thusly:

>To sum up the original article it seems to say that because some people cut
>themselves using real knives everyone should be forced to use plastic knives
>even though it make take 3 times longer to cut your food.

This parallels complaints I hear from people in real life. When I ask
to see examples of why they think C++ is horrible, every single time
it isn't C++, it is C style code. The error handling is painful and
error-prone, the memory management is done manually and error-prone
(e.g. using malloc for dynamic arrays instead of std::vector, using
C-style strings instead of std::string, etc.)

I once did an internal training for my team on the standard library
(e.g. vector, string, etc.) and entire categories of bugs disappeared
from our workflow.

>To paraphrase something I read on slashdot - C and C++ are engineering tools,
>not toys for children. You're expected to know what you're doing when you use
>them.

Well put.

[Manfred]

I wouldn't go that far, to me it appears just plain ignorance - with
some flavor of its twin companion, which is arrogance, by which he feels
entitled to spread his misconceptions as something others should count on.

> What to do there? :(
>

That is probably the saddest part. The author does not allow for
commentary on his posting, so there is no way to give him feedback about
any of it.

[blt...@3geioa3gw4m1utn25ccoo.com]

On Thu, 25 Apr 2019 16:24:22 -0000 (UTC)
legaliz...@mail.xmission.com (Richard) wrote:
>[Please do not mail me a copy of your followup]
>
>blt_a...@jby0d1iimwxs9a3.org spake the secret code
><q9q2ff$1iq2$1...@gioia.aioe.org> thusly:
>
>>To sum up the original article it seems to say that because some people cut
>>themselves using real knives everyone should be forced to use plastic knives
>>even though it make take 3 times longer to cut your food.
>
>This parallels complaints I hear from people in real life. When I ask
>to see examples of why they think C++ is horrible, every single time
>it isn't C++, it is C style code. The error handling is painful and
>error-prone, the memory management is done manually and error-prone
>(e.g. using malloc for dynamic arrays instead of std::vector, using
>C-style strings instead of std::string, etc.)

The only exception I would make is realloc(). Unfortunately C++ still doesn't
have an equivalent to it and in certain niche perfomance applications it is
extremely useful being able to keep memory allocation at the minimum required
at any given time.

[Ben Bacarisse]

C++ has realloc and both std::vector and std::string have a
shrink_to_fit method. In pointing out that C++ has realloc I'm not just
being facetious. It means that you can always construct your own C-like
solutions in those cases where realloc really is what's needed.

--
Ben.

[wyn...@gmail.com]

Öö Tiib於 2019年4月25日星期四 UTC+8下午3時30分43秒寫道：

Out of my own survey from local job market of recent months, C++ is at
the level just several points better than Cobol, about 10% less popular
than C#, no compete with Python.
Therefore, in this sense, I believe C++ rather deserve the word 'toy'
better (academic). I do not mean to embarrass many respectful people in
this forum, it's just the FACT I see.

[Bo Persson]

The amount of job ads does not directly reflect the number of positions
available (=popularity?).

Not sure about C++, but the old geezers who know Cobol just don't read
ads anyway. So no reason to publish any - just call a headhunter right away.

[wyn...@gmail.com]

Bo Persson於 2019年4月26日星期五 UTC+8下午8時29分11秒寫道：

If measured in longer period, the result should get close to 'popularity'

> Not sure about C++, but the old geezers who know Cobol just don't read
> ads anyway. So no reason to publish any - just call a headhunter right away.

In my place, 'headhunter' is also made known through ads, no other 'popular'
channels, if I understand the word 'headhunter' correctly.

[Paavo Helde]

With realloc() you can shrink or grow the allocated memory block. For
shrinking there is std::vector::shrink_to_fit(), no need for realloc().

When enlarging, there is typically no space to grow the block in-place
and realloc() becomes the equivalent of malloc+copy+free, no particular
need for realloc, and std::vector::resize() or push_back() makes the
same in a safer and cleaner way.

Finally, when a growing realloc() succeeds in-place then it means there
was some unused memory behind that. Might be the memory manager did not
do a good job when placing the requested blocks in memory initially and
left gaps. This sounds not like the goal of keeping the memory
allocation at the minimum all the time.

[Öö Tiib]

What you mean by survey? All surveys have for ages got "uninterested"
response from me.

> Therefore, in this sense, I believe C++ rather deserve the word 'toy'
> better (academic). I do not mean to embarrass many respectful people in
> this forum, it's just the FACT I see.

Lot of companies have dropped being visible on "job market". They
invite people they want directly and expect people who want to
join them also to contact them directly. Noteworthy geeks are
well interconnected and that network acts with rather low
outside visibility. C++ feels is at peak we had to hire about 30
devs more in first quarter.

[Öö Tiib]

So it is that combo you think?:
https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

> > What to do there? :(
> >
> That is probably the saddest part. The author does not allow for
> commentary on his posting, so there is no way to give him feedback about
> any of it.

Oh fine. Actually it is always sort of satisfying to beat them with
product of orders of magnitude different league instead of arguing. :D

[Melzzzzz]

On 2019-04-26, Stefan Ram <r...@zedat.fu-berlin.de> wrote:

> wyn...@gmail.com writes:
>>Therefore, in this sense, I believe C++ rather deserve the word 'toy'
>>better (academic).
>

> C++ is the standard language when developing
> state-of-the-art computer games. A lot of software from
> Microsoft is built using recent flavors of Visual C++
> (including large parts of Windows and Office). At Adobe all
> major applications are developed in C++ as are several
> high-performance and high-reliability components at
> Facebook. GCC now uses C++ as its implementation language.
> Chromium (browser), Firefox, and MySQL and probably a lot of
> other well-known software items are written in C++

Firefox uses Rust now, but larger parts are C++ alright.
>
>


--
press any key to continue or any other to quit...

Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[wyn...@gmail.com]

Melzzzzz於 2019年4月26日星期五 UTC+8下午10時05分08秒寫道：

I used to believe the same. But powerful!=popular

[Bo Persson]

No, not really. When you get no responses for your ads, you eventually
stop advertising. That doesn't mean that there are no vacancies. Or that
the popularity is low - it can also mean that everyone available is
already hired. High popularity.


Bo Persson

[Richard]

[Please do not mail me a copy of your followup]

wyn...@gmail.com spake the secret code
<935df0c9-de1e-42df...@googlegroups.com> thusly:

>Out of my own survey from local job market of recent months, C++ is at
>the level just several points better than Cobol, about 10% less popular
>than C#, no compete with Python.
>Therefore, in this sense, I believe C++ rather deserve the word 'toy'
>better (academic). I do not mean to embarrass many respectful people in
>this forum, it's just the FACT I see.

Niche demand does not mean toy. Erlang is not a toy language, but the
market demand for Erlang programmers is small. Ditto for things like
Clojure.

I've worked at several places where they said they didn't do any C++
it was all going to be Java or C# and lo and behold there's all this
C++ laying around that you also have to modify. I've also worked
places that were entirely C++ and not much else: embedded systems for
home automation and 3D graphics are two examples, I'm sure there are
others (like low latency/high frequency trading platforms).

It's been a long, long time (like at least since early 90s) since you
could stay relevant to the job market by only knowing a single language.

[Richard]

[Please do not mail me a copy of your followup]

blt...@3geioa3gw4m1utn25ccoo.com spake the secret code
<q9udoq$1upm$1...@gioia.aioe.org> thusly:

>The only exception I would make is realloc().

<https://github.com/bminor/glibc/blob/master/malloc/malloc.c> says
this in a comment:

"The returned pointer may or may not be the same as p. The
algorithm prefers extending p when possible, otherwise it employs
the equivalent of a malloc-copy-free sequence."

...which is what std::vector::resize does; if the new size is <= the
existing capacity, no memory allocations are performed because the new
size is extended into the existing capacity.

There are differences, of course. If the vector is shrunk via resize,
the unused capacity isn't returned to the free store as it would be with
the heap managed by malloc/realloc/free. If these semantics are
significant to you then you can easily create a vector like container
that manages everything with malloc/realloc/free.

It's similar to constructing a domain-specific string class in order
to obtain benefits specific to your problem domain.

[Richard]

[Please do not mail me a copy of your followup]

Manfred <non...@add.invalid> spake the secret code
<q9sp4b$122j$1...@gioia.aioe.org> thusly:

Use the Dissenter plug-in <https://dissenter.com/>

[Ian Collins]

On 27/04/2019 08:21, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> wyn...@gmail.com spake the secret code
> <935df0c9-de1e-42df...@googlegroups.com> thusly:
>
>> Out of my own survey from local job market of recent months, C++ is at
>> the level just several points better than Cobol, about 10% less popular
>> than C#, no compete with Python.
>> Therefore, in this sense, I believe C++ rather deserve the word 'toy'
>> better (academic). I do not mean to embarrass many respectful people in
>> this forum, it's just the FACT I see.
>
> Niche demand does not mean toy. Erlang is not a toy language, but the
> market demand for Erlang programmers is small. Ditto for things like
> Clojure.
>
> I've worked at several places where they said they didn't do any C++
> it was all going to be Java or C# and lo and behold there's all this
> C++ laying around that you also have to modify. I've also worked
> places that were entirely C++ and not much else: embedded systems for
> home automation and 3D graphics are two examples, I'm sure there are
> others (like low latency/high frequency trading platforms).
>
> It's been a long, long time (like at least since early 90s) since you
> could stay relevant to the job market by only knowing a single language.

Which is a shame. To many programmers "know" several languages without
much depth of knowledge. They invariably write with the same idioms an
all of them!

There is and probably always will be a place for specialist skills.

--
Ian.

[wyn...@gmail.com]

Bo Persson於 2019年4月27日星期六 UTC+8上午4時01分56秒寫道：

I admit the measure I made was flawed. However, it forces me to find
a way to re-think C++ in practice.
In my country, it's estimated about 30,000 new companies established
every year. One thing for sure they would setup a web site, so the
basic required skills are normally JavaScript,PHP,HTML,Python,MySQL,...
In all cases, the need for C++ is either avoided (E.g. using game engine) or
seemed deliberately separated to core minimum (If there were existing codes).

[Melzzzzz]

That is if all they do is cheap web shop....

> In all cases, the need for C++ is either avoided (E.g. using game engine) or
> seemed deliberately separated to core minimum (If there were existing codes).

--
press any key to continue or any other to quit...

U ničemu ja ne uživam kao u svom statusu INVALIDA -- Marko Marin

[jacobnavia]

Le 24/04/2019 à 00:47, Lynn McGuire a écrit :
> "Modern C++ Won't Save Us" by alex_gaynor
>    https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
>
> Neither will Rust or Swift.
>
> Lynn

In that article we have:

#include <iostream>
#include <string>
#include <string_view>

int main() {
std::string s = "Hellooooooooooooooo ";
std::string_view sv = s + "World\n";
std::cout << sv;
}

It took me a while to find this one. Actually, a list view is created
with the result of the expression

s + "World"

This is a temporary object that will disappear instantly, making a view
of a string that doesn't exist any more...


What bothers me is that there is no automatic mechanism for avoiding any
destruction of a string that has still views into it...

The constructor of a view could add the view to a list of views in the
string. The destructor of the string would fail if there are still views
to it. For instance, maybe other methods wpould be preferable

[jacobnavia]

Le 27/04/2019 à 20:09, jacobnavia a écrit :
> Actually, a list view

Sorry!

That should have been:

Actually, a string view

jacob

[Alf P. Steinbach]

Better to disallow /implicit/ construction of `string_view` from temporary.

With syntax like

const auto sv = string_view::temporary( s + "World\n" );

which is trivial to implement enforcement of, the problem would have
been very apparent.

However, requiring this explicitness for function call arguments would
IMO be impractical.

So for that it would be nice to have a `std::temp_string_view` type that
accepts both rvalue and lvalue constructor arguments.

An ordinary `std::string_view` would convert implicitly to
`std::temp_string_view`, but not vice versa.

---

Disclaimer: late in the day for me so there might be some problem with
my ideas here that I didn't think of.


Cheers!,

- Alf

[James Kuyper]

On 4/26/19 8:59 AM, wyn...@gmail.com wrote:
> Bo Persson於 2019年4月26日星期五 UTC+8下午8時29分11秒寫道：

...

>> Not sure about C++, but the old geezers who know Cobol just don't read
>> ads anyway. So no reason to publish any - just call a headhunter right away.
>
> In my place, 'headhunter' is also made known through ads, no other 'popular'
> channels, if I understand the word 'headhunter' correctly.

The defining characteristic of headhunters is that they hunt for
individual well-qualified people, rather than relying upon ads to
collect a large sample of qualified people in the hopes that one of them
will be suitable.

[wyn...@gmail.com]

James Kuyper於 2019年4月29日星期一 UTC+8下午12時52分49秒寫道：

...
The original question came from the OP: "Modern C++ Won't Save Us",
there, I thought those memory leaking problems should not be an issue
to experienced C++ programmers.

Then, in my own reflextion, I felt C++ programmer by now should begin
to be considered as 'rare' species. Because C++ fever is fading and
accelerating to fade by the weight of C++ itself.
The chance I see is technical singularity (the promised land?) or some
kind of break-through like the case in AI.

[james...@alumni.caltech.edu]

You might be right about that.
The ad for my current job listed 5 required skills, and 7 desirable
ones. I initially ignored that ad because I didn't have any of the
desirable skills, and of the 5 required skills, I only had two - a
knowledge of C++ (for some reason it was listed twice, with minor
differences in wording). However, a recruiter talked with me and told me
that C++ was the only actual requirement, and that I would be well
qualified for the job based solely upon my experience with C++, even
though that experience was much weaker than my experience with C. I was
skeptical, but that's how it actually turned out.

[Manfred]

On 4/26/2019 3:49 PM, Öö Tiib wrote:
> So it is that combo you think?:
> https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

It would look like that, indeed.
It is always curious to see these things formally studied like the world
were some lab setup.

>
>>> What to do there?:(
>>>
>> That is probably the saddest part. The author does not allow for
>> commentary on his posting, so there is no way to give him feedback about
>> any of it.
> Oh fine. Actually it is always sort of satisfying to beat them with
> product of orders of magnitude different league instead of arguing. :D

Which is also anthropologically amusing - the many faces of happiness.

[Richard]

[Please do not mail me a copy of your followup]

ja...@jacob.remcomp.fr spake the secret code
<qa25sm$e5u$1...@dont-email.me> thusly:

>What bothers me is that there is no automatic mechanism for avoiding any
>destruction of a string that has still views into it...

What you're looking for is a linter support that will tell you that
you're using a view into a temporary. Such things exist. IIRC, MSVC
is getting support for this based on a CppCon talk from last summer.

[Richard]

[Please do not mail me a copy of your followup]

wyn...@gmail.com spake the secret code

<773664b3-c093-4730...@googlegroups.com> thusly:

>I admit the measure I made was flawed. However, it forces me to find
>a way to re-think C++ in practice.
>In my country, it's estimated about 30,000 new companies established
>every year. One thing for sure they would setup a web site, so the
>basic required skills are normally JavaScript,PHP,HTML,Python,MySQL,...
>In all cases, the need for C++ is either avoided (E.g. using game engine) or
>seemed deliberately separated to core minimum (If there were existing codes).

I find it fun to program in JavaScript and C#. Of the remaining ones
you listed above, they would be in order from most to least fun: HTML/CSS,
Python, MySQL and finally PHP.

Knowing multiple programming languages and environments is very
useful. Not every problem is solved with equal amounts of effort in
different languages. Some things that are a snap in C++ are very
painful in JavaScript and vice-versa.

[Richard]

[Please do not mail me a copy of your followup]

wyn...@gmail.com spake the secret code

<fe248c8e-bdb7-4f23...@googlegroups.com> thusly:

>Then, in my own reflextion, I felt C++ programmer by now should begin
>to be considered as 'rare' species.

Again, it depends on the problem domain.

>Because C++ fever is fading and
>accelerating to fade by the weight of C++ itself.

People say this, but it's a silly position. You might as well say
that about any language with a large ecosystem of libraries and
techniques built around it. People point to the size of the C++
standard as "evidence" that C++ is too complicated, but they forget
that the size of the Java standard is comparable. It's a silly
argument.

Nobody is saying the NodeJS is suffering from the weight of the number
of node packages out there, nor is Python suffering from the number of
python packages, nor is Perl suffering from the size of CPAN, etc.

It's just a silly argument.

There is no one right tool for EVERY job. A software craftsman has
more than one tool in their toolbox and understands their relative
productivity for different tasks.

The days of the one language programmer are long gone, if they were
ever even here in the first place.

[Richard]

[Please do not mail me a copy of your followup]

"Alf P. Steinbach" <alf.p.stein...@gmail.com> spake the secret code
<qa2pn2$o3k$1...@dont-email.me> thusly:

>Better to disallow /implicit/ construction of `string_view` from temporary.

There are other approaches. Not everything has to be jammed into the
language or the standard library. Linters and IDEs can alert you to
silly mistakes as well. Once your broaden your thinking to realize
that not everything can (or should) be detected in the compiler or in
the standard library implementation, then problems like this become
tractable.

Shoving everything into the compiler/standard library and forcing the
checks all the time is the Java way of thinking. C++ thinks about
things differently.

[Ian Collins]

On 01/05/2019 10:49, Richard wrote:
>
> The days of the one language programmer are long gone, if they were
> ever even here in the first place.

I'm sure there plenty of well remunerated COBOL programmers enjoying a
happy retirement :)

--
Ian

[woodb...@gmail.com]

On Thursday, April 25, 2019 at 2:30:43 AM UTC-5, Öö Tiib wrote:
> On Wednesday, 24 April 2019 19:22:21 UTC+3, blt_a...@jby0d1iimwxs9a3.org wrote:
> > On Wed, 24 Apr 2019 06:07:46 -0700 (PDT)
> > =?UTF-8?B?w5bDtiBUaWli?= <oot...@hot.ee> wrote:
> > >On Wednesday, 24 April 2019 01:48:07 UTC+3, Lynn McGuire wrote:

> > >> "Modern C++ Won't Save Us" by alex_gaynor
> > >> https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/
> > >>
> > >> Neither will Rust or Swift.
> > >>
> > >> Lynn
> > >

> > >The std::string_view is performance optimization so I would
> > >reject its usage in review unless it is performance issue under work
> > >(that I won't give to novices anyway).
> > >
> > >However for "std::optional<std::unique_ptr<int>>" in code I would
> > >suggest to end the work contract. Either it was deliberate sabotage
> > >or the author is totally net negative moron, anything that such
> > >people touch turns into awfully inefficient and unmaintainable poop.
> >
> > To sum up the original article it seems to say that because some people cut
> > themselves using real knives everyone should be forced to use plastic knives
> > even though it make take 3 times longer to cut your food. This argument is
> > getting really old and tired, especially when the (usually a) kid making the
> > argument seems to think memory safety is the only thing that matters wrt a
> > programming language. Taking it to its logical conclusion we should all
> > just revert to using BASIC.
> >
> > To paraphrase something I read on slashdot - C and C++ are engineering tools,
> > not toys for children. You're expected to know what you're doing when you use
> > them.
>
> The other programming languages are actually not toys in
> any sense. Python for example performs about 30 times
> worse than C++ (in my tests) and C# performs about 4
> times worse.

What about Java? I guess it's a little faster than C#.
With C++ and Python gradually getting better, maybe there
will be some squeeze on C# and Java. I think Java is
more of a house of cards than C++.


Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

[Öö Tiib]

On Wednesday, 1 May 2019 01:49:56 UTC+3, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> wyn...@gmail.com spake the secret code
> <fe248c8e-bdb7-4f23...@googlegroups.com> thusly:
>

> >Because C++ fever is fading and
> >accelerating to fade by the weight of C++ itself.
>
> People say this, but it's a silly position. You might as well say
> that about any language with a large ecosystem of libraries and
> techniques built around it. People point to the size of the C++
> standard as "evidence" that C++ is too complicated, but they forget
> that the size of the Java standard is comparable. It's a silly
> argument.

I had a friend who wrote book-keeping programs in
FoxPro for DOS for little companies. When FoxPro for
Windows came out 1993 I asked if he is going to
upgrade he said no, he is old man and he can never
learn that all. And so the FoxPro died off. :)

Most general purpose languages are actually in very
similar weight category. There are no good ways out of it.

Language that refers too lot at other standards will so have
pile of (separately evolving) dependencies. Language that
leaves too lot of vital aspects up to implementations will
have implementations that extend the language in mutually
exclusive manner. Language that nails it down what may be
written in it will become narrowly special purpose.

And so Common Lisp (with its relatively short standard ANSI
X3.226:1994) is no way more pleasant to use nor to translate
between dialects than C++.

[Vir Campestris]

On 01/05/2019 04:09, woodb...@gmail.com wrote:
> What about Java? I guess it's a little faster than C#.
> With C++ and Python gradually getting better, maybe there
> will be some squeeze on C# and Java. I think Java is
> more of a house of cards than C++.

Why do you think Java will be faster than C#?

They're both byte code languages after all.

I also think that the ease of use of Java will have it around for a long
time. It's harder to leak resources accidentally in Java.

Andy

[Melzzzzz]

Java is c++ for dummies.

[wyn...@gmail.com]

Richard於 2019年5月1日星期三 UTC+8上午6時49分56秒寫道：

> [Please do not mail me a copy of your followup]
>
> wyn...@gmail.com spake the secret code
> <fe248c8e-bdb7-4f23...@googlegroups.com> thusly:
>
> >Then, in my own reflextion, I felt C++ programmer by now should begin
> >to be considered as 'rare' species.
>
> Again, it depends on the problem domain.
>
> >Because C++ fever is fading and
> >accelerating to fade by the weight of C++ itself.
>
> People say this, but it's a silly position. You might as well say
> that about any language with a large ecosystem of libraries and
> techniques built around it. People point to the size of the C++
> standard as "evidence" that C++ is too complicated, but they forget
> that the size of the Java standard is comparable. It's a silly
> argument.
>
> Nobody is saying the NodeJS is suffering from the weight of the number
> of node packages out there, nor is Python suffering from the number of
> python packages, nor is Perl suffering from the size of CPAN, etc.
>
> It's just a silly argument.
>

When people complained C++ is complicated or heavy, they do not refer to
C++'s various libraries.

> There is no one right tool for EVERY job. A software craftsman has
> more than one tool in their toolbox and understands their relative
> productivity for different tasks.
>

There must be at least one tool.

> The days of the one language programmer are long gone, if they were
> ever even here in the first place.

I prefer using C++ only (the core part), but I don't use standard library.
All are fine for me except using or maintaining other people's codes all
of them tends to be unnecessarily complex(lots names and rules and create
new kind of misuse).
E.g. pointers are just pointers to me. I don't use smart pointer or iterator.
The problem of memory leak and misuse are none issue to me.

[Öö Tiib]

Myth. In actual practice Java (and C# that is kind of "better" Java
from Microsoft) programs leak every precious resource there
is: sockets, file descriptors, threads, mutexes and memory.
Fortunately there is often plenty of that stuff but sometimes it
is concrete resource for what I need to compete and that they
leaked.
It is especially annoying under Windows where some of that
myriad of dumb Java or C# tools sneaking in background forgot
to close a file so I have to kill these using task manager or even
reboot the whole system for to get the file descriptor released.
Only then I can for example delete the file or the like.

[Ian Collins]

On 03/05/2019 18:06, wyn...@gmail.com wrote:

>
> I prefer using C++ only (the core part), but I don't use standard library.
> All are fine for me except using or maintaining other people's codes all
> of them tends to be unnecessarily complex(lots names and rules and create
> new kind of misuse).
> E.g. pointers are just pointers to me. I don't use smart pointer or iterator.
> The problem of memory leak and misuse are none issue to me.

I guess that makes you unique..

--
Ian.

[James Kuyper]

On 5/3/19 2:06 AM, wyn...@gmail.com wrote:
...

> I prefer using C++ only (the core part), but I don't use standard library.

How do you do input or output?

[Scott Lurndal]

Ian Collins <ian-...@hotmail.com> writes:
> Thunderbird/60.5.1
>In-Reply-To: <8a7013f3-bfae-4bbf...@googlegroups.com>
>Content-Language: en-US
>X-Received-Bytes: 1612
>X-Received-Body-CRC: 3831741180

There's a large amount of perfectly functional C++ code in the wild
that doesn't use smart pointers or iterators.

[Scott Lurndal]

Using operating system API's (e.g. POSIX pread/pwrite/mmap), for example.

In several of my past C++ projects (hypervisors, operating systems), I/O
was done the old fashioned way, by poking registers.

[Mr Flibble]

No, Ian is correct and you are not.

C++'s iterator model, for example, is near perfect (and realizing that
pointers can also be iterators is part of that).

As far as C++ is concerned (and modern C++ in particular) YOU ARE DOING IT
WRONG (tm).

/Flibble

--
“You won’t burn in hell. But be nice anyway.” – Ricky Gervais

“I see Atheists are fighting and killing each other again, over who
doesn’t believe in any God the most. Oh, no..wait.. that never happens.” –
Ricky Gervais

"Suppose it's all true, and you walk up to the pearly gates, and are
confronted by God," Bryne asked on his show The Meaning of Life. "What
will Stephen Fry say to him, her, or it?"
"I'd say, bone cancer in children? What's that about?" Fry replied.
"How dare you? How dare you create a world to which there is such misery
that is not our fault. It's not right, it's utterly, utterly evil."
"Why should I respect a capricious, mean-minded, stupid God who creates a
world that is so full of injustice and pain. That's what I would say."

[wyn...@gmail.com]

James Kuyper於 2019年5月3日星期五 UTC+8下午7時58分07秒寫道：

---------------
Hierarchy of system file class:
+-> My__Std (Internal, for standard devices)
|
+-> My::RegFile
|
My::SysFile -+-> My::ByteFlow --+-> My::ChrFile
. |
. +-> My::SockFile
. |
. +-> My::FifoFile
.
.--- ?? N.A.?? --+-> My::DirFile
.
.--- ?? N.A.?? --+-> MyBlkFile(not implemented)

------------- Demo. Example -----------
#include <My.stdio.h> // for cin/cout/cerr
#include <My.unistd.h> // for My::RdBuf (the whole file system in general)

using namespace My; // for clearity

int main()
try {
Errno r;
String str;
size_t n_wr; // number of data read or written

cin >> str; // Read characters from STDIN_FILENO to str
cout << str << MY_ENDL; // Write str to STDOUT_FILENO

// Reset cout to "fpath" associated device (could be regular file,
// character special file, socket file, or FIFO file)
// Note: This is a simple demo.
//
if((r=cout.reset("fpath",O_RDWR))!=Ok) {
MY_THROW( Reply(r) ); // Reply wraps class Errno for throwing purpose only
// MY_THROW registers __FILE__, __LINE__ info.
// before throw.
}
if((r=cout.write(str,n_wr))!=Ok) {
MY_THROW( Reply(r) );
}
if((r=cout.read(str.begin(),str._capacity(),n_wr))!=Ok) {
MY_THROW( Reply(r) );
}
str._setsize(n_wr);

// The behavior of reading is very dependent on the device, so data
// reading is normally done through class RdBuf.
// RdBuf generalizes sequential data reading from various ByteFlow
// devices, and for recovering packet message from read data stream.
//
RdBuf strm;

// Read till a character is in CharGrp (simplified explanation).
//
if((r=strm.read(cin,CharGrp,str))!=OK) {
MY_THROW( Reply(r) );
}

// Read request for exactly 1024 characters.
//
if((r=strm.read(cin,str,1024))!=OK) {
MY_THROW( Reply(r) );
}

return 0;
}
catch(Errno e) {
cerr << wrd(e) << MY_ENDL;
return e.c_errno();
}
catch(...) {
cerr << "Unknow throw type" MY_ENDL;
throw;
};

[Scott Lurndal]

Mr Flibble <flibbleREM...@i42.co.uk> writes:
>On 03/05/2019 14:04, Scott Lurndal wrote:
>> Ian Collins <ian-...@hotmail.com> writes:
>>> Thunderbird/60.5.1
>>> In-Reply-To: <8a7013f3-bfae-4bbf...@googlegroups.com>
>>> Content-Language: en-US
>>> X-Received-Bytes: 1612
>>> X-Received-Body-CRC: 3831741180
>>>
>>> On 03/05/2019 18:06, wyn...@gmail.com wrote:
>>>
>>>>
>>>> I prefer using C++ only (the core part), but I don't use standard library.
>>>> All are fine for me except using or maintaining other people's codes all
>>>> of them tends to be unnecessarily complex(lots names and rules and create
>>>> new kind of misuse).
>>>> E.g. pointers are just pointers to me. I don't use smart pointer or iterator.
>>>> The problem of memory leak and misuse are none issue to me.
>>>
>>> I guess that makes you unique..
>>
>> There's a large amount of perfectly functional C++ code in the wild
>> that doesn't use smart pointers or iterators.
>
>No, Ian is correct and you are not.
>
>C++'s iterator model, for example, is near perfect (and realizing that
>pointers can also be iterators is part of that).
>
>As far as C++ is concerned (and modern C++ in particular) YOU ARE DOING IT
>WRONG (tm).

While you are certainly entitled to your opinion, it's not universally
shared.

[Melzzzzz]

How do you solve leaks without sart pointers?


--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[Jorgen Grahn]

On Fri, 2019-05-03, Melzzzzz wrote:
> On 2019-05-03, Scott Lurndal <sc...@slp53.sl.home> wrote:
>> Mr Flibble <flibbleREM...@i42.co.uk> writes:
>>>On 03/05/2019 14:04, Scott Lurndal wrote:
>>>> Ian Collins <ian-...@hotmail.com> writes:
>>>>> On 03/05/2019 18:06, wyn...@gmail.com wrote:
>>>>>
>>>>>>
>>>>>> I prefer using C++ only (the core part), but I don't use
>>>>>> standard library. All are fine for me except using or
>>>>>> maintaining other people's codes all of them tends to be
>>>>>> unnecessarily complex(lots names and rules and create new kind
>>>>>> of misuse). E.g. pointers are just pointers to me. I don't use
>>>>>> smart pointer or iterator. The problem of memory leak and
>>>>>> misuse are none issue to me.
>>>>>
>>>>> I guess that makes you unique..
>>>>
>>>> There's a large amount of perfectly functional C++ code in the wild
>>>> that doesn't use smart pointers or iterators.
>>>
>>>No, Ian is correct and you are not.
>>>
>>>C++'s iterator model, for example, is near perfect (and realizing that
>>>pointers can also be iterators is part of that).
>>>
>>>As far as C++ is concerned (and modern C++ in particular) YOU ARE DOING IT
>>>WRONG (tm).
>>
>> While you are certainly entitled to your opinion, it's not universally
>> shared.
>
> How do you solve leaks without sart pointers?

YMMV, but I put my objects in containers, as part of other objects, or
as locals in functions. Code with is sprinkled with smart pointers
makes me suspicious -- IMO they should be used rarely.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Ian Collins]

Unique in "The problem of memory leak and misuse are none issue to me."

Code that doesn't use iterators is probably code that doesn't use the
standard containers. Such code is either very old, or written for
memory constrained systems, possibly without dynamic allocation. I've
contributed to both :)

--
Ian.

[Ian Collins]

The code base I'm currently working in uses them a lot simply because it
is event driven and passes shared messages between threads.

--
Ian.

[Melzzzzz]

So you put objects by value everywhere?
>
> /Jorgen

[Scott Lurndal]

>On Fri, 2019-05-03, Melzzzzz wrote:

>> On 2019-05-03, Scott Lurndal <sc...@slp53.sl.home> wrote:
>>> Mr Flibble <flibbleREM...@i42.co.uk> writes:
>>>>On 03/05/2019 14:04, Scott Lurndal wrote:
>>>>> Ian Collins <ian-...@hotmail.com> writes:
>>>>>> On 03/05/2019 18:06, wyn...@gmail.com wrote:
>>>>>>
>>>>>>>
>>>>>>> I prefer using C++ only (the core part), but I don't use
>>>>>>> standard library. All are fine for me except using or
>>>>>>> maintaining other people's codes all of them tends to be
>>>>>>> unnecessarily complex(lots names and rules and create new kind
>>>>>>> of misuse). E.g. pointers are just pointers to me. I don't use
>>>>>>> smart pointer or iterator. The problem of memory leak and
>>>>>>> misuse are none issue to me.
>>>>>>
>>>>>> I guess that makes you unique..
>>>>>
>>>>> There's a large amount of perfectly functional C++ code in the wild
>>>>> that doesn't use smart pointers or iterators.
>>>>
>>>>No, Ian is correct and you are not.
>>>>
>>>>C++'s iterator model, for example, is near perfect (and realizing that
>>>>pointers can also be iterators is part of that).
>>>>
>>>>As far as C++ is concerned (and modern C++ in particular) YOU ARE DOING IT
>>>>WRONG (tm).
>>>
>>> While you are certainly entitled to your opinion, it's not universally
>>> shared.
>>
>> How do you solve leaks without sart pointers?

Disciplined programming, of course. One writes the code such that
leaks cannot occur. You all seem to assume that C++
programmers are all stupid and incapable of writing correct code without
using the crutches that have been added to the language over the last
two decades. That's obviously not true. Granted, one needs to hire
capable programmers, but that's not been a problem, just requires due
diligence.

[Melzzzzz]

That depends on code. Smart pointers do what you have to do in all
your objects having pointers.

You all seem to assume that C++
> programmers are all stupid and incapable of writing correct code without
> using the crutches that have been added to the language over the last
> two decades. That's obviously not true. Granted, one needs to hire
> capable programmers, but that's not been a problem, just requires due
> diligence.

Smart pointers are not crutches, rather code reuse. If you like to
write smart pointer in every class, please do.

[Thiago Adams]

On Friday, May 3, 2019 at 4:53:40 PM UTC-3, Ian Collins wrote:
...

> The code base I'm currently working in uses them a lot simply because it
> is event driven and passes shared messages between threads.
>

Can you move the message? Or do you have to share it?

[Thiago Adams]

Just add some memory leak detector and you will be disciplined.
It is very easy to create one and use in debug.

For instance:

https://github.com/nothings/stb/blob/master/stb_leakcheck.h

[Ian Collins]

They are shared between multiple consumers.

--
Ian.

[Ian Collins]

"Crutches" such a smart pointers have been a feature of C++ since the
beginning because RAII has been a feature of C++ since the beginning.
RAII is one of C++'s core design features and greatest strengths.

--
Ian

[Ian Collins]

Why drive the ambulance to the bottom of the cliff when it belongs at
the top? Besides, memory isn't the only resource that can and should be
manages automatically.

Opposition to smart pointers (and by inference, RAII in general) is pure
Luddism!

--
Ian.

[Vir Campestris]

On 03/05/2019 08:59, Öö Tiib wrote:
> On Thursday, 2 May 2019 23:13:03 UTC+3, Vir Campestris wrote:

>>
>> I also think that the ease of use of Java will have it around for a long
>> time. It's harder to leak resources accidentally in Java.
>
> Myth. In actual practice Java (and C# that is kind of "better" Java
> from Microsoft) programs leak every precious resource there
> is: sockets, file descriptors, threads, mutexes and memory.

<snip>

I chose my words carefully.

It is harder to leak resources.

It is not impossible. I have an Android based satnav that has to be
rebooted every couple of weeks...

Andy

[Vir Campestris]

On 03/05/2019 21:01, Scott Lurndal wrote:
> Disciplined programming, of course. One writes the code such that
> leaks cannot occur. You all seem to assume that C++
> programmers are all stupid and incapable of writing correct code without
> using the crutches that have been added to the language over the last
> two decades. That's obviously not true. Granted, one needs to hire
> capable programmers, but that's not been a problem, just requires due
> diligence.

I use smart pointers because they make my life easier.

When writing Linux Kernel stuff I follow their rules - declare all
pointers at the beginning of the function and null them; have a single
exit point that release all non-null resources. And in case of error use
goto to get there.

It works. But it's clumsy, and occupies my mind with useless crud.

In C++ when I want a resource I create a variable to hold it when I want
it. And make sure it is one that will clean it up for me, so I don't
have to worry about whether that list at the end of the function is
complete. I can even abort processing mid-function and just return
E_FAIL if I want.

Andy

[Scott Lurndal]

Ian Collins <ian-...@hotmail.com> writes:
> Thunderbird/60.6.1
>In-Reply-To: <V61zE.288$fq3...@fx07.iad>
>Content-Language: en-US
>X-Received-Bytes: 3428
>X-Received-Body-CRC: 2919456816

I beg your pardon. I wasn't aware that smart pointers were part of C++
back in 1989 when we used a language called C++ to write an operating system
for a massively parallel processing system called OPUS.

Surely you don't need smart pointers to implement RAII; we had a rather clever (at the time)
use in that Operating System of a struct with a destructor that was used to track
resource allocation during processing of a 'fork' system call - if we needed to
bail from the fork prematurely (due to resource unavailability or permissions issues)
simply returning from the fork function caused the destructor to run which cleaned up
the partially allocated new process as it automatically ran the destructor for the local stack
instance of the cleanup class.

Even then, allocate in constructor, deallocate in destructor works just fine
without smart pointers.

[woodb...@gmail.com]

Yeah, I'm not as high on smart pointers as I once was.


Brian
Ebenezer Enterprises - If you can't join 'em, beat 'em.
https://github.com/Ebenezer-group/onwards

[Ian Collins]

Smart pointers have been part of C++ programming since C++ had automatic
object destruction; which it always has. I may not have been using C++
in 1989 (I didn't start until around 1990) but one of the features that
attracted me from C to C++ was the ability to manage memory and other
resources with objects.

> Surely you don't need smart pointers to implement RAII; we had a rather clever (at the time)
> use in that Operating System of a struct with a destructor that was used to track
> resource allocation during processing of a 'fork' system call - if we needed to
> bail from the fork prematurely (due to resource unavailability or permissions issues)
> simply returning from the fork function caused the destructor to run which cleaned up
> the partially allocated new process as it automatically ran the destructor for the local stack
> instance of the cleanup class.

You got it backwards, smart pointers are an example of RAII. They could
be described as the canonical example of RAII.

> Even then, allocate in constructor, deallocate in destructor works just fine
> without smart pointers.

Which is exactly what a smart pointer does, so I don't see your point.

--
Ian.

[Manfred]

Apropos 'harder'...
In C# exposing a COM object and having it properly Release()'d is
surprisingly hard.

[Melzzzzz]

In 1989? CFront? C++ in 1989 was not C++ of today. I can imagine what
that code looked like :P

[Melzzzzz]

Heh, I started to learn it around 1993-4 can't remember, but haven't use
it for anything seriously until 1999 ;)

[Paavo Helde]

Easy in toy programs, you mean. It only catches the leaks which are
triggered by the tests for which you have time to run through in this
mode. And it produces false alarms for long-lived static data
structures. And it expands the process memory so it might not fit in RAM
any more. Etc, etc.

[James Kuyper]

On 5/4/19 1:34 AM, Paavo Helde wrote:
> On 3.05.2019 23:22, Thiago Adams wrote:

...

>> Just add some memory leak detector and you will be disciplined.
>> It is very easy to create one and use in debug.
>
> Easy in toy programs, you mean. It only catches the leaks which are
> triggered by the tests for which you have time to run through in this
> mode. And it produces false alarms for long-lived static data
> structures.

What algorithm would a memory leak detector use that would confuse
"long-lived static data structures" for allocated memory?

The only things I would bother calling proper "memory leak detectors"
are integrated into the memory allocation and deallocation routines, and
as such always know precisely which pieces of memory are dynamically
allocated, and which are not (or at least, in the event of heap
corruption, are no more confused than those routines themselves would be).

[wyn...@gmail.com]

wyn...@gmail.com於 2019年5月3日星期五 UTC+8下午10時27分22秒寫道：

Correction:
1.The last tow "OK" should be "Ok"
2."catch(Errno e)" should be "catch(Errno& e)"
3.socket can't be constructed from "fpath"

But, have you noticed that the basic of 'My' filesystem API is easy to grasped.
Compared with standard library, from my point of view, no need to add that
many "implementational" names (and the accompanying rules).

From mathematical point of view, new names reduce reuse-ability of existing
names(components). Optimization-ability, along with other quality might
as well be sabotaged.

[wyn...@gmail.com]

Ian Collins於 2019年5月4日星期六 UTC+8上午7時42分20秒寫道：

I guess what Scott said is similar to what I do currently, e.g.

My::RegFile regf("tmpfile", O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
My::AtDestroy<My::Errno,const char*> rrad(My::unlink,regf);
...

Class AtDestroy collects info. needed to call resource release function
(RRAD Resource Release At Destruction), which may be ::free(), delete,
::clost(int), ::freeaddrinfo, unlock...
However, such usecase is not often encountered but necessary.

[Paavo Helde]

On 4.05.2019 14:14, James Kuyper wrote:
> On 5/4/19 1:34 AM, Paavo Helde wrote:
>> On 3.05.2019 23:22, Thiago Adams wrote:
> ...
>>> Just add some memory leak detector and you will be disciplined.
>>> It is very easy to create one and use in debug.
>>
>> Easy in toy programs, you mean. It only catches the leaks which are
>> triggered by the tests for which you have time to run through in this
>> mode. And it produces false alarms for long-lived static data
>> structures.
>
> What algorithm would a memory leak detector use that would confuse
> "long-lived static data structures" for allocated memory?

The one posted by grandparent which just redefines malloc/new and
instruments each call in the same way.

>
> The only things I would bother calling proper "memory leak detectors"
> are integrated into the memory allocation and deallocation routines, and
> as such always know precisely which pieces of memory are dynamically
> allocated, and which are not (or at least, in the event of heap
> corruption, are no more confused than those routines themselves would be).

The static data structures I talked about are allocated dynamically.
Rough example:

static std::map<std::string, std::shared_ptr<Module>> gTheGlobalMap;

int main() {
InitGlobalMap(gTheGlobalMap); // many dynamic allocations
RegisterPlugins(gTheGlobalMap); // many dynamic allocations
while (!terminated) {
ServiceRequests();
}
}

As long as the global map contents exist these are considered as
"leaked" by such a leak detection tool. In the program end it might get
deleted so it might make the picture clearer, but to be honest there
would no point in destroying such a global map, as it just makes the
program shutdown slower. So some programs and some third-party libraries
may skip the deletion step, causing a huge avalanche of false alarms
where real leaks are lost in. Been there, seen that.

Alas, the leaks may appear and cause problems long before the program
end. And in some cases the leaks are not leaks "by definition", but just
some hierarchic data structure which tend to grow indefinitely, eating
up all the memory and crashing the program all the same, not caring
about if somebody defines them as leaks or not. Such offenders might be
even nicely destroyed at the program end, making it impossible to
discover at the program end. Been there, seen that.

Yes, you can instrument the memory allocation calls, and you can detect
leaks that way, but in large and complicated programs it would not be so
simple and not so easy (hint: a statistic analysis of allocations' size
distribution might appear useful).

[Ian Collins]

But when and where is the file closed? What happens if the object is
passed to more than one consumer?

--
Ian.

[wyn...@gmail.com]

Ian Collins於 2019年5月5日星期日 UTC+8上午9時05分20秒寫道：

Sorry, typo again! Those lines should be:

const char* fname="tmpfile";
My::RegFile regf(fname, O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
My::AtDestroy<My::Errno,const char*> rrad(My::unlink,fname);
...

A1: Good question (when and where is the file closed?)
When execution leaves the scope, dtor of rrad unlink the fname entry in OS.
File descriptor is closed by the dtor of regf. OS does the job correctly.

A2: I'm not quite sure what the 2nd question means exactly.
regf can be passed to another functions easily, by reference or by value
(throu copy ctor). "by move" would be another story.

rrad is meant to stay there, not to pass to any other stuff. The only
chance the name rrad is used is rrad.release(), like the old smart_ptr does

Now I can understand better. It might be the typo that caused confusion.

[Ian Collins]

On 05/05/2019 15:21, wyn...@gmail.com wrote:
> Ian Collins於 2019年5月5日星期日 UTC+8上午9時05分20秒寫道：
>> On 05/05/2019 01:59, wyn...@gmail.com wrote:
>>> Ian Collins於 2019年5月4日星期六 UTC+8上午7時42分20秒寫道：
>>>

>>> I guess what Scott said is similar to what I do currently, e.g.
>>>
>>> My::RegFile regf("tmpfile", O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
>>> My::AtDestroy<My::Errno,const char*> rrad(My::unlink,regf);
>>> ...
>>>
>>> Class AtDestroy collects info. needed to call resource release function
>>> (RRAD Resource Release At Destruction), which may be ::free(), delete,
>>> ::clost(int), ::freeaddrinfo, unlock...
>>> However, such usecase is not often encountered but necessary.
>>
>> But when and where is the file closed? What happens if the object is
>> passed to more than one consumer?
>

> Sorry, typo again! Those lines should be:
>
> const char* fname="tmpfile";
> My::RegFile regf(fname, O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
> My::AtDestroy<My::Errno,const char*> rrad(My::unlink,fname);
> ...
>
> A1: Good question (when and where is the file closed?)
> When execution leaves the scope, dtor of rrad unlink the fname entry in OS.
> File descriptor is closed by the dtor of regf. OS does the job correctly.

How is what you use better than having RegFile take care of the close?
What benefit is there in adding another class (which you may forget to
include) to do the job?

> A2: I'm not quite sure what the 2nd question means exactly.
> regf can be passed to another functions easily, by reference or by value
> (throu copy ctor). "by move" would be another story.
>
> rrad is meant to stay there, not to pass to any other stuff. The only
> chance the name rrad is used is rrad.release(), like the old smart_ptr does

Doesn't that limit the utility of RegFile? It it was responsible for
cleaning up, by adding reference counting it could be passed around, or
even stored in a container somewhere.

That is what RAII gives you.

--
Ian.

[peteolcott]

On 4/26/2019 7:48 AM, Stefan Ram wrote:
> wyn...@gmail.com writes:
>> Therefore, in this sense, I believe C++ rather deserve the word 'toy'
>> better (academic).
>
> C++ is the standard language when developing
> state-of-the-art computer games. A lot of software from
> Microsoft is built using recent flavors of Visual C++
> (including large parts of Windows and Office). At Adobe all
> major applications are developed in C++ as are several
> high-performance and high-reliability components at
> Facebook. GCC now uses C++ as its implementation language.
> Chromium (browser), Firefox, and MySQL and probably a lot of
> other well-known software items are written in C++
>
>

C++ is the best language where performance matters, when we take into account
This perspective:
https://fossbytes.com/linux-creator-linus-torvalds-c-programming-horrible/

--
Copyright 2019 Pete Olcott All rights reserved

"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein

[wyn...@gmail.com]

Ian Collins於 2019年5月5日星期日 UTC+8上午11時31分24秒寫道：

> On 05/05/2019 15:21, wyn...@gmail.com wrote:
> > Ian Collins於 2019年5月5日星期日 UTC+8上午9時05分20秒寫道：
> >> On 05/05/2019 01:59, wyn...@gmail.com wrote:
> >>> Ian Collins於 2019年5月4日星期六 UTC+8上午7時42分20秒寫道：
> >>>
> >>> I guess what Scott said is similar to what I do currently, e.g.
> >>>
> >>> My::RegFile regf("tmpfile", O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
> >>> My::AtDestroy<My::Errno,const char*> rrad(My::unlink,regf);
> >>> ...
> >>>
> >>> Class AtDestroy collects info. needed to call resource release function
> >>> (RRAD Resource Release At Destruction), which may be ::free(), delete,
> >>> ::clost(int), ::freeaddrinfo, unlock...
> >>> However, such usecase is not often encountered but necessary.
> >>
> >> But when and where is the file closed? What happens if the object is
> >> passed to more than one consumer?
> >
> > Sorry, typo again! Those lines should be:
> >
> > const char* fname="tmpfile";
> > My::RegFile regf(fname, O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
> > My::AtDestroy<My::Errno,const char*> rrad(My::unlink,fname);
> > ...
> >
> > A1: Good question (when and where is the file closed?)
> > When execution leaves the scope, dtor of rrad unlink the fname entry in OS.
> > File descriptor is closed by the dtor of regf. OS does the job correctly.
>
> How is what you use better than having RegFile take care of the close?

No idea what is meant.
I can only split your question into smaller chunks to understand

> What benefit is there in adding another class

What 'another' class did I add?

> (which you may forget to
> include) to do the job?
>

What file or class did I forget to include?

> > A2: I'm not quite sure what the 2nd question means exactly.
> > regf can be passed to another functions easily, by reference or by value
> > (throu copy ctor). "by move" would be another story.
> >
> > rrad is meant to stay there, not to pass to any other stuff. The only
> > chance the name rrad is used is rrad.release(), like the old smart_ptr does
>
> Doesn't that limit the utility of RegFile?

What is it that limited the utility of RegFile?

> It it was responsible for
> cleaning up, by adding reference counting it could be passed around, or
> even stored in a container somewhere.
>

...

> That is what RAII gives you.
>
> --
> Ian.

I'm glad to hear what exactly RAII is.

[Ian Collins]

Why can't RegFile do what AtDestroy is doing? RegFile should be able to
clean up after its self without the need of a helper class (AtDestroy).

>> What benefit is there in adding another class
>
> What 'another' class did I add?

AtDestroy

>> (which you may forget to
>> include) to do the job?
>>
>
> What file or class did I forget to include?

You could forget AtDestroy.

>>> A2: I'm not quite sure what the 2nd question means exactly.
>>> regf can be passed to another functions easily, by reference or by value
>>> (throu copy ctor). "by move" would be another story.
>>>
>>> rrad is meant to stay there, not to pass to any other stuff. The only
>>> chance the name rrad is used is rrad.release(), like the old smart_ptr does
>>
>> Doesn't that limit the utility of RegFile?
>
> What is it that limited the utility of RegFile?

You can't use it outside of the scope where it is created or share it
with another object or thread. Consider a case where you want to open a
bunch of file and store the the descriptors in a container for later use.

--
Ian.

[wyn...@gmail.com]

Ian Collins於 2019年5月5日星期日 UTC+8下午12時33分37秒寫道：

A RegFile instance is basically a file descriptor. The ctor may open/create
a file or dup from another instance. So, dtor does the opposite (close it).
If a file is created, ::close(int) does not remove the file.
...
I guess you were suggesting that if a file is created, the dtor could do
exactly the opposite thing (delete the file).
But, then, the class will contain two more data members, one of which
would contain file pathname(already difficult),... besides, cosiderations
include 1.RegFile is not alone, belonging to SysFile class family(common vptr)
2.How to implement the copy ctor? So, conclusion, not viable, too expensive.

> >> (which you may forget to
> >> include) to do the job?
> >>
> >
> > What file or class did I forget to include?
>
> You could forget AtDestroy.
>

I tried, but haven't come up with any alternative.

> >>> A2: I'm not quite sure what the 2nd question means exactly.
> >>> regf can be passed to another functions easily, by reference or by value
> >>> (throu copy ctor). "by move" would be another story.
> >>>
> >>> rrad is meant to stay there, not to pass to any other stuff. The only
> >>> chance the name rrad is used is rrad.release(), like the old smart_ptr does
> >>
> >> Doesn't that limit the utility of RegFile?
> >
> > What is it that limited the utility of RegFile?
>
> You can't use it outside of the scope where it is created or share it
> with another object or thread.

Can't figure out sensible meaning. Are you really Ian Collins?

> Consider a case where you want to open a
> bunch of file and store the the descriptors in a container for later use.
>
> --

I tried using std::vector, what you are more familiar with. And...?

std::vector<Wy::RegFile> farr{Wy::RegFile("abc",O_RDWR),
Wy::RegFile("efg",O_RDWR)};

[Jorgen Grahn]

On Fri, 2019-05-03, Melzzzzz wrote:

> On 2019-05-03, Jorgen Grahn <grahn...@snipabacken.se> wrote:
>> On Fri, 2019-05-03, Melzzzzz wrote:

...

>>> How do you solve leaks without sart pointers?
>>

>> YMMV, but I put my objects in containers, as part of other objects, or
>> as locals in functions. Code with is sprinkled with smart pointers
>> makes me suspicious -- IMO they should be used rarely.
>

> So you put objects by value everywhere?

I don't see exactly what you mean by "put" ... I typically pass them
by (const) reference, and have a rule "the callee may not keep hold of
such a reference forever".

I don't mind std::unique_ptr, but I distrust std::shared_ptr. I want
to know when my objects are destroyed, without analyzing the whole
program. I want object lifetimes to be /designed/.

(This does not mean I'd never use shared pointers under any
circumstances; they're just not one of my main tools.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Fri, 2019-05-03, Ian Collins wrote:

> On 04/05/2019 07:46, Jorgen Grahn wrote:
>> On Fri, 2019-05-03, Melzzzzz wrote:
...
>>> How do you solve leaks without sart pointers?
>>
>> YMMV, but I put my objects in containers, as part of other objects, or
>> as locals in functions. Code with is sprinkled with smart pointers
>> makes me suspicious -- IMO they should be used rarely.
>

> The code base I'm currently working in uses them a lot simply because it
> is event driven and passes shared messages between threads.

That sounds like a valid use case, especially if you have a smart
pointer template dedicated for that use case.

[Ian Collins]

On 05/05/2019 18:55, wyn...@gmail.com wrote:
>>>
>>> No idea what is meant.

Because I misunderstood what you wrote, my questions made no sense, sorry..

--
Ian

[Scott Lurndal]

CFront, indeed. C with classes. Looked pretty :-)

[Manfred]

On 5/5/2019 6:14 AM, wyn...@gmail.com wrote:
> Ian Collins於 2019年5月5日星期日 UTC+8上午11時31分24秒寫道：
>> On 05/05/2019 15:21, wyn...@gmail.com wrote:
>>> Ian Collins於 2019年5月5日星期日 UTC+8上午9時05分20秒寫道：
>>>> On 05/05/2019 01:59, wyn...@gmail.com wrote:
>>>>> Ian Collins於 2019年5月4日星期六 UTC+8上午7時42分20秒寫道：
>>>>>
>>>>> I guess what Scott said is similar to what I do currently, e.g.
>>>>>
>>>>> My::RegFile regf("tmpfile", O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
>>>>> My::AtDestroy<My::Errno,const char*> rrad(My::unlink,regf);
>>>>> ...
>>>>>
>>>>> Class AtDestroy collects info. needed to call resource release function
>>>>> (RRAD Resource Release At Destruction), which may be ::free(), delete,
>>>>> ::clost(int), ::freeaddrinfo, unlock...
>>>>> However, such usecase is not often encountered but necessary.
>>>>
>>>> But when and where is the file closed? What happens if the object is
>>>> passed to more than one consumer?
>>>
>>> Sorry, typo again! Those lines should be:
>>>
>>> const char* fname="tmpfile";
>>> My::RegFile regf(fname, O_CREAT|O_TRUNC|O_RDWR, S_IRUSR|S_IWUSR);
>>> My::AtDestroy<My::Errno,const char*> rrad(My::unlink,fname);
>>> ...

I was also confusing destruction with closing, but after your
clarification I believe you have a problem here: standard C++ rules
destroy objects in LIFO order, so the dtor of rrad is executed before
the one of regf, which means that regf ends up close()ing an unlink()ed
file (and rrad unlink()s an open file).

I can't say how practically relevant the consequences may be (it depends
on the implementation of close()), but it looks like it is not what is
intended to happen.

[Thiago Adams]

On Sunday, May 5, 2019 at 1:05:58 AM UTC-3, peteolcott wrote:
> On 4/26/2019 7:48 AM, Stefan Ram wrote:
> > writes:
> >> Therefore, in this sense, I believe C++ rather deserve the word 'toy'
> >> better (academic).
> >
> > C++ is the standard language when developing
> > state-of-the-art computer games. A lot of software from
> > Microsoft is built using recent flavors of Visual C++
> > (including large parts of Windows and Office). At Adobe all
> > major applications are developed in C++ as are several
> > high-performance and high-reliability components at
> > Facebook. GCC now uses C++ as its implementation language.
> > Chromium (browser), Firefox, and MySQL and probably a lot of
> > other well-known software items are written in C++
> >
> >
>
> C++ is the best language where performance matters, when we take into account
> This perspective:
> https://fossbytes.com/linux-creator-linus-torvalds-c-programming-horrible/

I cannot understand what you said because the link says the opposite.
(Some kind of irony?)

[Richard]

[Please do not mail me a copy of your followup]

sl...@pacbell.net spake the secret code
<V61zE.288$fq3...@fx07.iad> thusly:

>[...] Granted, one needs to hire

>capable programmers, but that's not been a problem, just requires due
>diligence.

If that's your attitude, you might as well program in assembly. After
all, it's just a matter of due diligence in getting it right.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

[wyn...@gmail.com]

Manfred於 2019年5月6日星期一 UTC+8下午8時05分08秒寫道：

See https://linux.die.net/man/2/unlink
The results is as what I intended. You can put codes between the two
lines that create regf and rrad to verify correctness.

In general cases, regular files (or other kind of devices) should call
::close "explicitly" for the return status. This is where most people
failed to do. In not few cases, the return status of ::unlink should
as well be checked. This error checking issue implies a lot..., better
not to say now.

[Scott Lurndal]

legaliz...@mail.xmission.com (Richard) writes:
>[Please do not mail me a copy of your followup]
>
>sl...@pacbell.net spake the secret code
><V61zE.288$fq3...@fx07.iad> thusly:
>
>>[...] Granted, one needs to hire
>>capable programmers, but that's not been a problem, just requires due
>>diligence.
>
>If that's your attitude, you might as well program in assembly. After
>all, it's just a matter of due diligence in getting it right.

Argumentum ad absurdum noted.

[Vir Campestris]

On 06/05/2019 17:53, wyn...@gmail.com wrote:
> In general cases, regular files (or other kind of devices) should call
> ::close "explicitly" for the return status. This is where most people
> failed to do. In not few cases, the return status of ::unlink should
> as well be checked. This error checking issue implies a lot..., better
> not to say now.

It's interesting but my limited Linux experience (only ~5 years)
suggests it isn't worth checking the return code. It just cleans up a
handle, leaving your data in cache to be written at some future time.

Windows, OTOH, flushes the file to disc before returning from the close.
It's _very_ worth checking it there.

Andy

[wyn...@gmail.com]

Vir Campestris於 2019年5月7日星期二 UTC+8上午4時20分43秒寫道：

There are a list of possibilities things can go wrong.
See http://man7.org/linux/man-pages/man2/close.2.html
https://linux.die.net/man/3/close

Error checking codes may seem unworthy while coding or 'analysing'
When compiled executables are delivered to some unknown person
things can turn drastically different.

[Jorgen Grahn]

On Fri, 2019-05-03, Ian Collins wrote:

>>>> two decades. That's obviously not true. Granted, one needs to hire

>>>> capable programmers, but that's not been a problem, just requires due
>>>> diligence.
>>>

>>> "Crutches" such a smart pointers have been a feature of C++ since the
>>> beginning because RAII has been a feature of C++ since the beginning.
>>> RAII is one of C++'s core design features and greatest strengths.
>>
>> I beg your pardon. I wasn't aware that smart pointers were part of C++
>> back in 1989 when we used a language called C++ to write an operating system
>> for a massively parallel processing system called OPUS.
>

> Smart pointers have been part of C++ programming since C++ had automatic
> object destruction; which it always has. I may not have been using C++
> in 1989 (I didn't start until around 1990) but one of the features that
> attracted me from C to C++ was the ability to manage memory and other
> resources with objects.
>

>> Surely you don't need smart pointers to implement RAII; we had a rather clever (at the time)
>> use in that Operating System of a struct with a destructor that was used to track
>> resource allocation during processing of a 'fork' system call - if we needed to
>> bail from the fork prematurely (due to resource unavailability or permissions issues)
>> simply returning from the fork function caused the destructor to run which cleaned up
>> the partially allocated new process as it automatically ran the destructor for the local stack
>> instance of the cleanup class.
>
> You got it backwards, smart pointers are an example of RAII. They could
> be described as the canonical example of RAII.

I think this discussion may be missing the point.

- std::shared_ptr is RAII, but you delay the decision about when the object
is destroyed. You may not know or care exactly when.

- The other way to use RAII is to be up-front about it. You know exactly
when the object is destroyed, and need to design your code so noone still
has a reference to it afterwards.

It's two ways to deal with ownership. I'm personally kind of with
Lurndal; I prefer up-front ownership whenever possible.

I've worked with code where pretty much every has-a relationship goes
through std::shared_ptr, and I found that painful and Java-like. I've
only seen that in one project, though, and I don't think that's what
people are advocating here.

>> Even then, allocate in constructor, deallocate in destructor works just fine
>> without smart pointers.
>
> Which is exactly what a smart pointer does, so I don't see your point.

[Ian Collins]

On 08/05/2019 00:57, Jorgen Grahn wrote:
> On Fri, 2019-05-03, Ian Collins wrote:
>> On 04/05/2019 10:36, Scott Lurndal wrote:

>>> Surely you don't need smart pointers to implement RAII; we had a rather clever (at the time)
>>> use in that Operating System of a struct with a destructor that was used to track
>>> resource allocation during processing of a 'fork' system call - if we needed to
>>> bail from the fork prematurely (due to resource unavailability or permissions issues)
>>> simply returning from the fork function caused the destructor to run which cleaned up
>>> the partially allocated new process as it automatically ran the destructor for the local stack
>>> instance of the cleanup class.
>>
>> You got it backwards, smart pointers are an example of RAII. They could
>> be described as the canonical example of RAII.
>
> I think this discussion may be missing the point.
>
> - std::shared_ptr is RAII, but you delay the decision about when the object
> is destroyed. You may not know or care exactly when.
>
> - The other way to use RAII is to be up-front about it. You know exactly
> when the object is destroyed, and need to design your code so noone still
> has a reference to it afterwards.
>
> It's two ways to deal with ownership. I'm personally kind of with
> Lurndal; I prefer up-front ownership whenever possible.

In that case, use a unique_ptr. I always tell people to carefully
consider whether shared_ptr is appropriate and to consider the hidden
costs of using one.

> I've worked with code where pretty much every has-a relationship goes
> through std::shared_ptr, and I found that painful and Java-like. I've
> only seen that in one project, though, and I don't think that's what
> people are advocating here.

Indeed not!

--
Ian.

[Richard]

[Please do not mail me a copy of your followup]

Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
<slrnqd305a.1s...@frailea.sa.invalid> thusly:

>I've worked with code where pretty much every has-a relationship goes
>through std::shared_ptr, and I found that painful and Java-like.

In my experience, this is a sign that the designer didn't think about
who really owns things, so it devolved into a sort of "everyone owns
it and noone owns it" way of thinking which is just sloppy IMO.

[Jorgen Grahn]

On Tue, 2019-05-07, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jorgen Grahn <grahn...@snipabacken.se> spake the secret code
> <slrnqd305a.1s...@frailea.sa.invalid> thusly:
>
>>I've worked with code where pretty much every has-a relationship goes
>>through std::shared_ptr, and I found that painful and Java-like.
>
> In my experience, this is a sign that the designer didn't think about
> who really owns things, so it devolved into a sort of "everyone owns
> it and noone owns it" way of thinking

"The tragedy of the commons." This was indeed was the current
generation of developers noted.

> which is just sloppy IMO.

Maybe not always so much sloppiness as a wish to have one less thing
to think about. And not valuing ownership as a design tool.