Sunday, February 28, 2016

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

JiiPee <no@notvalid.com>: Feb 28 09:23PM

On 28/02/2016 19:38, Bob Langelaan wrote:
> enum Directions { NORTH, EAST, SOUTH, WEST };
 
you can do something like this:
Directions kk = NORTH;
kk = (Directions)(kk + 1);
Vir Campestris <vir.campestris@invalid.invalid>: Feb 28 09:43PM

On 28/02/2016 19:38, Bob Langelaan wrote:
 
> but I get the error:
 
> "Error (active) this operation on an enumerated type requires an applicable user-defined operator function"
 
> I thought this was supposed to work. Is this a bug or am I remembering wrong?
 
IIRC it works in C.
 
When you increment an enum you get an int (usually) - the underlying
type for an enum. You then have to cast it back to the enum type - as
JiiPee showed - or you can make an operator++ function for the enum type.
 
Directions operator++(const Directions old)
{
if (Direction == WEST)
return North;
else
return static_cast<Directions>(++old);
}
 
(and I haven't even fed that to a compiler so it's probably wrong)
 
Andy
Victor Bazarov <v.bazarov@comcast.invalid>: Feb 28 04:51PM -0500

On 2/28/2016 2:38 PM, Bob Langelaan wrote:
 
> but I get the error:
 
> "Error (active) this operation on an enumerated type requires an applicable user-defined operator function"
 
> I thought this was supposed to work. Is this a bug or am I remembering wrong?
 
You're remembering wrong, or incompletely. In order to use ++ with a
user-defined type, one needs to define one's own operator. What do you
think a ++ would do if you gave your enumeration constants specific
values, like
 
enum Directions { NORTH = 10, EAST = 100, SOUTH = 1000, WEST = 10000 };
 
? What would it do for 'WEST'? Circle back or become an unnamed value
(integral 4)? There is no default behavior for user-defined types.
 
As your compiler suggests, define your own operator:
 
Direction& operator++(Direction& d) {
switch (d) {
case NORTH: d = EAST; break;
case EAST: d = SOUTH; break;
case SOUTH: d = WEST; break;
case WEST: d = NORTH;
}
return d;
}
 
V
--
I do not respond to top-posted replies, please don't ask
JiiPee <no@notvalid.com>: Feb 28 10:54PM

On 28/02/2016 21:51, Victor Bazarov wrote:
> return d;
> }
 
> V
 
 
yes I think this is the safest way. adding +1 can lead to errors later
on if somebody changes their integer values.
so: enum + 1 I think think is not so good idea....
Bob Langelaan <bobl0456@gmail.com>: Feb 28 02:54PM -0800

On Sunday, February 28, 2016 at 1:51:14 PM UTC-8, Victor Bazarov wrote:
 
> V
> --
> I do not respond to top-posted replies, please don't ask
 
Thanks muchly :)
 
Bob
JiiPee <no@notvalid.com>: Feb 28 10:57PM

On 28/02/2016 22:06, Stefan Ram wrote:
> 3
> 0
> 1
 
Not sure how safe this approach is and is it recommended? I mean, what
if somebody changes EAST to say, 5 later on?
In any case, I think with this approach there should be heavy comments
near direction to warn about this, that not to change the integer values.
Geoff <geoff@invalid.invalid>: Feb 28 02:05PM -0800

On Sun, 28 Feb 2016 09:19:10 +0100, Christian Gollwitzer
>through which we all were made. It is scientifically proven the cause of
>all our being.
 
> Christian
 
I think this might go back to the myth of Adam and Eve and original
sin. They were both given life without fucking being involved. Then
they ate of the tree of knowledge and were both fucked from that day
forward. Damned by God and driven from Eden, it's now a sin in the
eyes of religious fanatics to eat the wrong foods, fuck, wank off,
fuck thy neighbor's wife or do anything you fucking like of which the
pious might disapprove.
"Öö Tiib" <ootiib@hot.ee>: Feb 28 02:27PM -0800

On Sunday, 28 February 2016 23:17:31 UTC+2, Dombo wrote:
 
> If mixing UI and program logic is really a big concern and you cannot
> rely on the discipline of the developers you'd much better of using
> another programming language for the UI.
 
Good idea, typically HTML5 is best candidate now. Maybe in few years C++
again built with asm.js. Qt 5 has also now gone to separate language
for GUI with its QML. Unfortunately that makes 3 layers: application
logic, fishbones of that Qt and QML.
 
> unnecessarily hard just stimulates people to just do everything in the
> UI code to avoid having to write error-prone/no-added-value glue code to
> interface with other parts of the program.
 
What are the better ways? I sometimes suggest separate processes for
UI and business logic but that makes interfacing even harsher so I
don't think you meant that.
 
The product gets actually produced quicker that way since UI-less
application logic is easier to unit test and automatic test and any
peck or panic about UI features does not accidentally screw
application logic up. It is not hard to sell such architecture to
shareholders since there is prospect to put business logic into
"cloud", UI into "web" or "apps" or whatever the current buzzwords
are.
 
> container types as used for the GUI part, apparently Qt didn't thought
> it was necessary to introduce more incompatible string and container
> classes to make the distinction between UI and business logic clear.
 
I agree. There is odd megalomania on case of Qt. Most things that Qt
incorporates besides GUI are not hard to dump however. Those have
better alternatives freely available.
 
> languages is the inconsistent mess of (naming) conventions, strings,
> containers...etc you get confronted with if you use multiple libraries
> from various sources. Not a good thing in my book.
 
That is very same with other languages as well. Everybody wants to
have some personal "style". More like samurais than engineers.
guinness.tony@gmail.com: Feb 28 02:19PM -0800

On Saturday, 27 February 2016 18:22:44 UTC, alexo wrote:
> on button pressing.
 
> any help is welcome and appreciated
 
> thank you
 
It seems that your program runs in an event-driven framework
(which the toy program did not).
 
In such an environment, you almost certainly need to be using
the curl_multi_xxxx() function set: this allows the transfer to
be made asynchronously, eventually notifying you of the final
success/failure status (through an event or callback function)
without holding up your original event handler.
 
In the last project in which we used libcurl, I seem to recall
comments in the code to the effect that curl_easy_perform()
must only be called from the same thread that called
curl_easy_init(), otherwise unexpected behaviour would ensue.
[I've not recently checked the libcurl documentation to
determine the validity of those warnings.]
In an event-driven runtime framework, this same-thread
guarantee cannot always, if ever, be met.
 
I advise looking into using libcurl-multi.
 
https://curl.haxx.se/libcurl/c/libcurl-multi.html
ram@zedat.fu-berlin.de (Stefan Ram): Feb 28 10:06PM

> }
> return d;
> }
 
Yes. But, /if/ the numerical values are appropriate,
then one might also:
 
#include <iostream>
#include <ostream>
 
enum direction { NORTH, EAST, SOUTH, WEST, TOP };
 
direction operator+( const direction d, int const n )
{ return static_cast< direction >
( ( static_cast< int >( d )+ n )% static_cast< int >( TOP ) ); }
 
int main()
{ direction x( NORTH );
for( int i = 0; i < 9; ++i )::std::cout <<( x = x + 1 )<< '\n'; }
 
1
2
3
0
1
2
3
0
1
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)