lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Gé:

On Tue, Jun 30, 2020 at 9:34 PM Gé Weijers <ge@weijers.org> wrote:
> I agree that if you use C++'s smart pointers and the related mechanisms correctly you will easily avoid space leaks,

resource leaks in general, if by space you mean memory, this is easier
with GC ( althoug a bit costlier ( in memory demand, not time ) in
most scenarios ).

> but I see a lot of code written by programmers that have a few years of experience and they do NOT consistently use these tools correctly.

Ah! C++, a year to learn a lifetime to master ( not yet proven, not an
old enough language, maybe more, YMMV ).

Everybody makes mistakes, and, besides, I've seen many programmers
with more than a decade of experience and a total disregard for
correct long term code. I would not trust many of them for programs
with multi-year runtimes like I have, you need a certain approach to
coding besides the experience.

> The language also has too many little gotchas. I would hesitate to use it for a new large project, because it's too hard to get a team of experienced C++ coders.

It's hard, but for some things it is the easier thing. I recently did
some couple of months project which needed some combinations of
multithreading, raw speed, memory demands and external library usage
which was easy in C++(14), but would have been a nightmare to do in
luajit or C, too memory hungry in Lua or any similar scripting
language, too difficult to code in Java. Maybe swift/rust/go or some
of those new ones would have done it, but I've been doing C++ for more
than 30 years, and the modern ones are a delight. I doubt I could have
coded it in less lines in lua, much less debug it as fast. Exceptions
were used sparingly ( I only got two possible severe error conditions,
one was out of memory ).

It's got a lot. But I've seen it described as rocket fuel, messy,
toxic, dirty, dangerous, difficult to handle, but sometimes you need
to use it.

> One issue that remains is that it's very hard to reason about the program state in a formal or semi-formal way once you add exceptions to the mix. You catch the exception, but your data structure's invariants are no longer valid. This is of course not specific to C++.

On this, RAII, GC or whatever, if you code correctly your data
structures should be correct. You have a try/whatever and when the
block is done your data should be in a defined state ( some can be in
a safe but undetermined state, but this should be documented ). Given
you can do the same as exceptions with a somehow more cumbersome
combination of non exception code, I do not think it is more difficult
to reason.

Of course, exceptions makes it easier to write apparently safe code,
or easy-looking complex code, but any competent programmer can write
unreasonably hard to reason about code.


Francisco Olarte.