Friday, December 14, 2018

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

Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 14 12:13AM

On Thu, 13 Dec 2018 22:07:38 +0000
> > take all the arguments and apply the function it is wrapping with all
> > but the last one.
 
> Ah, but the parameters are variadic in number. So that won't work.
 
I am not entirely sure of what you are doing, but since your functions
are variadic I think the earlier suggestion of constructing a tuple and
applying it with an index list is the way to go.
 
The code below is a suggestion which does that. If you are using C++14
rather than C++11 you can construct the index list with a constexpr
function instead of a template struct. You will need to add in type
deduction on the return value if you want to apply a function with
other than a void return type.
 
In the code below, three arguments are applied to a lambda expression
taking two arguments.
 
******************
 
#include <tuple>
#include <utility>
#include <cstddef>
#include <iostream>
 
template<std::size_t... indices>
struct IndexList {
typedef IndexList<indices...> Type;
};
 
template<std::size_t count, std::size_t... indices>
struct MakeIndexList: public MakeIndexList<count - 1, count - 1,
indices...> {};
 
template<std::size_t... indices>
struct MakeIndexList<0, indices...>: public IndexList<indices...> {};
 
template <class Func, class Tuple, std::size_t... indices>
void apply_helper(Func&& func, Tuple&& t, IndexList<indices...>) {
func(std::get<indices>(std::forward<Tuple>(t))...);
}
 
template <class Func, class... Args>
void apply_except_last(Func&& func, std::tuple<Args...>&& t) {
typedef typename MakeIndexList<(sizeof...(Args)) - 1>::Type List;
apply_helper(std::forward<Func>(func), std::move(t), List());
}
 
template <class Func, class... Args>
void call_except_last(Func&& func, Args&&... args) {
apply_except_last(std::forward<Func>(func),
std::make_tuple(std::forward<Args>(args)...));
}
 
int main () {
auto callback = [](int a, int b) {std::cout << a + b << std::endl;};
call_except_last(callback, 5, 6, 7);
}
User <aitor.folgoso@googlemail.com>: Dec 14 04:15AM -0800

Thanks for your help,
 
the Alf's parameter pack solution worked, but the problem is another: the template and parameter pack works only with indices produces at compile time. The problem is what happens when argument's count isn't a constant but a variable:
 
int numberOfArgumentsToRemove = 1;
template<Args... args> invoke()
 
for that the templates doesn't work. But it's ok, maybe with variants and other mechanisms is possible.
 
Am Freitag, 14. Dezember 2018 01:13:26 UTC+1 schrieb Chris Vine:
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Dec 14 01:41PM

On Fri, 14 Dec 2018 04:15:14 -0800 (PST)
> template<Args... args> invoke()
 
> for that the templates doesn't work. But it's ok, maybe with variants and
> other mechanisms is possible.
 
Ah, I hadn't seen Alf's coded solution until after I had posted mine.
Either it hadn't arrived on my news server or I missed it. Mine is
slightly more efficient as it avoids creating any intermediate
lvalues. In fact with -O1 and above
 
call_except_last(callback, 5, 6, 7)
 
produces the same object code as
 
callback(5, 6);
 
and it should do so with non-trivial argument types as well (not
tested).
 
On re-reading my version, it would be clearer to combine
call_except_last() and apply_except_last() into a single function (and
in case you were wondering, there is no lifetime problem with this for
the temporary tuple, as its lifetime is bound to the reference 't'):
 
template <class Func, class... Args>
void call_except_last(Func&& func, Args&&... args) {
typedef typename MakeIndexList<sizeof...(Args) - 1>::Type List;
auto&& t = std::make_tuple(std::forward<Args>(args)...);
apply_helper(std::forward<Func>(func), std::move(t), List());
}
 
On your latest question, you can use my/Alf's approach if the number of
arguments to pass to the target function is known at compile time. If
you cannot deduce that, then one alternative approach would be to have a
target function taking a std::vector or std::list object and construct
the vector or list recursively for the required number of iterations as
you peal arguments off, or to arrange the function somewhat like
std::printf.
 
However I have real difficulty in understanding your use case.
User <aitor.folgoso@googlemail.com>: Dec 14 11:42AM -0800

> However I have real difficulty in understanding your use case.
 
The idea is to implement the Qt signals & slots, delegates. I give you an example:
 
 
class Emitter {
public: /** signals: **/
void clicked(int x, bool status, int other);
};
 
class Receptor {
public:
void buttonClicked(int value, bool status){
qDebug() << "buttonClicked" << value << status;
}
};
 
int main(){
Emitter* emitter = new Emitter;
Receptor* receptor = new Receptor;
 
// the emitter save the objects to be called later
connect(emitter, &Emitter::clicked, receptor, &Receptor::buttonClicked);
 
...
// later in code
 
// our function is emitted and the connected functions must be called
emitter->clicked();
 
// here is the problem, I can know that one argument must be omitted, but
// there is no way to remove it with the parameter pack
 
}
jameskuyper@alumni.caltech.edu: Dec 14 12:54PM -0800

On Friday, December 14, 2018 at 2:42:38 PM UTC-5, User wrote:
 
> // here is the problem, I can know that one argument must be omitted, but
> // there is no way to remove it with the parameter pack
 
> }
 
According to <http://doc.qt.io/qt-5/signalsandslots.html>,
"a slot may have a shorter signature than the signal it receives because it can ignore extra arguments".
Juha Nieminen <nospam@thanks.invalid>: Dec 14 07:51AM

>> If the size is fixed, just use a plain old C array.
 
> why not std::array? its a better version of c array? nothing to lose ,
> only to get more, isnt it?
 
Neither a C array nor std::array offer almost any of the same member
functions as std::vector does. Also, they will construct every single
element in the array, even if you don't want to. There's no trivial
way of destructing the elements before the whole array is destroyed.
(Sure, you can explicitly call the destructor of an element, but
then you'll have a destructed element directly accessible. You would
have to make sure to construct it again if you want to reuse it.)
 
Also, in both cases you need to know the size at compile time, which
might not always be the case.
 
Using an std::vector with a reserved size ought to be fine (especially
if you only know the size at runtime), as long as you don't call any of
the member functions that change the size of its allocation. These are
quite easy to avoid (ie. push_back(), resize(), etc.)
JiiPee <no@notvalid.com>: Dec 14 11:20AM

On 14/12/2018 07:51, Juha Nieminen wrote:
>> only to get more, isnt it?
> Neither a C array nor std::array offer almost any of the same member
> functions as std::vector does.
 
yes I know array does not fit here, but just that std::array is better
than c-array imo, as you get object orianted benefits for free
 
> Using an std::vector with a reserved size ought to be fine (especially
> if you only know the size at runtime),
 
yes I know, I carefully take care of the size myself. Its meant to be
fixed size buffer (possibly increasing at some point, but I manage that)
 
> as long as you don't call any of
> the member functions that change the size of its allocation. These are
> quite easy to avoid (ie. push_back(), resize(), etc.)
 
but even push_back(), resize()should be fine as long as the capacity is
enough to do that. And thats why I wanted vector as I could normally use
push_back. if capacity is big, then push_back does not reallocate
JiiPee <no@notvalid.com>: Dec 14 11:23AM

On 13/12/2018 18:59, Lynn McGuire wrote:
>>> delete methods.
 
>> If the size is fixed, just use a plain old C array.
 
> I was thinking that also.
 
I prefer vector because I get all the benefits of vector easy usage
(pushback, remove, clear, insert). array does not have there.. so its
difficult to use. how do you easily add an element in the middel of an
array? :)
JiiPee <no@notvalid.com>: Dec 14 11:25AM

On 13/12/2018 18:59, Lynn McGuire wrote:
 
>> /Leigh
 
> That is specifically what the op asked for.  The op wants the vector
> to contain the max memory usage at startup.
 
Ye it has like 1000 slots to start with. But the main point I wanted
vector is because its easy to use (add element in the middle, pushback,
etc). array is not easy to use.
JiiPee <no@notvalid.com>: Dec 14 11:33AM

> True - but not necessarily a problem.
 
true, its not big issue here
 
> JiiPee has only expressed a desire
> to avoid unnecessary memory allocation.
 
yes. thats the main point here. And to be able to use vector which is
easy to use.
 
> It's not clear whether he has
> any need to avoid unnecessary default constructor calls.
 
I dont need to avoid....
 
> He hasn't said
> anything about the type of data he's storing -
 
objects with possible bigger data inside them. so quite big objects. Its
game programming, so in a tight for loop I dont want to do any allocations.
It should be able to survive also even if small images added there
inside objects I guess.
 
> for all we know, it might
> be a type with a trivial default constructor. Even if it's not trivial,
> it might be of neglible importance.
 
yes, not important... as it would be done only once at the beginning of
the program.
 
jameskuyper@alumni.caltech.edu: Dec 14 03:59AM -0800

On Friday, December 14, 2018 at 6:33:17 AM UTC-5, JiiPee wrote:
> the program.
 
> > There might be other reasons why std::array<> isn't suitable for his
> > application, but that isn't necessarily one of them.
 
Judging from your other three most recent messages, there are indeed
many reasons why std::array<> isn't suitable - but as I said, this isn't
one of them.
 
I've argued that clear(), by reason of invalidating all pointers,
references, and iterators, is permitted to do a reallocation, even after
a reserve. The same is true even if you erase() only the first element
of the vector. Others disagree - but regardless of whether I'm right
about those points, those are the only two operations that have
permission to reallocate after a call to reserve(), until you do an
insert that pushes size() above the current value of capacity(). If you
do the reserve() immediately after creating the vector, I would think
that should be sufficient protection against reallocation. If not, your
only alternative is to create a custom container that reallocates only
at the times you want it to do so.
James Kuyper <jameskuyper@alumni.caltech.edu>: Dec 14 07:06AM -0500

On 12/14/18 06:59, jameskuyper@alumni.caltech.edu wrote:
...
> of the vector. Others disagree - but regardless of whether I'm right
> about those points, those are the only two operations that have
> permission to reallocate after a call to reserve(), until you do an
 
That didn't come out right - I should have replaced "those are the only
two operations that" with "no other operations".
scott@slp53.sl.home (Scott Lurndal): Dec 14 02:02PM


>Neither a C array nor std::array offer almost any of the same member
>functions as std::vector does. Also, they will construct every single
>element in the array, even if you don't want to.
 
Not necessarily. I'd make the C array an array of pointers to
objects.
 
I know that some people believe pointers in C++ should be
avoided. I prefer to think that if you don't understand
how to use them properly, you shouldn't be programming in
a language that supports them.
Martijn van Buul <pino@dohd.org>: Dec 14 02:54PM

* Alf P. Steinbach:
> that you can use to /find/ reliable information, or that you can /test/
> yourself, but that you absolutely should not rely on directly by default
> without at least reasoning about it, checking that it makes sense.
 
<delurk>
StackOverflow is broken by design, in that the "right answer" gets picked
by the person who is least qualified to do so (namely: the person who
asked the question). It confuses "This answers was useful to me" with
"this is the right answer".
 
That said, I don't think there's an easy way to organize a site like
this that isn't flawed one way or the other. For example, this newsgroup is
a fond of useful information, but that doesn't mean you can trust everything
at face value either.
 
<delurk>
--
Martijn van Buul - pino@dohd.org
JiiPee <no@notvalid.com>: Dec 14 02:55PM

> If you
> do the reserve() immediately after creating the vector, I would think
> that should be sufficient protection against reallocation.
 
me also, but also not 100% sure.. thats why I asked :). And I would need
100% assurance...
 
> If not, your
> only alternative is to create a custom container that reallocates only
> at the times you want it to do so.
 
Yes, althought would prefer not to do this at this point... I have other
more important things... thats why would rather use vector if possible.
JiiPee <no@notvalid.com>: Dec 14 02:58PM

On 14/12/2018 14:02, Scott Lurndal wrote:
> I prefer to think that if you don't understand
> how to use them properly, you shouldn't be programming in
> a language that supports them.
 
 
I see it a safety issue , like in work. That if there is a risk then to
avoid the risk. So if there is another way to do (other than pointers) I
would prefer that. I think Bjarne also talked liked that. So imo its not
about how skillfull C++ programmer I am, its just that regardless of my
skill I would avoid risks.
Real Troll <real.troll@trolls.com>: Dec 14 11:22AM -0400

On 14/12/2018 14:54, Martijn van Buul wrote:
> by the person who is least qualified to do so (namely: the person who
> asked the question). It confuses "This answers was useful to me" with
> "this is the right answer".
 
There is no such thing as right answer or wrong answer. The OP decides
what is right for him or her. The feature of marking something is right
should be removed because, as you say, it is subjective.
 
> this that isn't flawed one way or the other. For example, this newsgroup is
> a fond of useful information, but that doesn't mean you can trust everything
> at face value either.
Do you mean to say discussion about religion? If so, I agree, it is
fake and it should be banned from these newsgroups but we don't have a
moderator and there was a stupid chap called Richard who was spending
all his time trying to open a closed moderated newsgroup and he failed
in that project. So religion is going to remain here, unfortunately.
 
 
JiiPee <no@notvalid.com>: Dec 14 03:27PM

On 14/12/2018 15:22, Real Troll wrote:
> decides what is right for him or her.  The feature of marking
> something is right should be removed because, as you say, it is
> subjective.
 
I think there is "best" answer many times objectively speaking. Like if
somebody says "should I put all my code in the main() function?" and
then somebody says "no"... that surely is best answer :).
 
But from our point of view sure its better it is objectively speaking
best answer.
 
> moderator and there was a stupid chap called Richard who was spending
> all his time trying to open a closed moderated newsgroup and he failed
> in that project.  So religion is going to remain here, unfortunately.
 
I like groups have some freedom though. Even though I dont also like
religion talk here (even though I believe), as its not the right forum,
then if somebody little bit talks religion here and there.... I would
not ban them :). We are humans anyway... and its difficult to keep
conversation 100% purely in programming always. Also couple of non-topic
messages here and there does not bother me, I can skil them easily. But
yes, if its all the time sending them, then I agree better ban.
Bo Persson <bop@gmb.dk>: Dec 14 06:16PM +0100

On 2018-12-14 15:55, JiiPee wrote:
>> that should be sufficient protection against reallocation.
 
> me also, but also not 100% sure.. thats why I asked :). And I would need
> 100% assurance...
 
You have gotten the correct answer - that it *is* guaranteed - supported
by quotes from the standard.
 
You have also gotten posts saying "I don't believe that".
 
This is probably as close as you get by asking random strangers on the
internet.
 
Bet you will not get 100% agreement on "Is Elvis still alive?" either. :-)
 
 
Bo Persson
jameskuyper@alumni.caltech.edu: Dec 14 09:19AM -0800

On Friday, December 14, 2018 at 9:58:31 AM UTC-5, JiiPee wrote:
> would prefer that. I think Bjarne also talked liked that. So imo its not
> about how skillfull C++ programmer I am, its just that regardless of my
> skill I would avoid risks.
 
There's no way to completely avoid risk, and some risks are worth
taking. You said the objects you're working with are large. A container
of pointers to large objects would be much smaller and correspondingly
less time-consuming to rearrange than a container of the objects
themselves, and you might be able to mitigate most of the risks by using
some variety of smart pointer.
JiiPee <no@notvalid.com>: Dec 14 05:56PM

On 14/12/2018 17:16, Bo Persson wrote:
> Bet you will not get 100% agreement on "Is Elvis still alive?" either. :-)
 
 
haha. I think he died...
 
There are conspiricies for sure, but this is propably not one of them
(no evidence).
jmani.20@gmail.com: Dec 13 10:27PM -0800

Hi,
 
We are using MersenneTwister.h V1.1 C++ class MTRand implemented by Richard J. Wagner.
 
We need the clarifications on the below,
 
1. Is there any newer version available after MersenneTwister.h V1.1?
2. Is there any SV issues reported on this version? If so,
3. What is the alternative?
Note: For the current being we can't move to the ++11 standard mersenne_twister_engine.
 
 
// MersenneTwister.h
// Mersenne Twister random number generator -- a C++ class MTRand
// Based on code by Makoto Matsumoto, Takuji Nishimura, and Shawn Cokus
// Richard J. Wagner v1.1 28 September 2009 wagnerr@umich.edu
 
// The Mersenne Twister is an algorithm for generating random numbers. It
// was designed with consideration of the flaws in various other generators.
// The period, 2^19937-1, and the order of equidistribution, 623 dimensions,
// are far greater. The generator is also fast; it avoids multiplication and
// division, and it benefits from caches and pipelines. For more information
// see the inventors' web page at
// http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
 
// Reference
// M. Matsumoto and T. Nishimura, "Mersenne Twister: A 623-Dimensionally
// Equidistributed Uniform Pseudo-Random Number Generator", ACM Transactions on
// Modeling and Computer Simulation, Vol. 8, No. 1, January 1998, pp 3-30.
 
// Copyright (C) 1997 - 2002, Makoto Matsumoto and Takuji Nishimura,
// Copyright (C) 2000 - 2009, Richard J. Wagner
// All rights reserved.
//
 
 
Thanks,
Mani
"Öö Tiib" <ootiib@hot.ee>: Dec 14 12:50AM -0800

> We are using MersenneTwister.h V1.1 C++ class MTRand implemented by Richard J. Wagner.
 
Who are "we"?
 
 
> We need the clarifications on the below,
 
> 1. Is there any newer version available after MersenneTwister.h V1.1?
> 2. Is there any SV issues reported on this version?
 
With questions about every particular product it is better idea
to contact the authors not random people on the net. Or why
you think he put his e-mail address into header file?
 
> If so,
> 3. What is the alternative?
> Note: For the current being we can't move to the ++11 standard mersenne_twister_engine.
 
Why? When standard library feature is not available (or is defective)
on platform then next best thing is Boost.
https://www.boost.org/doc/libs/1_69_0/doc/html/boost_random/reference.html#boost_random.reference.generators
 
Boost version often works on C++98 compiler, is usually
well-tested and supported and resulting usage code is
easier to migrate to standard later since its interface is
close.
Manikandan J <jmani.20@gmail.com>: Dec 14 01:05AM -0800

On Friday, 14 December 2018 14:20:18 UTC+5:30, Öö Tiib wrote:
> well-tested and supported and resulting usage code is
> easier to migrate to standard later since its interface is
> close.
 
Thanks for the update.
 
The intention is to use the generator which doesn't have any vulnerability issues.
 
it was last updated 9 years ago. If any vulnerability there, cannot continue with this.
David Brown <david.brown@hesbynett.no>: Dec 14 11:07AM +0100

On 14/12/18 10:05, Manikandan J wrote:
 
>> Why? When standard library feature is not available (or is
>> defective) on platform then next best thing is Boost.
>> https://www.boost.org/doc/libs/1_69_0/doc/html/boost_random/reference.html#boost_random.reference.generators
 
Boost version often works on C++98 compiler, is usually
> vulnerability issues.
 
> it was last updated 9 years ago. If any vulnerability there, cannot
> continue with this.
 
And you think that posting to a general C++ discussion group is the best
way to do a security audit on old libraries?
 
If the original code was posted as part of a live, on-going project then
look on that project's side - there will be issue lists, updated
development, etc.
 
If the original code was posted "as is", then you got it "as is" - and
it is /your/ responsibility to do a security audit, and fix the code if
necessary.
 
If neither of these suit, then you need a different random number
generator library. Boost is usually a fine starting point. Or you can
write one yourself.
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)