Wednesday, May 17, 2017

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

JiiPee <no@notvalid.com>: May 17 07:40PM +0100

I am thinking with one or my friends whether we should use boost's
thread or std's thread? Are they very similar? I have never used boost's
thread-system. Which one you would use? thanks
Paavo Helde <myfirstname@osa.pri.ee>: May 17 10:06PM +0300

On 17.05.2017 21:40, JiiPee wrote:
> I am thinking with one or my friends whether we should use boost's
> thread or std's thread? Are they very similar? I have never used boost's
> thread-system. Which one you would use? thanks
 
They are pretty similar, boost's implementation just served as the test
bench for standardization. Some boost features like thread cancellation
have been left out from std::thread, this is arguably a good thing.
 
One should always prefer standard tools whenever possible so one should
use std::thread nowadays.
JiiPee <no@notvalid.com>: May 17 08:14PM +0100

On 17/05/2017 20:06, Paavo Helde wrote:
> good thing.
 
> One should always prefer standard tools whenever possible so one
> should use std::thread nowadays.
 
thanks, that is what I was thinking as well.
 
But, as my friend mentiones, boost seems to be able to do concurrent
programming without threads. Is this gonna be significantly better
solution (so no need to start threads):
 
 
The Proactor Design Pattern: Concurrency Without Threads
<http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html>
 
http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html
 
I have no clue what this is, but just looking for a direction.
JiiPee <no@notvalid.com>: May 17 08:17PM +0100


> http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html
 
> I have no clue what this is, but just looking for a direction.
 
Seems to say its more efficient. Is this true:
 
Performance and scalability.
 
Implementation strategies such as thread-per-connection (which a
synchronous-only approach would require) can degrade system
performance, due to increased context switching, synchronisation and
data movement among CPUs. With asynchronous operations it is
possible to avoid the cost of context switching by minimising the
number of operating system threads — typically a limited resource —
and only activating the logical threads of control that have events
to process.
Ian Collins <ian-news@hotmail.com>: May 18 07:33AM +1200

On 05/18/17 07:14 AM, JiiPee wrote:
> <http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html>
 
> http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html
 
> I have no clue what this is, but just looking for a direction.
 
I had a similar discussion with a group of colleagues yesterday and we
all agreed asio is OK for situations where you need to manage multiple
concurrent connections and threads are better when the number is small
(often one!). Using asynchronous I/O is seldom simple!
 
--
Ian
Paavo Helde <myfirstname@osa.pri.ee>: May 17 10:46PM +0300

On 17.05.2017 22:14, JiiPee wrote:
 
> <http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html>
 
> http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio/overview/core/async.html
 
> I have no clue what this is, but just looking for a direction.
 
This is about async I/O, which is very relevant if your program is
I/O-bound. If it is CPU-bound, then the things get different and real
multi-threading might provide an answer.
 
The optimal solution depends a lot on the concrete task and the
properties of the available hardware. For example, nowadays some tasks
are best accomplished by GPU-s (which are not directly related to
neither async I/O nor to what is commonly called multithreading).
 
A general advice: if you have no experience in the area, there is not
much point in striving to the most effective solution the first time,
you will not achieve that anyway. Instead, you should try to develop a
decent, correctly working program, preferably multiple programs using
different approaches if possible, for comparison. The time to focus on
top performance will come maybe after some 5 years when you have
gathered enough experience.
Jerry Stuckle <jstucklex@attglobal.net>: May 16 09:11PM -0400

On 5/16/2017 8:42 AM, Scott Lurndal wrote:
> pretty straightforward to download and build most of the models. The
> vast majority of which are written in FORTRAN and use one of the parallelization
> features such as openMP or are in C/C++ and use CUDA.
 
No, NASA is not responsible for the weather prediction models. Many
models (i.e. European) are not even created in the U.S. That falls
under NOAA (Department of Commerce).
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Jerry Stuckle <jstucklex@attglobal.net>: May 16 09:13PM -0400

On 5/16/2017 5:48 PM, Christian Gollwitzer wrote:
 
> So this was just another classic Jerry line with claimed expertise and
> no real knowledge behind. Good to know.
 
> Christian
 
Ah, yes. Another slam from someone who can't stand to have someone more
experienced than he is.
 
Get over it, snowflake. You do NOT know everything. The difference
between you and me is I don't pretend to know everything - I just don't
comment on things I know nothing about.
 
You, OTOH, have to prove your ignorance on every subject.
 
 
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
Gareth Owen <gwowen@gmail.com>: May 17 05:42PM +0100

>> features such as openMP or are in C/C++ and use CUDA.
 
> So this was just another classic Jerry line with claimed expertise and
> no real knowledge behind. Good to know.
 
Yup. The cost of speeding up the code with assembler (time, money, like
of portability) are far greater than just throwing a bunch more
processors at them
Gareth Owen <gwowen@gmail.com>: May 17 06:53PM +0100


> So this was just another classic Jerry line with claimed expertise and
> no real knowledge behind. Good to know.
 
> Christian
 
From the NOAA, not NASA or github. Not in assembly, either.
http://www.nco.ncep.noaa.gov/pmb/codes/nwprod/
Lynn McGuire <lynnmcguire5@gmail.com>: May 17 02:24PM -0500

On 5/9/2017 8:14 AM, Scott Lurndal wrote:
>> optimized/beautiful "foo" code
 
> I challenge you to take any reasonable COBOL program and try to make it
> "optimized/beautiful C++" code. Good luck with that.
 
Heh.
 
Lynn
Paavo Helde <myfirstname@osa.pri.ee>: May 17 08:32AM +0300

On 16.05.2017 22:43, alexo wrote:
 
> Build failed: 4 error(s), 0 warning(s) (0 minute(s), 0 second(s))
 
> $ errors but the compiler doesn't tell me what they are. It shows only
> linker errors.
 
Yes, the 4 errors are the 3 linker error lines plus the fact that linker
returned an error exit status. Do not turn too much attention to the
exact number of them.
 
However, the error about missing destructor seems to have correct, there
is no destructor defined in the code.
 
> {
> MyClass<int> test(3);
 
> cout << test.data << endl;
 
This line does not compile because test.data is private. So there cannot
be any linker errors because the compilation never reaches the linking
stage.
 
So it appears that the main problem with your code is that the posted
code does not match the posted errors. Maybe you have mixed up the cpp
files on your computer as well?
 
 
alexo <alessandro.volturno@libero.it>: May 17 07:43PM +0200

Il 17/05/2017 07:32, Paavo Helde ha scritto:
 
> So it appears that the main problem with your code is that the posted
> code does not match the posted errors. Maybe you have mixed up the cpp
> files on your computer as well?
 
effectively I did it sorry. The version posted is not the one I posted
the output about. But I can assure you I get these messages anytime.
What I want to know is: does my code - (make T data public and try to
compile it) - compile on your machines? Do you get the same linker errors?
These messages appear to me even if I manually define the destructor. I
tried to compile it (the correct .cpp source file) both on a linux (Mint
18.1, g++ version 5.4.0 - CodeLite IDE) and a MS Windows machine (g++
4.9.2 MinGW + Code::Blocks ide) and I still get the same output. So I
don't know if there's a problem with my sintax. Is it correct or not?
 
thank you
alexo <alessandro.volturno@libero.it>: May 17 07:56PM +0200

Il 16/05/2017 22:36, red floyd ha scritto:
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
 
>> what is the problem in my code?
 
[...]
 
> since it seems like you actually did define it, but the linker error
> on the destructor is because you only declared it, but didn't define
> it.
 
That being linker errors, it seems to me that the compiler fails to
generate the code of the requested function calls.
Paavo Helde <myfirstname@osa.pri.ee>: May 17 09:39PM +0300

On 17.05.2017 20:43, alexo wrote:
> tried to compile it (the correct .cpp source file) both on a linux (Mint
> 18.1, g++ version 5.4.0 - CodeLite IDE) and a MS Windows machine (g++
> 4.9.2 MinGW + Code::Blocks ide) and I still get the same output.
 
It should compile if you define the destructor and make data public. If
it does not, then you introduced some other error. Please post the new
code and matching error messages, we are not psychics here!
 
So I
> don't know if there's a problem with my sintax. Is it correct or not?
 
If you get to the linker errors, this means that at least the compiler
was satisfied with your syntax. Whether the code is actually correct and
does what you wanted is another story.
woodbrian77@gmail.com: May 17 11:07AM -0700

I liked this video by Steven Simpson at ACCU 2017:
 
History of Time: Asynchronous C++
https://www.youtube.com/watch?v=Z8tbjyZFAVQ
 
It was helpful in pointing out how to skip a lookup based
on the socket. I hadn't realized how the kevent api could
be used to avoid that lookup.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 17 04:32AM +0200

On 16-May-17 10:35 PM, Richard wrote:
>> moderation servers, just stopped working.
 
> I am willing to look at this infrastructure to see if it can be made
> to work again.
 
You can contact Daveed (David Vandevoorde). As I recall he set it up,
and he also led the moderators. It was John Potter who created and
maintained the scripts that automated things on the server. Since I
wasn't active moderating after 2012 I don't know much about it, sorry.
 
E-mail addresses:
http://www.gotw.ca/resources/clcm.htm#Policy
 
 
Cheers!,
 
- Alf
Jorgen Grahn <grahn+nntp@snipabacken.se>: May 17 05:52AM

On Tue, 2017-05-16, Richard wrote:
>>moderation servers, just stopped working.
 
> I am willing to look at this infrastructure to see if it can be made
> to work again.
 
Could be worth it, even if it's just to:
- Post a message explaining that the group is inactive.
- Enable a later reactivation.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
woodbrian77@gmail.com: May 17 09:37AM -0700

On Wednesday, May 17, 2017 at 12:52:16 AM UTC-5, Jorgen Grahn wrote:
> > to work again.
 
> Could be worth it, even if it's just to:
> - Post a message explaining that the group is inactive.
 
And to mention comp.lang.c++ in case they don't know about it.
 
 
Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net
Juha Nieminen <nospam@thanks.invalid>: May 17 06:42AM

> usually in fan-boy groups of some sort. But if absolute mechanical rules
> worked well for programmers in general (it doesn't), not just beginners,
> then you'd have been replaced by a robot by now. ;-)
 
The std:: prefixes nicely mark all uses of the standard library in the
code, making them much easier to distinguish from other names, and thus
making the code easier to read and understand at a glance. Even when you
don't know or remember what a particular function or class does, the
std:: prefix immediately gives you the hint that it indeed *is* a standard
library element, and you thus immediately know where to look for the info,
rather than having to chasing wild geese. It's like color-coding of the
source code, but it works even in contexts where there is no code coloring
(such as here, or in many text editors).
 
I actually find it a curious psychological phenomenon why so many people
think that code that's "littered" with tons of std:: prefixes is somehow
ugly and hard to read. When I had this discussion in the past with someone,
he tried to demonstrate how "bad" code becomes when there are tons of
those prefixes by posting a piece of code that had a large amount of
calls to standard library functions and names. Ironically, it was
precisely the std:: prefixes that made the code actually *easier* to
understand, rather than harder (because of the abovementioned reason that
they give you an immediate visual cue about where the standard library
names are used.)
 
> All this said, this is the second ** NOISE **-posting in this thread,
> and I think I'm on much firmer ground than above when I speculate about
> why people would like to inject noise here.
 
My comment was besides the point of the original post for sure, but
so what? Is there a law that forbids tangential discussion?
 
Your conspiracy theory is really strange.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 17 12:11PM +0200

On 17-May-17 8:42 AM, Juha Nieminen wrote:
 
> Your conspiracy theory is really strange.
 
I think now you're off your rocker.
 
Cheers!,
 
- Alf
Juha Nieminen <nospam@thanks.invalid>: May 17 06:56AM

> The problem is however, that this makes the few_first_primes value
> far less usable! In particular, you can no longer use it with
> standard containers to initialize them or add values. Below code:
 
I tried this with clang, and it compiled and worked fine:
 
//-----------------------------------------------------------
#include <vector>
#include <iostream>
 
int main()
{
const auto values = { 1, 3, 5, 7 };
for(auto value: values) std::cout << value << "\n";
std::vector<int> vec = values;
for(auto value: vec) std::cout << value << "\n";
}
//-----------------------------------------------------------
 
Curiously, if I change the 'const' to 'constexpr', it fails to compile,
giving the error:
 
test.cc:7:20: error: constexpr variable 'values' must be initialized by a
constant expression
constexpr auto values = { 1, 3, 5, 7 };
^ ~~~~~~~~~~~~~~
 
test.cc:7:20: note: pointer to subobject of temporary is not a constant
expression
test.cc:7:29: note: temporary created here
constexpr auto values = { 1, 3, 5, 7 };
^
 
If I move 'values' to the global scope, then it works as a constexpr.
Ian Collins <ian-news@hotmail.com>: May 17 09:24PM +1200

On 05/17/17 06:56 PM, Juha Nieminen wrote:
> constexpr auto values = { 1, 3, 5, 7 };
> ^
 
> If I move 'values' to the global scope, then it works as a constexpr.
 
Interesting... g++ 6.3.0 doesn't mind the use of constexpr, but it
dislikes the vector assignment (with or without constexpr):
 
g++ x.cc -std=c++14
x.cc: In function 'int main()':
x.cc:9:28: error: conversion from 'const std::initializer_list<const
int>' to non-scalar type 'std::vector<int>' requested
std::vector<int> vec = values;
^~~~~~
--
Ian
Paavo Helde <myfirstname@osa.pri.ee>: May 17 08:58AM +0300

On 17.05.2017 0:42, Christiano wrote:
> without having to change the main.cpp program so that the original code
> was preserved and consequently the code from book did not have to have a
> "special case". Any suggestion is welcome.
 
This is a fine example demonstrating why "using namespace" is bad. It
would be probably be best for everybody if example programs meant for
teaching people did not contain such lines.
 
Instead, one could use for example
 
using Graph_lib::Font;
using Graph_lib::Point;
 
etc. This is both explicit and keeps the rest of the code the same as it
was.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 17 01:05AM +0100

Hi,
 
My upcoming C++ game/GUI library/framework "neoGFX" now has a wiki:
 
http://neogfx.io/wiki/index.php/Main_Page
 
neoGFX version 1.0 is about 75% complete at this stage.
 
/Flibble
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)