.
else if (not defaultServerList.contains(server))
Those C99 boolean operator keywords(not, or, and) break here on windows and are not worth the annoyance.
I already had discussions about that once and I am not keen on doing that again. Thus I beg you to use the standardized operators !,||,&& from now on, so that I will never have to complain about that again.
I will add another post about the second biggest annoyance (export macros) soon, but this requires a longer post.
Posts
19 comments:
Well, that look likes code of mine. I did not know about the discussion you mentioned and I indeed do this in some cases. Sorry for the hassle.
bbroeksema
actually, according to the msvc documentation, the C99 variant of these operators (the one that required including some include file) should work just fine. It is the perfectly standard C++ version of the operators that is supposed to work without including the header file that apparently is broken (one possible work around is thus to include that one header file whose name I forgot right now on windows)
I started using these english operators. They really do help readability. But they were fairly quickly reverted because of MSVC. :/
Do they really help readability? For my part, when I see '!' I read it as 'not' and that's done very quickly. It also stands out from identifiers. Using words instead means that you have a whole string of words, which is slower to parse (symbols provide easy to spot breaks in the stream of identifiers). I assume most long-term programmers are in the same boat.
well, as I said, I had long discussions (in koffice and not so much in amarok;-)) and I dislike that part really. I have to admit that I personally prefer the "old" versions so much that my new python code(where those old style operators have been allowed only recently) switched to those as well.
it's actually pretty straightforward: C++ is based on C98. No C99-isms allowed, full stop.
@Anonymous with a syntax highlighter, they are bolded and quite easy to make out. True ! does become 'not' in my mind, but it is quite a bit smaller on the screen and just an extra step to think through. Especially when several operators are in play, its nice to be able to easily pick them out at a glance.
There's also the issue of the close resemblance of bit and bool operators.
Of course, MSVC makes this whole conversation moot.
I would never use them in C code. However they have always been part of standard C++ and I prefer that tokens because they make code more readable by producing less clutter. I would say that a compiler that does not support this is not a C++ compiler and it is not worth using it.
I did a bit of digging around and according to wikipedia (http://en.wikipedia.org/wiki/Iso646.h) it seems the C++ standard mandate to provide the ciso646 header (which includes iso646.h) that define those as macros, even though they should be implemented as reserved keywords.
So I guess sticking #include <ciso646> somewhere should solve the problem and compile both with gcc and msvc.
I never even knew that they added those plain english operators.
Interresting how the comments seem to doubt that its a problem. Its not like Patrick didn't try this already ;)
Anyway, lets not have this discussion. Its too much like codingstyle (braces placement anyone?).
Its personal and you can learn to use the version that works with MSVC. It even beats the prospect of having code that mixes 'and' as well as '&&' which for sure will confuse people.
@SaroEngels
I find no mention that Python (2.6 or 3) will allow '&&' instead of 'and' ?
@thomas its exactly the same as coding style discussion, because thats what it is. :D Nothing wrong with that, we're not cluttering up k-c-d or something with it.
So (one of the same anonymouses as earlier) it seems I wrote way too soon. Those *are* reserved words in C++ and, as pointed out in another comment, you can use them in KDE code from a C++ language point of view. From a compiler compatibility and coding stlye point of view, maybe not. We have a list of supported compilers; if these reserved words aren't supported by some of those compilers, then it's legitimate to say they cannot be used in KDE code (but that can trigger a new discussion about which compilers to support, sure).
I hate to say this, but this kind of post and discussion could have been avoided if you have accepted proper the solution, the fact that you don't like not/and/or has been what has truly guided you in the choice.
As for the readability, it's a matter of choice, and since there are technical solution to the problem, it should be up to whoever will have to maintain the code to decide to use whatever he feel more comfortable with. It's like the choice of programming language, in the end you choose whatever language/coding style you feel the more comfortable with.
Even if there's the #include ciso646, the operators break my ability to read and parse the conditions quickly.
Personally (and quite a few are with me) I wouldnt use the newer operators even for excplicitly non-msvc projects.
In the past we have somewhat agreed on having something like Kate plugin that replaces ! with 'not', etc. for anyone willing to pythonize her/his code, and saves the code back using traditional operators.
@jstaniek: that's why the choice should be left to the maintainer, there is little chance that you will ever read code I write, and there is little chance that I will ever read code that you write. So whatever you do in your code is never going to affect me.
As for the kate plugin, most of the code is written, the only remaining difficulty is to make kate developers to agree on how the plugin should be loaded...
Is there an up to date page on like Techbase which list the common portability pitfalls with in KDE wrt Linux, Solaris, Mac OS X and Windows?
Maybe eventually one such page could be made strict rules for projects within KDE, with everyone being allowed to fix such deviations?
@anonymous said "Is there an up to date page on like Techbase which list the common portability pitfalls with in KDE wrt Linux, Solaris, Mac OS X and Windows?"
Windows part of such portability notes:
http://techbase.kde.org/Projects/KDE_on_Windows/Porting_Guidelines
sometimes you can go to earn the mabinogi gold for your own life and you can also get a lot of happiness in the game if you play the game well. you can brush the cheap mabinogi to upgrade and then you are very strong. You think that you want to play the game well and then you can get the mabinogi money for your own. you can go to buy mabinogi gold alone and you can give some for your friends; it can make you very happy I think. As long as you play the game you can get the mabinogi online gold as the rewards in this game.
Post a Comment