Thursday, January 24, 2019

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

Daniel <danielaparker@gmail.com>: Jan 24 07:47AM -0800

On Thursday, January 24, 2019 at 4:35:57 AM UTC-5, Stuart Redmann wrote:
> that parameters are not null. These checks are usually not needed in C++,
> so "proper" Java code is inherently slower than C++ code, even if Java is
> executed as native code.
 
Appreciate the balanced comments.
 
Generally speaking I prefer the reference + gc model in java/c# and most
(all?) newer languages to the C++ model. It's simpler, cleaner and more
consistent. And in principle it avoids the need for copies, which is safe as
long as java/c# programmers use immutable interfaces as consistently as C++
programmers use const. Unfortunately this isn't always the case, the library
containers don't come with immutable interfaces, and it's not unusual for a
C# programmers to make a copy after calling a function because they don't
trust what that function might have done with their reference.
 
Daniel
"Öö Tiib" <ootiib@hot.ee>: Jan 24 07:48AM -0800

On Thursday, 24 January 2019 17:24:08 UTC+2, Jux und Tollerei wrote:
 
> Then they obviously made a major mistake.
> It is a physical principe, that when you make more effort,
> i.e. get less efficiency, you get a higher performance.
 
There are no such laws of physics. Resources can be
(and are often) burned without any benefits in this universe.
Java is bit simpler to use and more difficult to misuse than
C++ and that is paid with inefficiency. So it has benefits,
but it is not speed.
Jux und Tollerei <Jux.und.Tollerei@gmail.com>: Jan 24 04:57PM +0100

> Java is bit simpler to use and more difficult to misuse than
> C++ and that is paid with inefficiency. So it has benefits,
> but it is not speed.
 
You're wrong because you're not skilled enough to write performant
Java-code.
leigh.v.johnston@googlemail.com: Jan 24 07:58AM -0800

On Thursday, January 24, 2019 at 3:48:21 PM UTC, Öö Tiib wrote:
> Java is bit simpler to use and more difficult to misuse than
> C++ and that is paid with inefficiency. So it has benefits,
> but it is not speed.
 
I disagree with your assertion that Java is simpler than C++ to use. C++ is more complex than Java sure but it doesn't follow that that makes Java easier to use: the complexity of the C++ language and library implementation actually pulls complexity out of the C++ programs you write. The simplest programming language of all is arguably assembly but try writing anything non-trivial in assembly.
 
/Leigh
"Öö Tiib" <ootiib@hot.ee>: Jan 24 08:19AM -0800

On Thursday, 24 January 2019 17:48:03 UTC+2, Daniel wrote:
> containers don't come with immutable interfaces, and it's not unusual for a
> C# programmers to make a copy after calling a function because they don't
> trust what that function might have done with their reference.
 
I like the idea (started by D language) that fundamental types and structs
are (by default) passed by value and classes are (by default) passed by
reference. This leaves the opportunity to control it in but removes the need
to type it out.
I think Swift has made that, immutability control and if something is optional
or not (can be null or not) close to perfectly.
All of it is still under my control but i don't have to type piles of "const&"
or null checking garbage for that, it does the right thing by default and
complains when I forget something about it.
Daniel <danielaparker@gmail.com>: Jan 24 08:43AM -0800

On Thursday, January 24, 2019 at 4:37:30 AM UTC-5, Öö Tiib wrote:
> ran with most decent stuff there is then C++ runs algorithms
> about twice faster, C++ takes about twice less power and the memory
> usage is about 6 times smaller.
 
Possibly of relevance:
 
http://www.vldb.org/pvldb/vol10/p1118-li.pdf
 
In this paper, the author finds that the Java-based JSON libraries (GSON and
Jackson) are often faster than RapidJSON, which is written in C++, and what I
would regard as the fastest open source C++ json library that is safe for
general use. On the other hand, the author's own, faster, attempt is written
in C++, and employs SIMD vectorization and "bitwise parallelism". So perhaps
we can conclude that skilled programmers writing a classic FSM C++ json
parser, and squeezing out all the performance they can by avoiding the C++
and C library functions for string/number conversions and supplying their own
(as RapidJson does), can only get close to the Java implementations, but that
C++ can provide opportunities for new and faster techniques :-)
 
> 2) Experts are limited and expensive resource. Most of code is
> written by mediocres or worse.
 
Just so :-)
Cholo Lennon <chololennon@hotmail.com>: Jan 24 01:47PM -0300

On 1/24/19 12:57 PM, Jux und Tollerei wrote:
>> but it is not speed.
 
> You're wrong because you're not skilled enough to write performant
> Java-code.
 
Wow... how about you? show us your Java credentials please.
 
 
--
Cholo Lennon
Bs.As.
ARG
Bonita Montero <Bonita.Montero@gmail.com>: Jan 24 05:54PM +0100

>> You're wrong because you're not skilled enough to write performant
>> Java-code.
 
> Wow... how about you? show us your Java credentials please.
 
I'm using Java on HPC-systems since the beginning of the first JIT-VM.
Daniel <danielaparker@gmail.com>: Jan 24 09:11AM -0800

On Thursday, January 24, 2019 at 11:19:32 AM UTC-5, Öö Tiib wrote:
> All of it is still under my control but i don't have to type piles of "const&"
> or null checking garbage for that, it does the right thing by default and
> complains when I forget something about it.
 
C# has a similar distinction between struct and class.
 
Do you think D still has a chance to break through? It's been around for a
long time.
 
Daniel
Thiago Adams <thiago.adams@gmail.com>: Jan 24 09:31AM -0800

On Thursday, January 24, 2019 at 3:11:13 PM UTC-2, Daniel wrote:
 
> C# has a similar distinction between struct and class.
 
> Do you think D still has a chance to break through? It's been around for a
> long time.
 
The first edition of C did it right.
 
From the C programming language first edition:
 
"There are a number of restrictions on C structures. The essential rules
are that the only operations that you can perform on a structure are take its
address with c, and access one of its members. This implies that structures
may not be assigned to or copied as a unit, and that they can not be passed
to or returned from functions. (These restrictions will be removed in forthcoming versions.) Pointers to structures do not suffer these limitations,
however, so structures and functions do work together comfortably.
"
 
In other words struct had to be passed as pointer and it was the only
way.
In 2019, I think 100% of my code don't passes structs by value.
 
I use struct assignment and I think returning structs can be useful
for initialization.
 
Since the begging C had the -> operator instead of just . (dot)
 
I would like to try a modified version of C passing structs as pointers
and without the -> operator. Arrays are already like that.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 24 07:11PM

On Thu, 24 Jan 2019 07:58:35 -0800 (PST)
> programs you write. The simplest programming language of all
> is arguably assembly but try writing anything non-trivial in
> assembly.
 
Java is a horrible language to write code in. It's like being locked
in an Austin Powers movie, with its massive inheritance heirarchies and
1990's style OO.
 
However the JVM is quite nice and is perfectly usable if you use some
other language with it such as scala, clojure or kawa: I'm told that
kotlin is also good although I don't know much about it. You can have
particular cases where java/jvm is faster than c++ but they are
uncommon. There is a reason why rust follows the C++ approach to native
code generation.
 
However, the OP has the name "Jux und Tollerie". That should tell you
all you know that he is having gentle amusement at others expense. That
is, he is a relatively inoffensive troll.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 24 07:13PM

On Thu, 24 Jan 2019 19:11:48 +0000
> However, the OP has the name "Jux und Tollerie". That should tell you
> all you know that he is having gentle amusement at others expense. That
> is, he is a relatively inoffensive troll.
 
Ah, I see that someone else has pointed that out further down the thread.
Daniel <danielaparker@gmail.com>: Jan 24 12:43PM -0800

On Thursday, January 24, 2019 at 2:12:06 PM UTC-5, Chris Vine wrote:
 
> Java is a horrible language to write code in.
 
This is of course an opinion with comparable intellectual heft to some of
the other opinions expressed herein :-) It's not, as I'm sure you realize, a
universally held opinion. During the nineties, Java largely replaced C++ as
the language in which middleware tooling and messaging software such as
TIBCO Business Works and IBM Process Server were written. Huge swathes of
software once written in C++, including financial trading systems and
computationally intensive risk systems, moved to JAVA, and later C#. There
were reasons for this. Do you understand why?
 
Daniel
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jan 24 08:48PM

On 24/01/2019 20:43, Daniel wrote:
> software once written in C++, including financial trading systems and
> computationally intensive risk systems, moved to JAVA, and later C#. There
> were reasons for this. Do you understand why?
 
Because of idiots such as yourself pushing Java due to not getting C++.
Also, C++ is a much better language now than it was in the 90s; there
wasn't even a C++ standard until 1998.
 
/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."
Juha Nieminen <nospam@thanks.invalid>: Jan 24 05:15PM

Static objects, such as ones in namespaces (including nameless
namespaces) and static class members, are constructed before
main() is even called.
 
I just want to make sure: Is it ok to use std::thread and the
other multithreading standard utilities in the constructors of
these objects?
 
We can assume that no such object needs anything from another
object in another compilation unit.
 
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Thiago Adams <thiago.adams@gmail.com>: Jan 24 04:05AM -0800

On Wednesday, January 23, 2019 at 6:32:39 PM UTC-2, Daniel wrote:
 
> Also, I'd be interested in thoughts about writing tests for exception guarantees.
 
> Thanks,
> Daniel
 
Because your sample is big I cannot see where exactly
is the point of your concern.
 
From C+ standard:
 
"23.2.1 General container requirements"
 
"— if an exception is thrown by a push_back() or push_front() function, that function has no effects."
 
The constructor itself also has strong guarantee.
 
 
Appendix E from The C++ programming Language (C++ 03 edition)
is:
 
"Standard-library Exception Safety"
Paavo Helde <myfirstname@osa.pri.ee>: Jan 24 03:05PM +0200

On 24.01.2019 14:05, Thiago Adams wrote:
 
> From C+ standard:
 
> "23.2.1 General container requirements"
 
> "— if an exception is thrown by a push_back() or push_front() function, that function has no effects."
 
I guess his question is about whether a change in capacity is "effect"
or not.
Paavo Helde <myfirstname@osa.pri.ee>: Jan 24 03:22PM +0200

On 23.01.2019 23:05, Daniel wrote:
 
> Indeed. Feel free to make mental substitutions of sense for nonsense, e.g.
 
> if (w_.size()+1 < w_.capacity())
> w_.reserve(w_.size() + 1);
 
This might be bad performance-wise as it will likely cause buffer
reallocation at each push_back(). I would suggest something like:
 
w_.reserve(w_.size() + std::max(size_t(1), w_.size()/2));
Daniel <danielaparker@gmail.com>: Jan 24 05:24AM -0800

On Thursday, January 24, 2019 at 7:05:40 AM UTC-5, Thiago Adams wrote:
 
> Appendix E from The C++ programming Language (C++ 03 edition)
> is:
 
> "Standard-library Exception Safety"
 
Yes, I know. The question isn't about std::vector, but about C, which
contains two std:vectors. Strong exception guarantee for C would mean
if an operation on either vector resulted in an exception, both vectors
would be in their original state. The question is: does C as I've
written it (with Alf's correction of my typo) satisfy the strong
exception guarantee?
 
Daniel
Daniel <danielaparker@gmail.com>: Jan 24 06:12AM -0800

On Thursday, January 24, 2019 at 8:22:28 AM UTC-5, Paavo Helde wrote:
 
> This might be bad performance-wise as it will likely cause buffer
> reallocation at each push_back(). I would suggest something like:
 
> w_.reserve(w_.size() + std::max(size_t(1), w_.size()/2));
 
Very bad performance wise :-) thanks for the comment.
"Öö Tiib" <ootiib@hot.ee>: Jan 24 06:59AM -0800

On Thursday, 24 January 2019 15:24:24 UTC+2, Daniel wrote:
> would be in their original state. The question is: does C as I've
> written it (with Alf's correction of my typo) satisfy the strong
> exception guarantee?
 
Strong exception guarantee is about operations (not classes) and it
means that state of objects participating in operation does not
change when exception was thrown during operation.
 
You likely mean "C::push_back" with "C"? C is relatively unsafe class
it exposes all data members, so anyone can do numerous unsafe
operations with it.
 
Formally it is not strong. In practice the answer depends on if change
of capacity of vectors in C is change of state of C for your app or not.
Lot of code ignores reserved capacity of vectors and for such it is
not a state.
Daniel <danielaparker@gmail.com>: Jan 24 07:19AM -0800

On Thursday, January 24, 2019 at 9:59:30 AM UTC-5, Öö Tiib wrote:
> means that state of objects participating in operation does not
> change when exception was thrown during operation.
 
> You likely mean "C::push_back" with "C"?
 
Right
 
> of capacity of vectors in C is change of state of C for your app or not.
> Lot of code ignores reserved capacity of vectors and for such it is
> not a state.
 
Okay, that answers my question, thanks. I'll go with the formal answer.
 
Daniel
Rosario19 <Ros@invalid.invalid>: Jan 24 10:58AM +0100

su rainews24 hanno fatto vedere una che parlava di aumento di tumori a
cervello in topi trattati con stessa frequenza e energia del campo dei
cellulari (presumo a contatto con l'orecchio)... direi di eliminare i
cellulari (o usare sempre l'auricolare con filo) e usare il modem
normale senza wi fi. (tranne che nn ho capito bene cmq mi regolo che
diminuisco l'uso di cellulari)
"Öö Tiib" <ootiib@hot.ee>: Jan 24 03:07AM -0800

On Thursday, 24 January 2019 11:52:20 UTC+2, Rosario19 wrote:
> cellulari (o usare sempre l'auricolare con filo) e usare il modem
> normale senza wi fi. (tranne che nn ho capito bene cmq mi regolo che
> diminuisco l'uso di cellulari)
 
Ci devono essere gruppi per gli italiani e per l'assistenza sanitaria.
(There must be groups for italians and about healthcare.)
ram@zedat.fu-berlin.de (Stefan Ram): Jan 24 10:31AM

You write:
>>ran with most decent stuff there is then C++ runs algorithms
>>about twice faster
>That's your *opinion*, which is affected by your taste.
 
Speed is not a opinion, but can be measured.
 
Shootoutgames has done so and shown Java to be
slower by a factor of two.
 
>Java can be even faster than C++ in most cases because of its
>dynamic compilation.
 
Then goto
 
benchmarksgame-team.pages.debian.net
 
and rewrite the Java code, so that it runs faster than C++
in most cases.
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)