Saturday, September 25, 2021

Digest for comp.lang.c++@googlegroups.com - 13 updates in 4 topics

"das...@gmail.com" <dashley@gmail.com>: Sep 25 11:03AM -0700

I'm reading "Sams Teach Yourself C++ in One Hour a Day (6th Edition)".
 
(I'm already an expert-level C programmer, learning C++. I just say that as notice that you don't need to overexplain.)
 
In the examples in the book, they assign pointers to 0, typically at definition, i.e.
 
int *pInt = 0;
 
Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.
 
Is one style preferred over the other in C++? Why?
 
Thanks.
Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 06:16PM

> use NULL. I believe the value assigned is going to be the same, whether 0 or
> NULL is used.
 
> Is one style preferred over the other in C++? Why?
 
There were problems between using 0 as *integer* or *pointer*, now
we have nullptr to differentitate.
 
 
--
 
7-77-777
Evil Sinner!
Paavo Helde <myfirstname@osa.pri.ee>: Sep 25 09:20PM +0300


> int *pInt = 0;
 
> Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.
 
> Is one style preferred over the other in C++? Why?
 
In C++ (unlike C), NULL is a macro defined to 0, so there is no
difference. There are special rules about converting literal 0 to
pointer values. However, this was a kind of hack which did not work so
well after all, so C++11 introduced a new special keyword for a null
pointer. So the current preferred style is:
 
int *pInt = nullptr;
Paavo Helde <myfirstname@osa.pri.ee>: Sep 25 09:32PM +0300

25.09.2021 21:20 Paavo Helde kirjutas:
 
>> (I'm already an expert-level C programmer, learning C++.  I just say
>> that as notice that you don't need to overexplain.)
 
>> In the examples in the book, they assign pointers to 0,
 
Oh, and if this book predates C++11 (i.e. 2011), be aware that some
content is out-dated and it does not cover the myriad of new
enhancements introduced by C++11. You might want to use a newer book.
 
C++11 is quite essential for using C++ effectively nowadays. Later
additions have been smaller and more specialized, so can be postponed
for a while.
"das...@gmail.com" <dashley@gmail.com>: Sep 25 12:08PM -0700


> C++11 is quite essential for using C++ effectively nowadays. Later
> additions have been smaller and more specialized, so can be postponed
> for a while.
 
Thanks for the heads up! You were correct. Amazon tells me that the 6th edition was released in 2008, and I purchased it in 2011. (It seems like only yesterday LOL.)
 
I spent $20.49 and grabbed the latest edition (8th edition), which claims to cover C++ 2011 and C++ 2014. Since I'm only in Chapter 8, re-skimming for changes should be easy and then I can continue.
 
TBH, it would not have made a practical difference. I'm actually working on a Blackjack simulation program (and writing a book) to evaluate card counting strategies, so that I can drink and gamble more. I figured it would be a good chance to learn and get comfortable with C++ (although I could do it in C). For that type of program (mildly complex simulation, essentially numerical), advanced features of the language probably would not come into play.
 
As an aside, SOMEBODY will point out that there are lots of Blackjack books on the market, and what more could I want to know. Just to satisfy the curious, here are my reasons:
 
a)Blackjack authors are, on average, bad mathematicians. I don't trust what they publish. I would prefer to double-check.
 
b)I would prefer to know the first decimal point after some true count boundaries. For example, with hi-lo, it is typical to take the insurance bet at 3 or above. Is it really 3? Or is it 3.2? I can do arithmetic in my head well enough to want to know precisely.
 
c)No book I'm aware of covers the mathematical basis of camouflage plays (and it is mathematical). The goal is to do something that appears as bizarre as possible but that has a very small negative impact on expected value, so as to keep the dealer and pit bosses convinced that you aren't right in the head rather than being a skilled card counter. The notion of what you can do that appears bizarre but is not costly is mathematical.
 
d)I would like to maximize total return, which also involves counting against side bets, if possible. So, the "best" counting strategy at a given game with side bets may not be the best strategy for pure Blackjack. Again, no book I'm aware of looks at how best to count against the TOTAL game, including side bets.
 
So, to cut off the obvious feedback I would otherwise receive, .... no, I'm not reinventing the wheel.
 
Thanks for the heads up on upgrading my book!
"see.my....@gmail.com" <see.my.homepage@gmail.com>: Sep 25 01:05PM -0700

> int *pInt = 0;
 
> Nothing inherently wrong with that, but in C, it would be more traditional to use NULL.
 
It would be more traditional in C++, as well. Even though the actual definition means it's the same for the compiler, there is a difference for the human reader. NULL stands out in the code and immediately draws attention to its intended meaning as a pointer, whereas literal 0 is a number. I certainly prefer NULL over 0 in such uses.
 
> Is one style preferred over the other in C++? Why?
 
Things get more interesting with nullptr vs. NULL (since C++11), but I have to admit I'm not much excited about nullptr. NULL still draws attention more and I appreciate it for exactly this reason. Does it cause problems? I don't deny any horror story, but I certainly don't have any to share myself, so nullptr did not solve any measurable problem for me. I still write NULL in new code (and that usually applies to calling 3rd-party libraries) and I don't feel bad about it. You might find convincing arguments for the contrary, too. I believe it will stay as subjective choice forever.
 
--
Maciej Sobczak * http://www.inspirel.com
James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 25 05:36PM -0400


> int *pInt = 0;
 
> Nothing inherently wrong with that, but in C, it would be more traditional to use NULL. I believe the value assigned is going to be the same, whether 0 or NULL is used.
 
> Is one style preferred over the other in C++? Why?
 
In C, NULL can be defined as (void*)0, which is safer than 0, because it
cannot be accidentally used in arithmetic contexts, which is a good
reason to prefer NULL.
 
In C++, NULL is not permitted to expand to (void*)0, but it can be
defined as nullptr, which is not only safer than 0, but also is safer
than (void*)0, so NULL should be preferred in C++, too. However, as a
general rule explicit use of nullptr would be even better, because NULL
could simply be defined as 0.
Manfred <noname@add.invalid>: Sep 25 11:07PM +0200

On 9/25/2021 3:14 PM, Alf P. Steinbach wrote:
 
> ---
 
> That could open the world of safe multi-tasking to C++ programmers in
> general.
 
I'm no expert in coroutines, but AFAIU their main advantage is to enable
multitasking without the overhead of multithreading.
In order to achieve this, language support is needed that was just not
available prior to C++20 (and even with C++20 such support is limited,
so that only the subset of continuations is actually available, as you say)
 
The point being, if you try to do that using threads kind of defeats the
purpose, doesn't it?
(even if you build this with full synchronization inside, you'll still
pay the price of performance and resource usage, which can be relevant
for this kind of thing)
 
Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:22PM


>> And you use unreliable function for that?
 
> Show me where my code is unreliable.
> I think you're simply a poor troll.
I am just asking because you build something
on shaken ground. Why do you think is reliable,
simple question?
 
--
 
7-77-777
Evil Sinner!
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 25 01:34PM -0700

On 9/24/2021 10:24 PM, Bonita Montero wrote:
>> exists mainly for backward compatibility. For more information, see
>> Remarks."
 
> What I do is reliable.
 
Whats up with the:
 
while( !SetEvent( (HANDLE)m_xhEvtVisit ) );
 
Shouldn't you use GetLastError to find out why SetEvent failed?
 
Also, you are using:
 
cpu_pause( PAUSE_ITERATIONS );
 
In several places? Reeks of a spinlock. Some kind of backoff?
Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:20PM


> On my computer this outputs:
 
> 34.9194
 
> (Intel Xeon E-2286M CPU @ 2.40 GHz)
 
On mine does not compile becaise it is x86 specific...
 
 
--
 
7-77-777
Evil Sinner!
Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:29PM

>>> _mm_pause();
>> What's in _mm_pause ?
 
> Read again what I wrote or google for _mm_pause.
On mine system it is:
#include <iostream>
#include <chrono>
#include <cstddef>
#include <cstdint>
 
using namespace std;
using namespace chrono;
 
int main( int argc, char **argv )
{
static uint64_t const PAUSE_ROUNDS = 1'000'000'000;
auto start = high_resolution_clock::now();
for( uint64_t i = PAUSE_ROUNDS; i; --i )
__asm__ __volatile__("isb\n");
// _mm_pause();
double ns = (int64_t)duration_cast<nanoseconds>(
high_resolution_clock::now() - start ).count() / (double)PAUSE_ROUNDS;
cout << ns << endl;
}
 
 
 
--
 
7-77-777
Evil Sinner!
Branimir Maksimovic <branimir.maksimovic@gmail.com>: Sep 25 05:33PM


> I get
 
> 30.7635
 
> (Core i9 9900K 5GHz
 
bmaxa@Branimirs-Air News % ./a.out
9.14544
 
M1 processor. (with code modification to compile)
 
 
 
--
 
7-77-777
Evil Sinner!
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)