Wednesday, July 11, 2018

Digest for comp.lang.c++@googlegroups.com - 10 updates in 3 topics

Ian Collins <ian-news@hotmail.com>: Jul 12 08:43AM +1200


>> Do I? That's good to know.
 
> Well perhaps you don't if you're just writing mickey mouse code. Some of us
> have had to however.
 
Ha, so that's what I do. Very insightful.
 
--
Ian.
Paavo Helde <myfirstname@osa.pri.ee>: Jul 11 11:46PM +0300

On 11.07.2018 20:41, Bart wrote:
> table, and an expanding byte buffer. If I was to bring in some of those
> heavyweight container types you get with C++, they would probably grind
> to a halt.)
 
So you are saying your systems have troubles with common data structures
which have been in wide use for tens of years - what conclusions we
should draw from this?
 
> understand the default copy to be, may not be sufficient. Or sometimes
> it will, and sometimes it won't; it depends! Maybe xx=yy will copy the
> pointers but also needs to set something inside *yy.
 
In C++ you objects of RAII objects into the class. RAII objects like
std::vector or std::shared_ptr know how to copy themselves, no problem.
In general, one should not put raw pointers into a class, especially if
they own resources, for the reasons you just listed.
 
The implementation of the low-level classes like std::vector and
std::shared_ptr is more complicated and needs custom constructors,
assignment operators and destructors. Luckily, this work has been done
in the standard library to a large extent already. But if you need more
flexibility you can always define new low-level RAII classes.
bitrex <user@example.net>: Jul 11 05:23PM -0400


> Similarly with your code - you write code to impress and use as much cutting
> edge syntax as you can because its there, not because its appropriate or would
> be maintainable in the wild. Syntax for its own sake.
 
it's perfectly understandable there's no mystery to it you're just not
familiar with modern C++. it is what it is. Stop whining
bitrex <user@example.net>: Jul 11 05:29PM -0400

On 07/10/2018 08:37 AM, Alf P. Steinbach wrote:
> vote to close, to get this to them affronting nonsense out of the way.
 
> Cheers!,
 
> - Alf (social focus mode)
 
I invite the "syntactic masturbation" crowd to look at this snipped of
Erlang and explain how this works on first examination:
 
<https://csdl-images.computer.org/mags/ic/2007/05/figures/w50901.gif>
 
that's it though. That's the language, sorry. If you don't like it and
think it's obtuse then GTFO write basic or something.
bitrex <user@example.net>: Jul 11 05:39PM -0400

On 07/10/2018 08:37 AM, Alf P. Steinbach wrote:
> that one is disqualified is a purely associative one, idiotic IMHO,
> although it must be said that that argument often /works/, when it
> appeals to authority in a direction that the herd has experience with.
 
The joke-variant is that you don't need to be a master chef to know bad
food when you taste it.
 
But "appeal to authority" has to be a valid tactic sometimes because an
"authority" whose opinions are never more useful or informed than the
average person is not actually an authority in anything.
 
The reason "appeals to authority" often fall flat is that the appeal is
usually to the wrong authority, and in the US at least there are no
shortage of authorities in, generously, one or two topics who feel that
their credentials in those one or two topics give them authority to
speak with more authority than any layman, in any topic at all.
Bart <bc@freeuk.com>: Jul 11 10:59PM +0100

On 11/07/2018 21:46, Paavo Helde wrote:
 
> So you are saying your systems have troubles with common data structures
> which have been in wide use for tens of years - what conclusions we
> should draw from this?
 
No trouble, just that I found them unnecessary. Those programs I write
are very fast by taking some care with design rather than doing anything
sophisticated. The main data structure is a singly-linked list - using a
raw pointer. And most searches are sequential.
 
> std::vector or std::shared_ptr know how to copy themselves, no problem.
> In general, one should not put raw pointers into a class, especially if
> they own resources, for the reasons you just listed.
 
At a certain level of language it's not something that you want to
unduly worry about. And it seems that with C++ there are is a lot /more/
to keep in mind.
 
I tend to code either at the C level where I'm using simple data
structures, or a couple of levels up using dynamic code which makes a
lot of this stuff painless to use (you rarely use pointers at all for
example).
 
So it is interesting to observe how it works between those two points
with C++. The only thing I might envy is to be able to use sophisticated
data handling but also have it fast (dynamic code is slow).
 
> assignment operators and destructors. Luckily, this work has been done
> in the standard library to a large extent already. But if you need more
> flexibility you can always define new low-level RAII classes.
 
That's the last thing I'd want to do when writing applications. I tend
to adopt the KISS principle. (I do know what RAII stands for; what it
means is another matter and another thing to worry about that I don't need.)
 
 
--
bart
Bart <bc@freeuk.com>: Jul 11 11:12PM +0100

On 11/07/2018 18:49, Stefan Ram wrote:
>> picture. That is far less likely with C++.
 
> You don't need to understand C++ code at the low level
> because you can understand it at the high level.
 
I have from time to time needed to convert algorithms from one language
to another (usually one of mine).
 
When that original language is C, that offers enough problems of its own
(what with over-enthusiastic use of the macro system and such).
 
With C++ however, that takes the difficulties to a whole new level.
 
Also, even when I don't want to understand the source code or translate
it, but just use the program as an already compiled library [from my
language], then with C I can eventually manage to use such a library,
given docs and an interface usually as a .h C header file.
 
But when an interface is specified in C++ code, then forget it! (I was
never able to use APIs such as GDI+ or DirectDraw for those reasons.)
 
--
bart
woodbrian77@gmail.com: Jul 11 04:02PM -0700

On Wednesday, July 11, 2018 at 3:46:25 PM UTC-5, Paavo Helde wrote:
> std::vector or std::shared_ptr know how to copy themselves, no problem.
> In general, one should not put raw pointers into a class, especially if
> they own resources, for the reasons you just listed.
 
I disagree with that. There's a BufferCompressed type here:
https://github.com/Ebenezer-group/onwards/blob/master/Buffer.hh
 
,around line 509, that has several owning raw pointers. This
post by Howard Hinnant:
https://stackoverflow.com/questions/38780596/how-to-handle-constructors-that-must-acquire-multiple-resources-in-an-exception#38780597
 
was helpful to me.
 
 
Brian
Ebenezer Enterprises - Enjoying programming again.
http://webEbenezer.net
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Jul 11 01:28PM -0700

On 7/11/2018 2:57 AM, Anton Shepelev wrote:
>> This is Terry. Seems like a very odd demented thing.
 
> The OS in very interesting regardless of the author:
> http://www.codersnotes.com/notes/a-constructive-look-at-templeos/
 
Agreed. One part I do not quite understand is why the author seemed to
stick artificial limitations in the OS. Something about not making it
attractive for mass use wrt "prevent commercialization and corruption."
 
Here is another quote from:
 
from:
https://www.reddit.com/r/programming/comments/5s7wu4/templeos_red_sea_file_system_and_block_chains
 
"
[...]
I am intentionally crippling this operating system, making it a toy with
the wisdom that this will prevent commercialization and corruption.
[...]
"
 
That aside for a moment, I like the custom file system: RedSea. It is
interesting...
 
Another quote:
"
[...]
Doing whole file operations is the TempleOS way of doing thinks. It is
the simplest and, ironically, the fastest. It is obnoxious in the
characteristic way that TempleOS is obnoxious, flaunting massive modern
resources in a way that makes old programmers protest.
 
Doing whole file operations will sabotage efforts to change the 640x480
resolution and violate the ban on multimedia. When doing large,
whole-file operations, immediately memory fragmentation is a serious
problem, but not so for allocations in the range under a Meg (with
occasional larger ones).
[...]
"
 
TempleOS is _obnoxious_ is just strange to me. Well, at least he seems
to support FAT32. Iirc, I read that TempleOS can use FAT32 and/or RedSea?
ram@zedat.fu-berlin.de (Stefan Ram): Jul 11 05:49PM

>At least, you can understand such C code at the low-level, as a bunch of
>structs and arrays and function calls, even if you don't get the big
>picture. That is far less likely with C++.
 
You don't need to understand C++ code at the low level
because you can understand it at the high level.
 
C++ has several container type with a many algorithms. In C
all of this would have to be implemented (like Jacob did).
 
>How would x = y work? How about xx = yy?
 
Depends on why you would want to do this.
Depends on the purpose the class is intended for.
For some classes, it's appropriate to forbid
copying (you can't copy ::std::cout or an atomic_int,
IIRC) alltogether for another example.
 
(The NIH class library which provided deep and shallow copy
functions. But today we do not seem to miss them.)
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)