Wednesday, March 30, 2016

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

Geoff <geoff@invalid.invalid>: Mar 29 05:09PM -0700

On Tue, 29 Mar 2016 18:36:05 +0200, Paavo Helde
 
>> What are the advantages/disadvantages?
 
>If it works and there is no need to add features or change
>functionality, then there is not much reason to convert anything.
 
It works very well and there are no features to add.
 
 
>With std::vector, sorting and removing would then become:
 
> std::sort(Tx.begin(), Tx.end());
> Tx.resize(newsize);
 
This would be most likely, since access speed to the array is critical
to the speed of the computations.
 
> - no arbitrary limit of 1000 elements
> - no fear of buffer overrun
> - no need to track the actual size in a separate variable
 
These reasons we in my mind while considering the question.
 
>pointers to them.
> - serialization needs to be rewritten a bit to work without the
>terminator.
 
The 1000 limit was chosen to limit the study. As it stands, a 1000 x
1000 array can take dozens of hours to compute all the products on a
modern platform. Back when this was written, a 400MHz i486 was a fast
machine and it would take several days.
 
>address is important) or you need things like splice. In this usage
>scenario I do not see any need to use std::list, it would just combine
>the worst properties of std::vector and std::set (for this scenario).
 
I think I'd have to test and measure the speeds of analysis of an
array compared with a std::vector before committing to it.
 
Thank you for your well-considered reply.
Juha Nieminen <nospam@thanks.invalid>: Mar 30 06:19AM

> std::set in my codebase: not all lists need to be ordered.
 
> Just because YOU are unfamiliar with the common use-cases for std::list
> does not mean that std::list is redundant.
 
I am perfectly aware of how linked lists work, and what their advantages
and disadvantages are.
 
Yet, I have not used std::list since forever, for the simple reason that
I have never needed it. I remember using it in one serious project for
university, where it was actually necessary (the algorithm in question was
explicitly designed to work with fast splicing of linked lists). But
that's about it.
 
The problem with std::list is that it consumes more memory, adding
elements to it is slower (because memory allocation is slow), and it
easily gets fragmented in memory, potentially adding to the slowness
of even element access. (This slowness does not technically speaking
affect its asymptotic complexity, but slowness is slowness.)
 
Perhaps you are too reliant on pointers/iterators all over the place,
outliving their creation scope?
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Juha Nieminen <nospam@thanks.invalid>: Mar 30 06:22AM

> std::deque also makes O(n) memory allocations like std::list and
> std::set so you clearly do not know what you are talking about.
 
But std::deque makes n/x memory allocations while std::list makes n.
That makes a big difference in efficiency.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
"Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Mar 30 09:58AM +0200

Am 28.03.2016 um 22:12 schrieb Geoff:
>>>>> On Sun, 2016-03-27, Heinz-Mario Frühbeis wrote:
>>>>>> Am 27.03.2016 um 15:03 schrieb Alf P. Steinbach:
>>>>>>> On 27.03.2016 11:17, Heinz-Mario Frühbeis wrote:
 
[...]
> cout.flush();
> return 0;
> }
 
std::string (of its own; not c_str) is *not thread safe...
Yes, you can store a member var as std::string, but e.g. within a
callback function e.g. from a loop which is runnnung in a pthread, you
can only use c_str, also *not length(). Else, undef behaviour, or even
crash...
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Mar 30 11:20AM +0200

On 30.03.2016 09:58, Heinz-Mario Frühbeis wrote:
> callback function e.g. from a loop which is runnnung in a pthread, you
> can only use c_str, also *not length(). Else, undef behaviour, or even
> crash...
 
I'm sorry, that's bollocks. The threading issues are the same with
`std::string` as with C style strings. If some code is unsafe with the
former, then its unsafe with the latter, and vice versa, except that its
easier to introduce bugs with C style strings.
 
Cheers & hth.,
 
- Alf
"Heinz-Mario Frühbeis" <Div@Earlybite.individcore.de>: Mar 30 01:09PM +0200

Am 30.03.2016 um 11:20 schrieb Alf P. Steinbach:
> former, then its unsafe with the latter, and vice versa, except that its
> easier to introduce bugs with C style strings.
 
> Cheers & hth.,
 
Here, I have a XLib-Event-Loop running in a pthread and *every access on
std::string in a callback-function from this loop results in an error,
except I'm using c_str!
 
E.g.:
std::string string_var;
if(string_var.length() > 0){ // ERROR
}
if(strlen(string_var.c_str) > 0){ // NO ERROR
}
 
if(string_var == "HALLO"() > 0){ // ERROR
}
if(string_var.c_str == "HALLO"){ // NO ERROR
}
 
To me, it seems to be the same behaviour like XLib has...
 
Regards
Heinz-Mario Frühbeis
"Öö Tiib" <ootiib@hot.ee>: Mar 30 04:31AM -0700

On Wednesday, 30 March 2016 10:59:04 UTC+3, Heinz-Mario Frühbeis wrote:
> callback function e.g. from a loop which is runnnung in a pthread, you
> can only use c_str, also *not length(). Else, undef behaviour, or even
> crash...
 
You seem to claim that 'char' array is more thread safe than 'std::string'.
That is dangerous nonsense. Only very few things that are immutable
whole program run are thread safe (constexpr, static const and string
literals). In C++ it is *possible* to make rest of things thread safe.
However that is it. Read up on C++ memory model.
"Öö Tiib" <ootiib@hot.ee>: Mar 30 04:35AM -0700

On Wednesday, 30 March 2016 14:09:38 UTC+3, Heinz-Mario Frühbeis wrote:
> if(string_var.c_str == "HALLO"){ // NO ERROR
> }
 
> To me, it seems to be the same behaviour like XLib has...
 
Huh? What you now posted should not compile in C++.
It seems full of strange syntax errors.
There must be no way to run it. Stop the nonsense, please.
Mr Flibble <flibble@i42.co.uk>: Mar 30 03:38PM +0100

On 30/03/2016 07:22, Juha Nieminen wrote:
>> std::set so you clearly do not know what you are talking about.
 
> But std::deque makes n/x memory allocations while std::list makes n.
> That makes a big difference in efficiency.
 
x is a constant though so it makes no difference as far as algorithmic
"efficiency" (complexity) is concerned.
 
/Flibble
Mr Flibble <flibble@i42.co.uk>: Mar 30 03:42PM +0100

On 30/03/2016 07:19, Juha Nieminen wrote:
> university, where it was actually necessary (the algorithm in question was
> explicitly designed to work with fast splicing of linked lists). But
> that's about it.
 
If you have only used std::list once in your entire career then it is
painfully obvious that you are not aware of (or stubbornly ignore) its
advantages.
 
> easily gets fragmented in memory, potentially adding to the slowness
> of even element access. (This slowness does not technically speaking
> affect its asymptotic complexity, but slowness is slowness.)
 
std::set, std::multiset, std::map and std::multimap also have a single
node based allocation strategy so are you suggesting we shouldn't use
these containers either as they are "slow"? Besides, the allocation
problems of which you speak can be mostly mitigated against through the
use of a custom allocator such as one of the Boost pool allocators which
should, IMO, be part of C++.
 
 
> Perhaps you are too reliant on pointers/iterators all over the place,
> outliving their creation scope?
 
No more than I should be.
 
/Flibble
Geoff <geoff@invalid.invalid>: Mar 30 08:25AM -0700

On Wed, 30 Mar 2016 09:58:54 +0200, Heinz-Mario Frühbeis
>callback function e.g. from a loop which is runnnung in a pthread, you
>can only use c_str, also *not length(). Else, undef behaviour, or even
>crash...
 
If you are using memmove or strlen without obtaining appropriate locks
then you are not thread safe. It makes no difference if you are using
the c_str member or not, you are still accessing the same object and
if you don't own the lock on it you are not thread safe. Your
experiment is flawed and your statement above is incorrect.
 
Thread safety is YOUR problem, not the functions and not the objects
(necessarily). You asked about string manipulation and splitting and
presented non-threaded C code. I showed you an example of a
non-threaded C++ way to do it. Thread safety is a separate issue.
 
Since you were copying a const char *nString, I assumed you knew where
it was coming from and would obtain the lock on that string before
copying it to the local mutable string for manipulation.
woodbrian77@gmail.com: Mar 30 10:51AM -0700

On Wednesday, March 30, 2016 at 9:42:45 AM UTC-5, Mr Flibble wrote:
 
> If you have only used std::list once in your entire career then it is
> painfully obvious that you are not aware of (or stubbornly ignore) its
> advantages.
 
Whatever.
 
> problems of which you speak can be mostly mitigated against through the
> use of a custom allocator such as one of the Boost pool allocators which
> should, IMO, be part of C++.
 
There's junk in the standard that should be removed and
there are some things that should have been added years
ago. The standard adds "any" but what about something
useful like pool allocators? Leave out the good stuff and
throw in some junk. More about this after the next paragraph.
 
Chandler Carruth gave a talk a few years ago about data
structures and performance. He said he despises std::map.
I agree with that.
 
Maybe this is like a Scooby Doo cartoon where a group
of friends is out playing and they run into a crook.
They put the pieces of the puzzle together and they
eventually catch up to the crook and take off his
mask. Then they are stunned to realize it's someone
they thought they knew. I think Chandler, Andrei A.
Bjarne S. and myself are some of the good guys. I have
hope for people here to go in the right path also,
but it's not clear yet to me what they will do. I
understand Andrei A.'s effort to be a trailblazer. If
that doesn't work out, I hope he will come back to C++.
I could name some people I think are suspect, but am not
sure that would help.
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
legalize+jeeves@mail.xmission.com (Richard): Mar 30 01:11AM

[Please do not mail me a copy of your followup]
 
Christopher Pisz <nospam@notanaddress.com> spake the secret code
>the interpreter exists, but that's what 3 or 4 platforms? There are
>probably thousands if not millions of pieces of hardware out there that
>utilize C++.
 
I always chuckle when I install the Java runtime and it shouts "3
billion devices run Java!". The number for C++ is probably something
like 300 billion, but because there is no "C++ SDK" or "C++ Virtual
Machine" from a single company that you have to install, there isn't
any shouting from the rooftops how ubiquitous C++ is in modern
computing.
 
Where does C++ run? Everywhere.
 
What runs C++? Everything.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Johann Klammer <klammerj@NOSPAM.a1.net>: Mar 30 09:22AM +0200

On 03/29/2016 10:27 PM, Christopher Pisz wrote:
> Does there exist a list of operating systems/hardware that I can target in C++?
 
> My office mate is arguing with me that C# is now more portable than C++, because...mono. He is making me angry.
 
Isn't mono another one of those platforms that emulate a non-existent architecture and
the emulator runs only on a very small subset of actually existing architectures?
(like java?)
Marcel Mueller <news.5.maazl@spamgourmet.org>: Mar 30 01:11PM +0200

On 30.03.16 09.22, Johann Klammer wrote:
 
> Isn't mono another one of those platforms that emulate a non-existent architecture and
> the emulator runs only on a very small subset of actually existing architectures?
> (like java?)
 
Mono and Java are essentially the same. Only the ecosystem around them
is quite different. Most sufficiently powerful computer can deal with
both of them.
However, if you talk about "existing architectures" and include embedded
devices, you are right. This will not work mostly. Just because the VMs
are too bulky - for now...
 
Btw. neither the Mono nor the Java VM emulates any hardware. They are
just JIT platforms where the compiler to assembly language always runs
on the target platform. So the binaries are only an intermediate
language. The important advantage is that this binaries are /not/
platform dependent and, of course, the compiler can use hardware
specific optimization which are impossible when you deliver executables
for a series of platforms like x86 or arm64.
 
The result is similar than distributing your C++ application as source
code. But without all the drawbacks of compile time source code
incompatibilities and so on.
Of course the intermediate language (or Java Byte Code) is the least
common denominator. You can't do any hacks that won't fit into this
standard (mostly platform specific hacks).
 
If you look how gcc internally works it does basically the same. It
parses the C++ code into formal execution trees (to some degree
comparable to the Mono IL) and in the second stage the machine code for
the target platform is generated. This is part of the success story of
gcc. If a new language feature is required you only change the first
stage (mostly), then the feature is available on all platforms. If you
port gcc to a new platform you only implement the second stage, and you
get all the language features. AFAIK LLVM works similar (as the name
suggests).
 
Btw.: the concept of the Transmeta CPUs is similar too. It morphs the
code into platform specific RISC code. The coffin nail was that they
used the (horrible) x86 instruction set as intermediate language.
All modern x64 CPUs operate similar, but they do not write the result
back into memory because the decoder stages are realized in hardware and
operate on the fly.
 
Btw.2: I am quite sure, as long as C++ code do not use the ugly (and
often platform dependent) reinterpret casts, it could be compiled into
intermediate language too. But probably there is no much existing C++
application around that satisfies this restriction.
 
 
Marcel
Bo Persson <bop@gmb.dk>: Mar 30 07:07PM +0200

On 2016-03-30 13:11, Marcel Mueller wrote:
> platform dependent and, of course, the compiler can use hardware
> specific optimization which are impossible when you deliver executables
> for a series of platforms like x86 or arm64.
 
The supposed JIT advantage really isn't any advantage at all, as a C++
compiler can produce code for any specific system of its choice.
 
For example, gcc has TONS of options specifically for doing that:
 
https://gcc.gnu.org/onlinedocs/gcc/Submodel-Options.html#Submodel-Options
 
 
So, to have optimal performance you either download an executable
specifically optimized for your system, or a JVM with specific
optimizations for your system.
 
Big deal! :-)
 
 
Bo Persson
Wouter van Ooijen <wouter@voti.nl>: Mar 30 07:13PM +0200

Op 30-Mar-16 om 7:07 PM schreef Bo Persson:
> specifically optimized for your system, or a JVM with specific
> optimizations for your system.
 
> Big deal! :-)
 
The deal is that in order to be able to dowload a version of the app
specific for your system such a version must exits. For N apps and M
systems that means N * M executables.
 
For the JIT version it requires N 'executables' + M JIT compilers.
 
Wouuter van Ooijen
(A big C++ fan, but also a big Python user)
jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 03:03PM +0200

https://github.com/jacob-navia/ccl.git
 
There you will find all the source code and the source code of the
dopcumentation in TeX form (the only word processor of the 80es that is
still running today and will run in 2030)
 
The C Containers library is a replica of the STL written in plain C.
 
jacob
scott@slp53.sl.home (Scott Lurndal): Mar 30 03:11PM


>There you will find all the source code and the source code of the
>dopcumentation in TeX form (the only word processor of the 80es that is
>still running today and will run in 2030)
 
troff is a word processor of
the 70's that is still running today, and will continue to
run through 2030, and is still the foundation of manual pages
on unix/linux systems.
 
If you are documenting source code, then you should at minimum
provide doxygen comments in the source.
Randy Howard <rhoward.mx@EverybodyUsesIt.com>: Mar 30 10:30AM -0500

On 3/30/16 8:03 AM, jacobnavia wrote:
 
> There you will find all the source code and the source code of the
> dopcumentation in TeX form (the only word processor of the 80es that is
> still running today and will run in 2030)
 
Is "dopcumentation" an artifact of an archaic word processor? ;-)
 
Btw, I'm completely convinced that other word processors from that era
are still running today and will still be runnable in 2030. But don't
let that get in the way of grinding the axe for your favorite one.
 
> The C Containers library is a replica of the STL written in plain C.
 
Thanks for the warning.
 
Out of curiosity, is it really written in plain C, or that 'almost C'
flavor you like?
 
 
--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)
Randy Howard <rhoward.mx@EverybodyUsesIt.com>: Mar 30 10:33AM -0500

On 3/30/16 10:11 AM, Scott Lurndal wrote:
> the 70's that is still running today, and will continue to
> run through 2030, and is still the foundation of manual pages
> on unix/linux systems.
 
Or perhaps nroff.
 
> If you are documenting source code, then you should at minimum
> provide doxygen comments in the source.
 
Seriously? doxygen is a train wreck.
 
 
 
--
Randy Howard
(replace the obvious text in the obvious way if you wish to contact me
directly)
jacobnavia <jacob@jacob.remcomp.fr>: Mar 30 06:01PM +0200

Le 30/03/2016 17:11, Scott Lurndal a écrit :
> the 70's that is still running today, and will continue to
> run through 2030, and is still the foundation of manual pages
> on unix/linux systems.
 
You are comparing TeX to troff?
 
How about mathematical formulae?
How about QUALITY?
 
Please, there is NO comparison here!
scott@slp53.sl.home (Scott Lurndal): Mar 30 04:12PM

>> run through 2030, and is still the foundation of manual pages
>> on unix/linux systems.
 
>Or perhaps nroff.
 
It's the same source language - troff generates typesetter output (now postscript)
and nroff generates terminal output.
 
 
>> If you are documenting source code, then you should at minimum
>> provide doxygen comments in the source.
 
>Seriously? doxygen is a train wreck.
 
YMMV.
scott@slp53.sl.home (Scott Lurndal): Mar 30 04:14PM

>> on unix/linux systems.
 
>You are comparing TeX to troff?
 
>How about mathematical formulae?
 
man eqn(1) for the small subset of documents requiring math formulae.
man pic(1) for diagrams
man tbl(1) for tables
man dformat(1) for data structure documentation
mqn grap(1) for graphs
 
>How about QUALITY?
 
Missing definition noted.
 
 
>Please, there is NO comparison here!
 
Wrong group for this argument. Suffice it to say
horses for courses.
Keith Thompson <kst-u@mib.org>: Mar 30 09:23AM -0700

(I'm not sure this belongs in comp.lang.c++, but I'll leave the
newsgroups list as it is for now.)
 
 
>> There you will find all the source code and the source code of the
>> dopcumentation in TeX form (the only word processor of the 80es that is
>> still running today and will run in 2030)
[...]
 
> Thanks for the warning.
 
> Out of curiosity, is it really written in plain C, or that 'almost C'
> flavor you like?
 
It appears to be plain C. When I modify the Makefile to use
-std=c11 -pedantic -Wall -Wextra -O3
with gcc 5.3.0, I get a number of unused parameter warnings.
(I haven't looked into them, but that's probably to be expected
for this kind of thing.) Adding
-Wno-unused-parameter
 
leaves two warnings:
 
hashtable.c: In function 'Clear':
hashtable.c:696:27: warning: 'HashIdx.ht' is used uninitialized in this
function [-Wuninitialized]
if (hi->index > hi->ht->max)
^
hashtable.c:383:15: note: 'HashIdx' was declared here
HashIndex HashIdx,*hi;
^
 
and:
 
priorityqueue.c: In function 'checkcons':
priorityqueue.c:418:36: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
if (h->Log2N == -1 || h->count > (1 << h->Log2N)) {
 
"-std=c99" gives similar results.
 
One more minor problem: "make clean" doesn't remove "test.o".
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
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)