Monday, February 13, 2017

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

Christiano <christiano@engineer.com>: Feb 13 08:06PM

On Thu, 02 Feb 2017 19:11:21 +0000, Christiano wrote:
 
> natural way of thinking of C. In fact whenever I used libraries made in C,
> I never saw anything that was "header-only".
 
> So, what's the point? Why in C ++ is this way?
 
I know that this question is a little old, but I found this page in the
stroutrup's book ( ISBN-13: 978-0321992789 ) very relevant and I decided
to do a scan and post here:
 
http://imgur.com/FPkvQ91
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 13 09:41PM +0100

On 13.02.2017 21:06, Christiano wrote:
> stroutrup's book ( ISBN-13: 978-0321992789 ) very relevant and I decided
> to do a scan and post here:
 
> http://imgur.com/FPkvQ91
 
Oh goodie. But it's best to post /pure text/, and to not refer to
storage elsewhere: that Imgur image will probably disappear in a few
weeks or months, while these Usenet postings will continue to be
archived by various services, including by Google Groups. So that end, I
 
(1) googled "online ocr",
(2) clicked the first result,
(3) uploaded your image,
(4) downloaded the resulting Word file,
(5) copied the relevant text over to Notepad++ and replaced tabs with
spaces, as well as adding blank lines between paragraphs,
 
resulting in
 
 
<quote>
Writing the definition of a member function within the class definition
has three effects:
 
• The function will be inline; that is, the compiler will try to
generate code for the function at each point of call rather than using
function-call in¬structions to use common code. This can be a
significant performance advantage for functions, such as month(), that
hardly do anything but are used a lot.
 
• All uses of the class will have to be recompiled whenever we make a
change to the body of an inlined function. If the function body is out
of the class declaration, recompilation of users is needed only when the
class declaration is itself changed. Not recompiling when the body is
changed can be a huge advantage in large programs.
 
• The class definition gets larger. Consequently, it can be harder to
find the members among the member function definitions.
 
The obvious rule of thumb is: Don't put member function bodies in the
class declaration unless you know that you need the performance boost
from inlining tiny functions. Large functions, say five or more lines of
code, don't benefit from inlining and make a class declaration harder to
read. We rarely inline a function that consists of more than one or two
expressions
</quote>
 
 
Bjarne Stroustrup is over-simplifying a bit here, for the novice audience.
 
I think that as language creator we can be assured that he knows better
than to assert what the compiler will do with the `inline` hint.
 
It's worth noting that this page, in particular the part with a
rectangle around it quoted here, is not about header only modules but
about how to structure a class definition so as to make it *clear*.
 
Even for a class definition in a header for a conventional separately
compiled module, it can make sense to have some short member functions
inline in the class.
 
For example, a public short function can check preconditions and
postconditions, but delegate the main work to a private virtual function
that can be arbitrarily complex, possibly with some transformation of
the argument(s). The short public wrapper's body is then part of the
class' public interface. And that body is not subject to change unless
the class interface is changed, in which case recompilation is needed
anyway.
 
 
Cheers!, & sorry for mailing this by mistake,
 
- Alf
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 13 04:21PM +0100

On 13.02.2017 00:21, Alf P. Steinbach wrote:
> begin( dictionary ), end( dictionary ) - 1, board, start,
> visited, word, result
> );
 
A new bug, the "-1" here, weaseled its way into the code as a result of
exploring solutions of the dereferencing-of-beyond-array-iterator bug.
 
It's like bugs create new bugs.
 
Like they procreate!
 
 
Cheers!,
 
- Alf
Gareth Owen <gwowen@gmail.com>: Feb 13 05:39PM

> board, and a potentially unbounded dictionary. The program needs
> to do something with each dictionary word, even if just to read
> and discard it
 
A digression : this reinforces your later point about asking smart
questions. Here asking about the problem parameters is key. If we know
nothing about the dictionary, we have to look at every word in it.
 
If we know its sorted, however ..
 
(In the world of books, being sorted is an important property of
anything calling itself a dictionary)
Juha Nieminen <nospam@thanks.invalid>: Feb 13 07:33AM

> This works when FLT_RADIX is 2, but it need not be.
 
In which practical system it isn't?
 
Of course for optimization you could use #if to use the integer
calculation, else the floating point one.
Robert Wessel <robertwessel2@yahoo.com>: Feb 13 04:07AM -0600

On Mon, 13 Feb 2017 07:33:44 +0000 (UTC), Juha Nieminen
 
>In which practical system it isn't?
 
>Of course for optimization you could use #if to use the integer
>calculation, else the floating point one.
 
 
On IBM mainframes, you can use either traditional hex FP or IEEE
binary FP for floats, doubles and long doubles (based on a compiler
option). FLT_RADIX changes appropriately.
 
The system also supports IEEE decimal floating point, but I'm not
aware of any way you can make ordinary floats use decimal FP (you
actually do define such items with "_Decimal64", etc., and additional
constants are defined in decimal.h).
Juha Nieminen <nospam@thanks.invalid>: Feb 13 07:29AM

> std::vector<Employee *> or std::vector<std::shared_ptr<Employee>>
 
> Because of the copy construction on insert.
> The fellow did not seem to like that answer at all.
 
I would say that in most cases the former is better, even more efficient.
 
Memory allocation in languages that use the C runtime allocator is quite
heavy and inefficient. By using pointers you are introducing an additional
memory allocation (and deallocation) for every single element. This can
increase the inefficiency of the container by quite a lot (especially
if Employee doesn't itself allocate any memory dynamically).
 
Using a vector of values is also simpler and safer, as it's harder to
accidentally eg. leak memory, or access freed memory.
 
If Employee is a very heavy class to copy, then the optimization should
be done inside it, not in the container that's using it.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Feb 12 11:29PM

BUGGER SHIT FUCK SHIT FUCKING SPHINCTER ARSEHOLE UP YOUR ARSE UP YOUR
CUNT FUCK YOU SIDEWAYS YOU FUCKING BORING FUCKING WHORE FUCK OFF YOU COW!
 
https://www.youtube.com/watch?v=JaY7VTftPdY
 
Brian Blessed is a star.
 
/Flibble
woodbrian77@gmail.com: Feb 12 06:36PM -0800

On Sunday, February 12, 2017 at 5:29:54 PM UTC-6, Mr Flibble wrote:
 
Pretty please? Urbandictionary.com says, "no man can say
no to a 'pretty please'."
 
 
Brian
 
"But the path of the righteous is like the light of dawn,
That shines brighter and brighter until the full day." Proverbs 4:18
Ian Collins <ian-news@hotmail.com>: Feb 13 07:10PM +1300


> Brian
 
> "But the path of the righteous is like the light of dawn,
> That shines brighter and brighter until the full day." Proverbs 4:18
 
Maybe if Flibble cuts back on the swearing, you (and Rick) can cut out
the proselytising?
 
--
Ian
woodbrian77@gmail.com: Feb 12 07:21PM -0800

On Sunday, February 12, 2017 at 3:04:40 AM UTC-6, Öö Tiib wrote:
> // here we know that get returns string
> auto extract = std::get<1>(v);
> }
 
+1 for example code.
 
It looks like std::variant can have zero or one types.
What's up with that? Prefer "float" to ::std::variant<float>.
Scott Meyers if you're listening to this, please put that in
your next book.
 
 
Brian
Ebenezer Enterprises
http://webEbenezer.net
"J. Clarke" <j.clarke.873638@gmail.com>: Feb 12 10:14PM -0500

In article <o6klkt$1dcu$1@gioia.aioe.org>, alessandro.volturno@libero.it says... > Il 28/01/2017 21:40, Christiano ha scritto: > > Test this code: > > #include <iostream> > > #include <string> > > using namespace std; > > int main() > > { > > cout << "\033[2J" << endl; // clear screen > > cout << "\033[0;0f" << endl; //puts the cursor at line 0, columm 0 > > string text = "Hello, world...\n"; > > for(int i=0;i<text.size();i++) > > > > // text with colors > > cout << "\033[0;"<< (31+i%7) <<"m" << text[i] ; > > > > char c; > > cout << "\033[10;30f:)..."; > > cin >> c; > > return 0; > > } > > Reference: > > http://www.tldp.org/HOWTO/Bash-Prompt-HOWTO/c327.html > Too many "magic" numbers. > Thank you anyway, > this is the output compiled with Code::Block 16.01 - MingW compiler > under MS-Windows: [0;0f [0;31mH [0;32me [0;33ml [0;34ml [0;35mo [0;36m, [0;37m [0;31mw [0;32mo [0;33mr [0;34ml [0;35md [0;36m. [0;37m. [0;31m. [0;32m [10;30f:)... > Microsoft Visual Studio 17 RC doesn't evn compile it. What happens when you try to compile it? It compiled fine under 2015 for me.
"Chris M. Thomasson" <invalid@invalid.invalid>: Feb 12 06:09PM -0800

On 2/12/2017 12:48 AM, Robert Wessel wrote:
>>> spread across nodes, it would be just wasting computer resources).
 
>> Indeed. Sharing across NUMA nodes should be avoided like the damn plague!
 
> FSVO "plague".
 
Well, the phraseology was to harsh, but the action should try to be
minimized.
 
 
> The whole point of NUMA is to allow some level of intra-node sharing
> with significantly lower latency than across a cluster.
 
Indeed. I worry about the details of the type of communications that
make NUMA nodes share. Think of a node going down! Or the process that
holds the thread, or fiber that is initiating the sync totally dies?
Iirc, a mixture of transactional memory, clever lock-free
fault-tolerant, and/or down right robust mutexs can get the job done.
Also, one can try to emulate this with a so-called "watchdog" process,
that can notify when an active entity has died while in the middle of
something critical.
 
 
 
> If you don't
> have/need that, then why are you running on an expensive NUMA box
> rather than on a cheap cluster?
 
What about multiple NUMA computers in a cluster?
 
 
 
> Which is not to detract from your point, which is that data sharing
> between nodes has a very significant penalty compared to items held
> (exclusively) local to a node.
 
I should say, try to avoid, however, sometimes this is easier said than
done.
 
;^o
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 13 12:32AM +0100

On 12.02.2017 23:14, JiiPee wrote:
 
> )
 
> As you can see it keep giving ONLY big numbers. It never give numbers
> like 9887. Why? How can I get values from the whole range? Thanks.
 
That looks like 64-bit numbers.
 
Now if you produce 1 such number, the chance of it being less than 2^16
= 65536, a not unreasonable choice for "small" number, is 2^16/2^64 =
2^(16-64) = 2^(-48). The Windows calculator tells me that that is
roughly 3,55 * 10^(-15). Now if you produce 1000 such numbers, the
chance of getting at least one small one, is at most 3,55 * 10^(-12).
 
More precisely, the chance of not getting any small number among the
1000 numbers is (1 - (3,55 * 10^(-15)))^1000, and correspondingly the
chance of getting at least one, is 1 - (1 - (3,55 * 10^(-15)))^1000. The
Windows calculator says that that is, roughly, 3,55 * 10^(-12). Oh!
Nothing much gained for getting precise here! :)
 
 
Cheers & hth.,
 
- Alf
"Öö Tiib" <ootiib@hot.ee>: Feb 12 03:36PM -0800

On Monday, 13 February 2017 00:14:51 UTC+2, JiiPee wrote:
> I am trying to get values from the whole : 1 - max(unsigned long long)
> range. But this code (which many recommend on the internet) just does
> not seem to give small number never.
 
I did not look at your code since the behavior as you describe feels
totally as expected to me.
 
Same happens when we try to count from unsigned long long max to 0,
it will seemingly give 42 never. The actual problem is that it would
take about 150 years to reach 42 when counting at 4 gigahertz one per
cycle.

Random number generators take tens of cycles per number so to get
for example one of 0 to 150 (from uniform distribution between 0
and unsigned long long max) would likely take tens of years of
generating. We accept 0 to 300? Then it would be expected in twice
less than in tens of years. :D
 
Oh and beware of random_device, it is not guaranteed to work by
standard. Implementation may choose that it does nothing.
JiiPee <no@notvalid.com>: Feb 12 11:43PM

"the windows calculator says" ... haha. so that is your auktority ? :).
 
just joking.
Yes, I also noticed that.... that its actually not propable the low
numbers would come. Its just difficult as a human to see that
intuitively (I would think we get also small ones). Yes I understand
mathematics...
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)