My OLD Syntax

This topic is 1533 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Yes, that's precisely what I mean. In most other languages, the assignment operator is a statement (i.e. it doesn't result in a value at all, and you can't use it in a conditional).

Only in C/C++ can you write such monstrosities as:

if ( (y += 12)/5 > 10) { /*...*/ }

Though, without assignment as a value you wouldn't have this beautiful pattern:

while (char *line = read(...)) {
...
}


It's pretty much poor man's Maybe and I sorely miss it in Java.

Edited by patrrr

Share on other sites

If I'm going to use curly braces, then I want the open and closed characters nicely lined up vertically. Makes things nice and neat by grouping things in blocks.

Well, if you insist:

if (keyboard_check(vk_left)) {
x -= 5;
}

if (keyboard_check(vk_right)) {
x += 5;
}

if (keyboard_check(vk_up)) {
y -= 5;
}

if (keyboard_check(vk_down)) {
y += 5;
}


Okay, this is scary, but I think that actually might work and be rather readable... Assuming you could set it up to automatically add white-space so the open/close for the outer level is always to the right of the open/close of the nested inner set.

Share on other sites

Is that legal syntax? I tried that in VS 2012 and it yelled at me.

It looks like it's not, at least according to section 6.4 of the C++ standard. It defines selection-statements as:

selection-statement:
if ( condition ) statement
if ( condition ) statement else statement
switch ( condition ) statement

The parentheses here are part of the definition of if and switch, so I would conclude that no, they are not optional.

Oh, it's perfectly legal. With function macro wrappers you can bend the syntax and remove the need to write unnecessary parenthesis.

extern bool keyboard_check(keycode);
#define keyboard_check(keycode) (keyboard_check(keycode))

if keyboard_check(vk_left) { … }

That's not the same thing, though. You're talking about code before the preprocessor runs, and we're talking about code after the preprocessor runs (or stays the same after the preprocessor runs).

Share on other sites

and mine:

#define IF if(
#define THEN )
#define DO {
#define ENDIF }
#define ELSE }else

IF keyboard_check(vk_left) THEN
DO
x -= 5;
ELSE IF keyboard_check(vk_right) THEN
DO
x += 5;
ENDIF


do not undervaluate the power of this. You get automatic error-correction for mistypings and wrong capital letters

#define IF if(
#define iF if(
#define Iff if(
#define If if(
//...

IFFF condidion ISTRue   //expands to "if(condition==true){"


I'm guessing if something like that is allowed:

#define while for


Share on other sites

The one I dislike is the start btrace at the end of the if test and the
other hanging out by itself at the end of the block

if (x & y & funcz(a)) {
// do shirt here
}

My usual syntax Ive used :

if (x & y & funcz(a))
{
//do shirt here   --- note triple blank indent
}

when its not a single statement in the if-true code block

I will do    if ()     plus single statement (and align them).... when they are simple

if      (x < 0 )        x = 0;
else if (x > maxx)      x = maxx;
if      (y < 0 )        y = 0;
else if ( y > maxy)     y = maxy;

I also add extra blanks  in many places to make the code less of a run together clustercluck and even split and align if clauses
(funny I usually dont do some for simple 'for'  control clauses)

if ((test1() == 3)    &&
(test2() == 4)    &&
(test3() == 7))
{
// do shirt
}

Im also liberal adding blank lines particularly around For loops to accentuate their groupings

comments I dont mind being on the same line as code

for (o=0; o<maxi; o++)     // loop thru all objects
{
object[o].x = tx;
object[o].y = ty;
// etc....
}

Ive rarely ever use the   ? :     statement form as they disappear in clutter making it hard to visually scan code

//-------------------------------------------------------------------------

and I use lines like this between EVERY function definition to help spot the startpoints (again speeds up visually scanning code )
Edited by wodinoneeye

Share on other sites

if (x & y & funcz(a)) {
// do shirt here
}


That conditional almost certainly doesn't do what you meant it to do

Hint: bitwise & is not the same as logical &&.

Share on other sites

For the record, I know at least one language where it is indeed the case (it only pays attention to the lowest bit instead of the whole value).

Share on other sites

For the record, I know at least one language where it is indeed the case (it only pays attention to the lowest bit instead of the whole value).

But it wouldn't be bitwise anymore, then, right?

Share on other sites

It would be a "single bit bitwise" operator :P

Share on other sites

For the record, I know at least one language where it is indeed the case (it only pays attention to the lowest bit instead of the whole value).

I mean, provided that the binary representation of true and false are exactly 0x1 and 0x0, then they will produce the same result.

Unfortunately, C/C++ are a little flexible in their definition of what constitutes a boolean value...

Share on other sites
Unfortunately, C/C++ are a little flexible in their definition of what constitutes a boolean value...

Well, as usual, the C++ committee took great care to avoid actually saying anything while saying a lot of things, but I think you can still deduct the de-facto definition from what they say. It's amazing how you can write 1,300 pages without laying something very simple down in a clear, understandable, non-ambiguous manner.

Values of type bool are either true or false.

and

A zero value, null pointer value, or null member pointer value is converted to false; any other value is converted to true.

Great. Very nice, except we don't know what true and false are. This isn't mentioned anywhere within those 1,300 pages. For all we know, false could be 354357 and true could be 77342.

However, in combination with this:

A prvalue of type bool can be converted to a prvalue of type int, with false becoming zero and true becoming one.

one can pretty much safely presume that false == 0 and true == 1, even though again it doesn't explicitly say so. Converting to bool and converting from bool converts to/from 0 and 1, respectively.

Of course, given this wording, it is still technically allowable to have different values and add extra code for conversion (similarly, it is perfectly allowable for a null pointer to be something different from zero, even though the literal zero explicitly converts to the null pointer).

But even though technically allowable, it's not something that really makes sense. The values 0 and 1 are as good as any other values, and they do not require extra code for a conversion that has no benefit.

Further, it is explicitly allowable to store a bool in a bit-field, and in this case no "implementation specific" value that isn't exactly 1 would work for true. Neither would (given only two possible values in a single bit) any other value but 0 work for false, since 1 is already taken.

Edited by samoth

Share on other sites

one can pretty much safely presume that false == 0 and true == 1, even though again it doesn't explicitly say so.

Fair enough.

However, the code sample I was commenting on didn't indicate that the values being operated on were actually booleans. It's not uncommon for legacy code to perform boolean operations on integers, for example.

Share on other sites

When I was a newer programmer, it felt unintuitive to me that -1 == true. I just naturally assumed positive numbers were true, and zero + negative numbers were false.

Share on other sites

I've used machines where true == ~false (ie. ~0 == -1 in two's complement) because that was the most efficient way to encode it in the machine instructions.  A conversion to the integral value 1 would take extra instructions, but it's a corner case.  Logical operations are performed on booleans far far more often than arithmetic operations are.

Share on other sites

For the record, I know at least one language where it is indeed the case (it only pays attention to the lowest bit instead of the whole value).

But it wouldn't be bitwise anymore, then, right?

It makes AND, OR and XOR behave as both logical and bitwise, since technically a bitwise operation will still affect the lowest bit exactly the same way. It gets rid of the risk of mixing both variants by simply not having them (the bitwise variant now works for both cases, so the logical one is ditched).

EDIT: actually NOT too. No more need to have separate NOT and complement operators either.

Edited by Sik_the_hedgehog

Share on other sites

if (x & y & funcz(a)) {
// do shirt here
}

That conditional almost certainly doesn't do what you meant it to do

Hint: bitwise & is not the same as logical &&.

The conditional wasnt meant to do anything but be some arbitrary condition for a formating  example (so it did exactly what I meant it to do )

I never use Bitwise operators on single value Boolean variables or conditional clauses ,  But have regularly used bit-wise operators in my coding as a way to compact data in games (single bit flags in sets of flags for objects) . I also have judiciously used the pack settings (on compilers that actually implement them)....

How large do the C/C++ compliles make a single  Boolean variable these days   32 bits, 8 at best?    Blasting needlessly oversized object structures through a network  wasnt conducive to efficiency (including possibly Page Fault stallings in general)

Some might say that is a time for size tradeoff, but dont the out-of-order processing of instructions cancel most fo that these days?

NOTE - I also did exclusively X86 coding so dont read me the usual stuff about endians and compiler differenced in packing

Since someone else brought it up I also #define'd my own  constants TRUE 1  FALSE 0   simply to make that clear and also to make the values use stand out in code  (though in bitwise masking I often used hex  0x0001 and such forrmats  to make what was going on clear also)

Edited by wodinoneeye

Share on other sites

Curly brace arguments. Keeping programmers busy since 1969.

Besides, the only correct brace style is the one I use.

Which one do you use eh?

Edited by Solid_Spy

Share on other sites

Which one do you use eh?

Quantum braces.

They are of indeterminate style until observed, at which point they concretely represent a randomly-selected style.

Share on other sites

Schrödinger's braces?

Share on other sites

Schrödinger's braces?

They look like this: $$\langle \text{code} \rangle$$

Share on other sites

IIRC they help greatly against Heisenbugs.

Touché!

Share on other sites

Thats why having indentation patterns and blank (whitespace) padding stuff  makes the actual visual recognition of the braces/parens/whatever lessimportant (even more so as you get older and 8hours staring at a computer screen starts making your eyballs disolve)

Share on other sites

Curly brace arguments. Keeping programmers busy since 1969.

Besides, the only correct brace style is the one I use.

HA! Until the Director of Software Engineering enforces his own personally preferred ideology upon his subjects. Sadly, dx'ing indexes stuck with me. (idx, jdx, kdx)

I only code on mechanical keyboards. So addicted to them, I bought them for every high-use workstation at my business.

if (keyboard_check(vk_left)) {
x -= 5;
}


* snort *  <--- I can feel aforementioned Director of Software Engineering twitching already...

if
(
keyboard_check
(
vk_left
)
)
{
x -= 5;
}

* sigh * that makes ME twitch. :(  The first time OOP was choked down my throat, that's how those people coded. And were paid. Well paid.

Also, what sane language that allows bool to int casting doesn't represent the bool as 1 or 0?

Probably PHP. It has buried me with it's too-easy casting before.

Great. Very nice, except we don't know what true and false are. This isn't mentioned anywhere within those 1,300 pages. For all we know, false could be 354357 and true could be 77342.

Two things I miss the most from PHP: === operator and all variables needing to start with $. The$ thing makes it easier for me to see my own variables in the other mess of logic. And the === identity is true only if value and type match. So you can do a ===0 or !==0 and not really worry about accidental 1/0 true false problems.

I'm coming back to C (and sadly C++) from my too many years of PHP hacking web apps for my business. The C++ is for embedded things and we don't get any MSVC help, so many of my code searches are about doing things the hard way, coding it by yourself, and not relying on a framework for a crutch.

Thanks for the lolz!

:D Chris, the FNG