Tuesday, January 24, 2017

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

Ramine <toto@toto.net>: Jan 24 03:00PM -0500

Hello...
 
I have compiled the Windows DLLs for DRWLock and DRWLockX with a newer
compiler to ensure that all is correct, and finally i have tested
thoroughly my C++ synchronization objects library for Windows and Linux
and i think it is more stable and fast, and it has no memory leak.
 
Please download my updated C++ synchronization objects library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Lynn McGuire <lynnmcguire5@gmail.com>: Jan 23 07:03PM -0600

"Bjarne Stroustrup mines generic programming for a better C++"
http://www.infoworld.com/article/3155288/application-development/bjarne-stroustrup-mines-generic-programming-for-a-better-c.html
 
"Bjarne Stroustrup is on a mission to simplify generic programming."
 
"In a recently published paper titled "Concepts: The Future of Generic Programming," Stroustrup makes the case for concepts as a
foundation for generic programming. In concepts, Stroustrup sees the solution to the interface specification problem that has long
dogged C++, the language he founded more than 35 years ago."
 
Lynn
Real Troll <real.troll@trolls.com>: Jan 23 09:29PM -0400

On 24/01/2017 01:03, Lynn McGuire wrote:
> "Bjarne Stroustrup mines generic programming for a better C++"
> http://www.infoworld.com/article/3155288/application-development/bjarne-stroustrup-mines-generic-programming-for-a-better-c.html
 
> "Bjarne Stroustrup is on a mission to simplify generic programming."
 
OK tell us what is generic programming? Also tell us what other types
of programming are there in the wild apart from generic programming?.
 
Thank you.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 24 02:52AM +0100

On 24.01.2017 02:29, Real Troll wrote:
 
>> "Bjarne Stroustrup is on a mission to simplify generic programming."
 
> OK tell us what is generic programming? Also tell us what other types
> of programming are there in the wild apart from generic programming?.
 
See e.g. <url:
https://en.wikibooks.org/wiki/C%2B%2B_Programming/Programming_Languages/Paradigms>
 
Cheers & hth.,
 
- Alf
JiiPee <no@notvalid.com>: Jan 24 07:42AM

On 24/01/2017 01:03, Lynn McGuire wrote:
> "Bjarne Stroustrup is on a mission to simplify generic programming."
 
 
thats good. I dont like too complex languagages. I know, Bjarne has
always the desire to make things more simple.
David Brown <david.brown@hesbynett.no>: Jan 24 08:51AM +0100

On 24/01/17 08:42, JiiPee wrote:
>> "Bjarne Stroustrup is on a mission to simplify generic programming."
 
> thats good. I dont like too complex languagages. I know, Bjarne has
> always the desire to make things more simple.
 
As he said himself, "I have always wished for my computer to be as easy
to use as my telephone; my wish has come true because I can no longer
figure out how to use my telephone"
Daniel <danielaparker@gmail.com>: Jan 24 09:33AM -0800

On Monday, January 23, 2017 at 8:03:46 PM UTC-5, Lynn McGuire wrote:
> "Bjarne Stroustrup mines generic programming for a better C++"
> http://www.infoworld.com/article/3155288/application-development/bjarne-stroustrup-mines-generic-programming-for-a-better-c.html
 
Personally, I'd rather have date, big_integer, decimal, strtod_l, a proper string class ...
 
Daniel
Daniel <danielaparker@gmail.com>: Jan 24 09:35AM -0800

On Tuesday, January 24, 2017 at 2:42:55 AM UTC-5, JiiPee wrote:
> On 24/01/2017 01:03, Lynn McGuire wrote:
> > "Bjarne Stroustrup is on a mission to simplify generic programming."
 
> Bjarne has always the desire to make things more simple.
 
If that were that case, why do we have to implement both == and !=, < and >=?
 
Daniel
Manfred <noname@invalid.add>: Jan 24 08:47PM +0100

On 01/24/2017 06:33 PM, Daniel wrote:
>> "Bjarne Stroustrup mines generic programming for a better C++"
>> http://www.infoworld.com/article/3155288/application-development/bjarne-stroustrup-mines-generic-programming-for-a-better-c.html
 
> Personally, I'd rather have date, big_integer, decimal, strtod_l, a proper string class ...
I would like these too (although IMHO strtod_l should come from C and
then transparently included into C++), but I do not see why these should
exclude concepts.
As far as I can see concepts can be an excellent thing, at the same time
I can see that it can be hard to design them right for the language.
 
 
Ralf Goertz <me@myprovider.invalid>: Jan 24 04:50PM +0100

Hi,
 
why is it necessary to declare the operator()() in a comparison object
const in order to find elements in const std::set<T>?:
 
 
#include <set>
 
struct cmp_int {
bool operator()(const int &x,const int &y) const //const necessary
{
return x>y;
}
};
 
int main()
{
const std::set<int,cmp_int> s={{47,11}};
if (s.find(815)!=s.end()) return 1;
return 0;
}
 
Shouldn't the std::set<int> be happy with the fact that both parameters
are const references? I guess the answer is going to be that cmp_int is
part of the const declaration and must therefore be const. But IMHO
cmp_int is not part of the *data* that the std::set holds. The const
declaration is not necessary when the std::set itself is non const. So I
could flip the order used for the comparison object every other call,
which would be devastating for both const and non const std::set.
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 24 04:24PM

On Tue, 24 Jan 2017 16:50:09 +0100
> itself is non const. So I could flip the order used for the
> comparison object every other call, which would be devastating for
> both const and non const std::set.
 
I didn't even know that was a requirement, but it seems a sensible
one so as to maintain referential transparency: that is, so that
ordering is correctly maintained. If the operator could mutate the
state of the object of type cmp_int of which it is a member, different
invocations of the operator with the same arguments could yield
different results. Your cmp_int type does not have non-static data
members; but it might have.
 
Chris
Ralf Goertz <me@myprovider.invalid>: Jan 24 05:54PM +0100

Am Tue, 24 Jan 2017 16:24:34 +0000
> invocations of the operator with the same arguments could yield
> different results. Your cmp_int type does not have non-static data
> members; but it might have.
 
But that's exactly my point. If cmp_int were something like this:
 
struct cmp_int {
static bool counter;
bool operator()(const int &x,const int &y) const
{
counter=!counter;
return (counter ? x < y : x > y);
}
};
 
it would compile for const and non const variables of type
std::set<int,cmp_int>. So I don't see how the const declaration of the
operator helps. So why is it necessary?
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jan 24 06:31PM +0100

On 24.01.2017 16:50, Ralf Goertz wrote:
 
> why is it necessary to declare the operator()() in a comparison object
> const in order to find elements in const std::set<T>?:
 
The short answer, if I could find this requirement in the standard,
would be that the standard requires it. That's fundamentally different
from the requirement being imposed by a given implementation. It would
mean that all standard-conforming implementations had this requirement.
 
I can't find it though, but it seems reasonable that it's there.
 
Assuming it is, then regarding the /rationale/ that rule supports an
implementation where the comparison object is directly part of the
`std::set` object, instead of being dynamically allocated and just
referred to. With the comparison object as a direct part it's `const`
when the `std::set` is const. And in particular it's `const`, so that
only its `const` members can be used, in a call of a `const` `std::set`
member function such as `std::set::find`.
 
[snip]
 
 
Cheers & hth.,
 
- Alf
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jan 24 07:10PM

On Tue, 24 Jan 2017 17:54:25 +0100
> Am Tue, 24 Jan 2017 16:24:34 +0000
> schrieb Chris Vine <chris@cvine--nospam--.freeserve.co.uk>:
[snip]
 
> it would compile for const and non const variables of type
> std::set<int,cmp_int>. So I don't see how the const declaration of the
> operator helps. So why is it necessary?
 
So far as the ability of a const member function to mutate static
member data is concerned, or its ability to mutate global or static
data at namespace scope as well for that matter, I guess you just have
to accept that as a matter of language specification in C++ 'const' does
not mean 'pure'.
 
But on your larger point about std::set, on reflection I think you are
right. The requirement to maintain referential transparency for the
comparison operator type should apply irrespective of whether the
std::set object is const or not. There may be an argument that for a
non-const set, the comparison operator should be able to arbitrarily
mess around with ordering, but that doesn't seem a very good argument.
This may be just a miscellaneous wart in C++.
 
Chris
"Adam C. Emerson" <azure@fox.blue>: Jan 24 12:01AM

On 2017-01-23, Christopher J. Pisz <cpisz@austin.rr.com> wrote:
[snip]
> so, std::map is implemented as a tree and std::unordered_map is
> implemented as a hastable?
 
> What are the differences, advantages, etc?
 
Well! The main answer is implicit in the name. std::map, as a tree,
can be traversed in order. What do I mean by order?
 
One of the parameters to std::map is a functor class that, when called
with two Keys, will return true if the first is less than the
second. By default this functor is std::less specialized on the key
type.
 
When you iterate over a std::map, you traverse the elements in order
from Least to Greatest. std::map inserts or looks up elements in
logarithmic time. It's implemented as a tree. A Red-Black tree
specifically in GNU libstdc++ and CLang libc++.
 
std::unordered_map is a hash table. Instead of a functor telling
whether one key is less than another, it takes one functor that hashes
objects (taking an object it returns a value convertible to
std::size_t) and another defining equivalence that returns true if two
supplied objects are equal.
 
By default it uses std::hash and std::equal_to specialized on the Key
type. std::unordered_map does lookups and insertions, on average, in
constant time. If your hash function is really bad or your object
distribution is really pathological, it degrades to linear. it does
/not/ traverse objects from least to greatest and there's basically
nothing useful you can say about the order of traversal except that
you do traverse all objects.
 
If you don't need ordered traversal, you likely want a
std::unordered_map. As always, if performance is critical, benchmark
your use-case with your library.
 
If you wish to avoid allocations and you can insert your items in
order, you may want boost::container::flat_map.
 
If the entire set of keys will be known at compile time, consider
using a Perfect Hash Function like those generated by gperf.
"Öö Tiib" <ootiib@hot.ee>: Jan 24 07:48AM -0800

On Tuesday, 24 January 2017 02:03:18 UTC+2, Adam C. Emerson wrote:
 
> If you don't need ordered traversal, you likely want a
> std::unordered_map. As always, if performance is critical, benchmark
> your use-case with your library.
 
One other point worth mentioning here is the automatic rehashing.
The rebalance of map is so cheap that it is hard to notice.
Rehashing of unordered_map is more pricy. So unordered_map
is likely faster in average but single insert now or then can
take noticeable lag. One has to consider that when testing
performance since sometimes uniform performance is more
important than average efficiency.
Ben Bacarisse <ben.usenet@bsb.me.uk>: Jan 24 04:05PM

>> std::unordered_map. As always, if performance is critical, benchmark
>> your use-case with your library.
 
> One other point worth mentioning here is the automatic rehashing.
 
You don't necessarily have to rehash when the table size changes if you
store the hash in the table. You have to /re-key/ the items, but that
can be as cheap as a mask operation (and of course they move to a larger
table).
 
<snip>
--
Ben.
ruben safir <ruben@mrbrklyn.com>: Jan 24 07:35AM -0500

On 12/19/2016 09:30 AM, Scott Lurndal wrote:
> Have a static method in class reader as your thread entry point
> taking a single void * argument.
 
 
how is that different from using an Lamda
ruben safir <ruben@mrbrklyn.com>: Jan 24 07:27AM -0500

On 01/23/2017 10:17 AM, Chris Vine wrote:
> I used to think that this newsgroup had enough sensible on topic
> posting about C++ to survive all this. Now I am not so sure.
 
it is probably still the best venue for C++ expertise and discussion.
the alternative to open access if moderated forum that track you and are
a PIA to use.
 
This is much better. But good use of /dev/null is needed, at least for me.
 
Reuvian
fl <rxjwg98@gmail.com>: Jan 23 03:49PM -0800

Hi,
 
Thanks Riccardo and Jorgen answering my previous question.
 
The smctc library is built OK now. When I compile an example .cpp file with the
lib, it has a new error, i.e. "'max' was not declared in this scope".
 
It is really strange to me. Is the example code
(../../include/sampler.hh) wrong on using function max()?
 
Or my build command line, which is copied and modified (adding a -I for GSL
header files), is incorrect?
 
 
Thanks,
 
 
.....................
~/workspace/smctc-1.0/examples/pf$ g++ -I/home/jeff/gsl/include -I ../../include -c pfexample.cc pffuncs.cc
In file included from ../../include/smctc.hh:104:0,
from pfexample.cc:1:
../../include/sampler.hh: In instantiation of 'double smc::sampler<Space>::IterateEss() [with Space = cv_state]':
../../include/sampler.hh:308:15: required from 'void smc::sampler<Space>::Iterate() [with Space = cv_state]'
pfexample.cc:36:23: required from here
../../include/sampler.hh:338:24: error: 'max' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
dMaxWeight = max(dMaxWeight, pParticles[i].GetLogWeight());
^
In file included from /usr/include/c++/5/bits/char_traits.h:39:0,
from /usr/include/c++/5/ios:40,
from /usr/include/c++/5/ostream:38,
from /usr/include/c++/5/iostream:39,
from ../../include/smctc.hh:99,
from pfexample.cc:1:
/usr/include/c++/5/bits/stl_algobase.h:265:5: note: 'template<class _Tp, class _Compare> const _Tp& std::max(const _Tp&, const _Tp&, _Compare)' declared here, later in the translation unit
max(const _Tp& __a, const _Tp& __b, _Compare __comp)
fl <rxjwg98@gmail.com>: Jan 23 03:56PM -0800

On Monday, January 23, 2017 at 6:50:01 PM UTC-5, fl wrote:
> from pfexample.cc:1:
> /usr/include/c++/5/bits/stl_algobase.h:265:5: note: 'template<class _Tp, class _Compare> const _Tp& std::max(const _Tp&, const _Tp&, _Compare)' declared here, later in the translation unit
> max(const _Tp& __a, const _Tp& __b, _Compare __comp)
 
Excuse me. I should paste to code having max() in the previous post.
HTH. Thanks,
 
 
 
template <class Space>
double sampler<Space>::IterateEss(void)
{
//Initially, the current particle set should be appended to the historical process.
if(htHistoryMode != SMC_HISTORY_NONE)
History.Push(N, pParticles, nAccepted, historyflags(nResampled));
 
nAccepted = 0;

//Move the particle set.
MoveParticles();
 
//Normalise the weights to sensible values....
double dMaxWeight = -std::numeric_limits<double>::infinity();
for(int i = 0; i < N; i++)
dMaxWeight = max(dMaxWeight, pParticles[i].GetLogWeight());
fl <rxjwg98@gmail.com>: Jan 23 04:00PM -0800

On Monday, January 23, 2017 at 6:50:01 PM UTC-5, fl wrote:
> from pfexample.cc:1:
> /usr/include/c++/5/bits/stl_algobase.h:265:5: note: 'template<class _Tp, class _Compare> const _Tp& std::max(const _Tp&, const _Tp&, _Compare)' declared here, later in the translation unit
> max(const _Tp& __a, const _Tp& __b, _Compare __comp)
 
Sorry, I forgot to paste the include header file.
Is max() a standard cpp library function?
 
 
#ifndef __SMC_SAMPLER_HH
 
#define __SMC_SAMPLER_HH 1.0
 
#include <algorithm>
#include <cstdlib>
#include <iostream>
 
#include "rng.hh"
#include "history.hh"
#include "moveset.hh"
#include "particle.hh"
#include "smc-exception.hh"
JiiPee <no@notvalid.com>: Jan 24 12:03AM

did you include:
#include <algorithm>
?
 
On 23/01/2017 23:56, fl wrote:
JiiPee <no@notvalid.com>: Jan 24 12:07AM

Did you use: std::max()
std is needed.
if not that, are both arguments the same type (both doubles?)?
 
 
On 24/01/2017 00:00, fl wrote:
fl <rxjwg98@gmail.com>: Jan 23 04:30PM -0800

On Monday, January 23, 2017 at 7:07:44 PM UTC-5, JiiPee wrote:
> > #include "moveset.hh"
> > #include "particle.hh"
> > #include "smc-exception.hh"
 
Thanks JiiPee. Your last suggestion solves the problem.
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)