Monday, December 10, 2018

Digest for comp.lang.c++@googlegroups.com - 20 updates in 6 topics

Paul <pepstein5@gmail.com>: Dec 10 01:55PM -0800

Suppose that we want to check if an "enough" condition is satisfied.
Is there a way to use library count functions efficiently -- is this taken
care of by the compiler?
 
I know that sounds vague. I'll explain the type of thing I mean.
Suppose I have a large vector<int> v
and my code is:
if(std::count(v.begin(), v.end(), 7) > 2)
{
//// more code
}
 
Suppose the vector actually has a million occurrences of 7.
Do standard compiler optimizations like -03 on gcc let the count stop
after the third occurrence? Or must time be wasted counting the 4th, 5th
... occurrence of 7?
 
How about the count member function of unordered_multiset.
If s is a multiset,
does the code:
if(s.count(7) > 15)
{
//more code
}
need to count every instance of 7 or can it just execute the loop as soon
as it has found 16 occurrences?
 
Thank you,
 
Paul
Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 10 10:34PM

On Mon, 2018-12-10, Paul wrote:
> }
> need to count every instance of 7 or can it just execute the loop as soon
> as it has found 16 occurrences?
 
If everything relevant is visible to the compiler, in theory it could
be optimized. But I wouldn't count on it.
 
If it's important to you, write your own at_least() algorithm.
 
/Jorgen
 
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
Paul <pepstein5@gmail.com>: Dec 10 03:02PM -0800

On Monday, December 10, 2018 at 10:34:11 PM UTC, Jorgen Grahn wrote:
> be optimized. But I wouldn't count on it.
 
> If it's important to you, write your own at_least() algorithm.
 
> /Jorgen
 
I'm not sure how to proceed in that case. I'm doing the Boyer-Moore majority
problem as follows. If a vector of ints has an element that occurs
more than half the time, output that number, otherwise output 0.5.
There's a standard algorithm to do this by incrementing and decrementing
a counter. But I'm pretending I don't know that, and trying to do
the problem time-efficiently via data structures instead.
 
My code is below but I don't want the multiset to do so much unnecessary
counting. Basically, I don't know how to code an at_least function for
a multiset. Any ideas gratefully received. Thanks. Paul
 
double DataStructuresMajority(const std::vector<int>& vec)
{
const double noMajority = 0.5;
std::unordered_multiset<int> duplicates(vec.begin(), vec.end());
for(std::unordered_set<int>::const_iterator iter = duplicates.begin(); iter!= duplicates.end(); ++iter)
if(duplicates.count(*iter) > vec.size()/2)
return *iter;
 
return noMajority;
}
"Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Dec 10 02:09PM -0800

On 12/7/2018 7:41 PM, Chris M. Thomasson wrote:
 
> Fwiw, here is a hyper simple Relacy unit test:
 
> // I love this, been using it for years...
> https://github.com/dvyukov/relacy
[...]
 
Btw, has anybody here even tried Relacy? It is header only... :^)
woodbrian77@gmail.com: Dec 09 08:58PM -0800

On Friday, December 7, 2018 at 1:08:25 AM UTC-6, David Brown wrote:
> > could tell if #import support has been preserved.
 
> It is highly unlikely to be removed - simply because no one would
> prioritise making the change.
 
I installed Gcc 9 now and am happy to say that it
still supports #import.
 
> That does not mean it is a good idea to use it.
 
"All the world is just a narrow bridge. The most
#important thing is not to be afraid." Rebbe Nachman
David Brown <david.brown@hesbynett.no>: Dec 10 08:22AM +0100

>> prioritise making the change.
 
> I installed Gcc 9 now and am happy to say that it
> still supports #import.
 
That is as expected (do you even /read/ what I write in these posts?) -
and is equally irrelevant.
 
 
>> That does not mean it is a good idea to use it.
 
> "All the world is just a narrow bridge. The most
> #important thing is not to be afraid." Rebbe Nachman
 
Out-of-context quotations do not justify irrational decisions.
Juha Nieminen <nospam@thanks.invalid>: Dec 10 08:04AM

> You get one set of "Defines for B", and one set of "Defines for A". You
> may have to be careful about the ordering of your defines and includes
> (if you can't avoid the circular inclusions), but it will work fine.
 
The problem is that, in general, recursive inclusion is an error, and will
usually cause obscure compiler errors that are hard to track. With complex
chains of inclusions it may happen inadvertently.
 
If a.h includes b.h, and depends on something from the latter, and then
b.h directly or indirectly includes a.h, maybe through a longer chain
of includes, now b.h or something along this chain depends on something
declared in a.h, but the include guard is making everything in a.h to
be skipped, so whatever needs that something from a.h isn't getting it,
and you'll get a compiler error for an undefined name.
 
If you want a clear error message like "this header file is being
recursively included", you need additional #defines to check for this.
David Brown <david.brown@hesbynett.no>: Dec 10 11:34AM +0100

On 10/12/18 09:04, Juha Nieminen wrote:
 
> The problem is that, in general, recursive inclusion is an error, and will
> usually cause obscure compiler errors that are hard to track. With complex
> chains of inclusions it may happen inadvertently.
 
Yes, recursive inclusion is likely to be a design flaw. And it may
cause odd errors. But I'd be surprised to see it turn up often.
 
And standard include guards handle it as well as other mechanisms.
 
> declared in a.h, but the include guard is making everything in a.h to
> be skipped, so whatever needs that something from a.h isn't getting it,
> and you'll get a compiler error for an undefined name.
 
That is true of any kind of recursive import mechanism.
 
> If you want a clear error message like "this header file is being
> recursively included", you need additional #defines to check for this.
 
Ah, so what you were saying is that the standard include guards don't
make it easy to spot this kind of recursion and warn you about it.
Neither does gcc #import. But both methods give you the expected results.
Tim Rentsch <txr@alumni.caltech.edu>: Dec 10 04:55AM -0800

> maybe I should switch to using include guards. In the
> past I had more include files, but now just have a few,
> so switching to include guards would be easy.
 
To me the (implicit) question here seems like a no-brainer.
It probably cost you more time and effort to do the research
and post here about it than it would have just to change to
using include guards. The main advantage of using include
guards is you know they are going to work and you'll never
have to think about them or wonder if they might be causing
problems. The main advantage of #pragma once is ... what?
Unless there are very particular motivating circumstances,
using #pragma once seems like all potential downside with
negligible upside. Given that the energy barrier to getting
rid of the existing #pragma's is low, just do it and be done
with it. Save your brain for more important matters.
 
By the way I think the usual #ifndef/#define...
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)