Thursday, December 22, 2016

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

Joseph Hesse <joeh@gmail.com>: Dec 22 04:03PM -0600

The documentation of std::set says that the second optional argument of
a template set instantion should be a function object or a function pointer.
In the example below I am trying to create a set object using a function
pointer.
I compiled the code with:
$ g++ -std=c++11 Set.cpp
and got the compiler error that there was a type mismatch in the second
argument.
Please help.
Thank you,
Joe
 
========================= Set.cpp =============================
#include <iostream>
#include <set>
 
class X
{
private:
int x;
public:
X(int a) : x(a) {}
friend bool Comp(const X &, const X &);
};
 
bool Comp(const X &xobj1, const X &xobj2)
{
return xobj1.x < xobj2.x;
}
 
int main()
{
std::set<X, Comp> SetOfX; // <== use function pointer
 
return 0;
}
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 22 11:25PM +0100

On 22.12.2016 23:03, Joseph Hesse wrote:
> std::set<X, Comp> SetOfX; // <== use function pointer
 
> return 0;
> }
 
The second template argument needs to be a /type/.
 
You could use `decltype(&Comp)` if you feel unsure about function types.
 
When you do this, using a simple freestanding function, you need to pass
it as a constructor argument. That's because a raw function pointer type
doesn't say anything about which function it is. While a class type does
say all there is to know: it's that class' operator().
 
 
Cheers!,
 
- Alf
Joseph Hesse <joeh@gmail.com>: Dec 22 05:16PM -0600

On 12/22/2016 04:25 PM, Alf P. Steinbach wrote:
> say all there is to know: it's that class' operator().
 
> Cheers!,
 
> - Alf
 
Thank you. I should have known that when instantiating a template, the
stuff that goes between < and > have to be types.
std::set<X, bool (*)(const X &, const X &)> SetOfX(Comp);
fixes it when I want to use function pointers.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 22 11:22PM

On 22/12/2016 22:03, Joseph Hesse wrote:
> std::set<X, Comp> SetOfX; // <== use function pointer
 
> return 0;
> }
 
Just add an operator< to your class and forget about the template parameter.
 
/Flibble
legalize+jeeves@mail.xmission.com (Richard): Dec 22 08:51PM

[Please do not mail me a copy of your followup]
 
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> spake the secret code
 
>I've done this so many times in the past, with C++03. But I feel that
>there must be some less unclean modern C++-ish way. Ideas?
 
My question is:
 
Why are you reinventing the wheel?
 
These message cracker macros have already been done in the Windows
headers, MFC and ATL.
 
ATL is now available with Community Edition, so there is no longer a
dollar cost to selecting ATL for use in your program.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 22 11:22PM +0100

On 22.12.2016 21:51, Richard wrote:
>> there must be some less unclean modern C++-ish way. Ideas?
 
> My question is:
 
> Why are you reinventing the wheel?
 
Well I'm not, but I'm reimplementing my wheels from scratch for
umpteen'th time.
 
 
> These message cracker macros have already been done in the Windows
> headers, MFC and ATL.
 
The macros above delegate the cracking (de-serialization, so to speak)
to the Windows C API macros.
 
MFC and as I recall also ATL/WTL use message maps: they're ungood.
 
MFC and ATL do not really ease anything except the basic window
creation, which is a single little job to put together. In exchange for
providing a default implementation of window creation (and at one time,
providing print preview and COM boiler plate code) they impose a steep
programmers' time overhead: one has to do detective work for every other
little detail. MFC suffered from being deliberately dumbed down from the
original AFX framework goals, and from being a 1990's design, while
ATL/WFC suffers from being designed by incompetents, including the goal
of running ActiveX controls in a browser (imagine that idea! shudder!),
even though there's some modern C++ stuff like templating.
 
 
> ATL is now available with Community Edition, so there is no longer a
> dollar cost to selecting ATL for use in your program.
 
I think maybe you mean WTL, which was derived from ATL.
 
Unless they've rebranded, which they sometimes do?
 
 
Cheers!,
 
- Alf
ram@zedat.fu-berlin.de (Stefan Ram): Dec 22 05:29PM

>But amazingly your example code does compile with both g++ and MSVC.
 
I am usually programming against the latest draft, if possible,
and this contains:
 
template <class T = void> struct multiplies;
template <> struct multiplies<void>;
 
. I never really learned templates, but superficially it
resembles a default type of »void«.
ram@zedat.fu-berlin.de (Stefan Ram): Dec 22 08:46PM

>I apologize for having disinformed you.
>I should have qualified very strongly that I was referring to C++11. I
>shall strive to do so in the future. Thank you!
 
It was clear enough for me that you were referring to C++11.
I never felt disinformed during this thread.
"Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Dec 22 09:14PM +0100

On 22.12.2016 18:29, Stefan Ram wrote:
> template <> struct multiplies<void>;
 
> . I never really learned templates, but superficially it
> resembles a default type of »void«.
 
Oh, I only looked at C++11.
 
There's so much, I'd call it idiocy, in the C++17 drafts, and will be in
that standard.
 
And it's not just that it's so meaningless and impractical from the
developer point of view, it's so /arbitrary/, so /unpredictable/,
apparently in support of internal details in some implementation. One
can no longer use common sense to predict what the official language is.
It started for real with C++14 but it's so much worse now.
 
I apologize for having disinformed you.
 
I should have qualified very strongly that I was referring to C++11. I
shall strive to do so in the future. Thank you!
 
 
Cheers!,
 
- Alf
Marcel Mueller <news.5.maazl@spamgourmet.org>: Dec 22 07:52PM +0100

> The method DetermineAutoPilotMode is called at interval. FlightMode and DeviceID are determined at run time and is static through flight. SpaceShipMode and AutoPilotMode are dynamic - i.e change during the flight trajectory. I've scanned a handful of articles on how to restructure a design predicated on switch statements but not sure how the solutions apply to this case. I know switch statements are not necessarily bad but any recommendations on how to restructure this (design patterns ....) would be appreciated.
 
AFAICS you try to model several dependent state machines.
From the performance point of view there is nothing wrong with switch.
But doing this in Spaghetti code is error prone. If you miss to
synchronize one of the mode variables on an unusual mode transition the
system could end up in an inconsistent state, turning into undefined
behavior at least at application level. And if you miss to handle one
combination in one of the sub paths the implementation could be
incomplete, again UB.
 
First of all you should split the different levels of operation into
different functions. This makes the code more readable.
 
Furthermore calling a function /Determine/AutoPilotMode that depends on
AutopilotMode is at least misleading. Actually the implementation is
unstable, because it toggles between Decorrelation and Terminal.
 
DeviceID sound like something that should not be hard coded at all. But
it is not clear from your example what the intention behind DeviceID is.
 
At the next step it could be useful to separate the different state
machines. I.e. Some code controls the SpaceShipMode and provides actions
for state transitions. Another code manages the AutopilotMode including
transitions as well. E.g. it is probably valid to combine AutoPilot Off
with Launch. If you do so, then there is no more need to /determine/ the
AutopilotMode at all. It is just there.
 
Maybe the autopilot handler does not exist at all if it is turned off.
In this case the mode Off is superfluous.
 
 
Just a few suggestions,
 
Marcel
Paavo Helde <myfirstname@osa.pri.ee>: Dec 22 08:29PM +0200

On 22.12.2016 19:13, ruben safir wrote:
>> mutex lock. Any access to data which is concurrently modified needs a
>> mutex lock.
 
> Wouldn't that cause a deadlock condition?
 
Deadlock means that at least 2 threads wait for each other. In your
example there is only one function, called in a single thread only,
which ever waits for anything (the destructor, in the thread join
operations), so there is no possibility of deadlocks.
 
Or alternatively, if you look at the code of sync_canvas_and_input()
then you see that when it has locked the mutex it will release it again
a microsecond or so later, unconditionally. Mutex locks in
get_canvas_index() and get_source_index() are needed so that these
functions would not return incompatible or garbage information during
this microsecond. This is the whole point of "mutual exclusion".
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)