views:

418

answers:

6

leisure/curiosity question as implied in the title.

I personally prefer the new operators as to make code more readable in my opinion.

Which ones do use yourself? What is your reason for choosing one over the other one?

also Emacs highlights those operators differently so I get more visual feedback when looking at the screen. I know the old operators can be highlighted as well but the ISO646 highlighted by default

+2  A: 

I use the old ones.

Reason: I coded in Perl for a while and the operators have different precedence depending on if they're the spelled-out variant or not. I ran into a couple of bugs because of this and since then I always use &&, || and ! over the spelled out variant for any language that has them.

Ben S
PHP has those problems as well. Replacing `($a or $b)` with `($a || $b)` fixed a bug, at which point I got fed up with the language entirely.
Tom
+2  A: 

Are you referring to the alternative tokens originating from iso646.h?

They are from C and it's very uncommon to see, therefore likely to be less readable by most. I'm sure if we had been "raised" with these keywords they'd be more common, since they read like English better.

Then again, && lets non-English speakers say "and" in their native tongue. (Not that this was a concern in the keywords in the first place.)

GMan
But ciso646.h contains... nothing??
Charles Bailey
What? For me, Visual Studio 2008, it does the expected `#include <iso646.h>`, which has the macros. I'm sure g++ is the same.
GMan
`<iso646.h>` in C contains `and`, `and_eq`, etc. as macros, but `<ciso646>` (according to appendix C of the standard) should exclude the macros `and`, `and_eq`, etc. as they are keywords in c++, thereby making `<ciso646>` the most pointless header in the standard (IMHO). VS is known to be non-compliant in this regard, though, so that might explain what you're headerfile.
Charles Bailey
Huh, I agree then. I didn't know they were actual keywords, why on earth would this header exist? :o
GMan
Sorry, they're not keywords (thinko!), they are alternative tokens.
Charles Bailey
Ha, no problem.
GMan
The header exists because they aren't keywords in C so C has `iso646.h` to get them, and C++ supports all the C headers (from the 1995 amendment to the C standard, which is where `iso646.h` got added). In addition, MS decided not to implement the keywords in MSVC unless yo use the strict ANSI option (/Za), so to get them in MSVC C++ you often need to include the header: http://stackoverflow.com/questions/555505/c-alternative-tokens/555524#555524
Michael Burr
@Charles - I think calling them keywords is fine - they're listed in the "2.11 Keywords" section of the C++ standard, and they're specifically called 'keywords' in Annex C (C.2.2.2 - Header `<iso646.h>`)
Michael Burr
If they weight the same as a keyword, and they quack like a keyword... but they're not actually in the table of keywords. Practically, yes, it matters little.
Charles Bailey
+4  A: 

I prefer to use not instead of ! because it's a lot more readable:

if (not condition()) {
}

versus

if (!condition()) {
}

The ! kind of gets lost in there. Of course, this must be avoided (or #defined) when writing code intended to be portable.

However, and and or don't do much for me, so I don't use them.

Greg Hewgill
`if (not condition())` is a blasphemous abomination from hell.
Charles Salvia
I disagree with the readability. But that is because I am so used to the ! operator. To train my brain to read not as an operator is a non trivial processes at my age.
Martin York
I like to use `not`, `and`, `or`, even more since I work with python. Emacs highlights them by default, I find `not` in particular more readable, and they are faster to type IMO.
rafak
+8  A: 

I don't think I have ever even seen C/C++ source code that actually uses the alphabetic operators. To me, it just looks strange; very un-C-ish.

Charles Salvia
Never knew they existed til now.
Edan Maor
+1  A: 

Alternative tokens for logical (and not only logical) operators, like and, or, not etc. have nothing to do with C++ specifically. They were present in C as well, virtually from the very beginning. If you like to use them in your code, you are free to do so, but don't be surprised if people see this practice as rather unorthodox. Normally people use traditional designators for these operators (e.g. &&, || and so on) in both C and C++ code.

AndreyT
No. `and`, `or`, `not`, etc. are _specific_ to C++. They are _keywords_ in C++. You can't choose to do without them. They are standard macros in C, but if you don't include <iso646.h>, you don't get them.
Charles Bailey
Well, I don't want to restart the beaten to death debate about whether alternative tokens are keywords or not. In my opinion, the wording of the standard (C++98 at least) is pretty clear: they are *not* keywords. Altough it is true that they are not macros in C++.
AndreyT
Sorry, you're right, they are not keywords, they are alternative tokens. Either way, they _are_ C++ specific (as oppose to C where they are definitely macros).
Charles Bailey
Wait, so what should my answer say? :P
GMan
Charles Bailey
Time to unsplit hairs and continue beating this to death: Alternative tokens are keywords. They're defined in the Keywords section of the standard, and are specifically called keywords in Annex C.
Michael Burr
+4  A: 

I won't use the alternative operators as they cause more confusion then clearity in my opinion.
If i see an alphabetical name i expect a namespace, class, variable, function or a function style operator - the common operators divide this intuitively into sequences for me. The alternative style just doesn't fit into the C/C++ world for me.

Also, while Greg has a point regarding people new to C or C++, you get used to it pretty soon - i have no problems spotting ! anywhere.

Georg Fritzsche