> Oct 16 2008 6:09pm from LoanShark @uncnsrd
>
> solution to Ford's crap, don't use C++. seriously. Objective-C or
>Smalltalk, if you must, but please, no C++.
>
> Unless you need to use Qt. ;)
>
>
Haha. I was thinking the same thing. But I wasn'
Not even remotely interested in doing C++ and, since I'm not a
professional developer, there's little chance that I'll ever get roped
into it.
Oh yeah, and since I'm the lead developer of this project I can say,
we're sticking with C.
I did a little C++ years ago (remember Daphne,
r6694 | ajc | 2008-10-16 22:07:54 -0400 (Thu, 16 Oct 2008) | 1 line
Changed paths:
M /trunk/webcit/calendar.c
M /trunk/webcit/event.c
M /trunk/webcit/tabs.c
ah more recurrence editor
-
solution to Ford's crap, don't use C++. seriously. Objective-C or
Smalltalk, if you must, but please, no C++.
Unless you need to use Qt. ;)
though its similar, it jamms indention, and harder to read I think.
and, we're doing C over here for a reason, right? ;-)
its one of those things I hate most about C++, that this abstraction stuff is
more of hiding whats going on beyound the surface so you realy can't tell
anymore whether a lin
And also if you consider that if (ptr != null) if (memcmp(ptr, "data")
while 'uglier' the fact is, it will compile to the same thing, so it's not
really bad except for asthetically, and that's a matter of subjectivity of
the reader.
> I never liked that usage, though, becuse it places the condition after
>the point where it's evaluated.
yeah, that's the dumbest larry wallism of them all. I imagine he got it
from somewhere.
I especially like it when the trailing if part is off the screen in your
editor so
> I never quite got to the point where I trusted short circuit
>evaluation. Gotta work on that.
And that's not a bad thing.
In C it's still reliable, but in C++ and other
too-smart-for-their-own-good languages (possibly java I forget) it can be
bad because you can for exampl
http://en.wikipedia.org/wiki/Short-circuit_evaluation
r6693 | ajc | 2008-10-16 12:26:33 -0400 (Thu, 16 Oct 2008) | 1 line
Changed paths:
M /trunk/citadel/commands.c
M /trunk/citadel/messages.c
M /trunk/citadel/msgbase.c
M /trunk/citadel/sysdep.c
Trust the compiler to
..or even more frequently:
[ do something that returns an exit code ] || exit 1
The funny thing is that I've been doing this in shell scripts for years.
I habitually write scripts that look like:
[ foo == bar ] && do_something
r6692 | ajc | 2008-10-16 12:18:30 -0400 (Thu, 16 Oct 2008) | 1 line
Changed paths:
M /trunk/webcit/auth.c
M /trunk/webcit/event.c
M /trunk/webcit/paging.c
M /trunk/webcit/useredit.c
M /trunk/webcit/webserver.c
Yea absolutely you can count on it. "It's not just a good idea.. it's the
LAW" :) As far as the perl do_this if(that) syntax.. I was never too
happy with that. But I will use it for some things. For example let's
say I have a bunch of variables that are set to default values unless they
yeah it's guaranteed. you can rewrite that as if (foo != NULL && ...)
What I've got to do is start trusting the compiler to perform
short-circuit evaluation. I'm so paranoid that I tend to write code like
this:
if (foo != NULL) if (foo->bar == baz) {
...
}
Sort of an "absolutely guaranteed short circuit evaluation" syntax. But
it's ugly.
well it doesn't require brackets if you say blah... unless foo, or
blah... if foo;
I never liked that usage, though, becuse it places the condition after
the point where it's evaluated.
It's great to, for example, check for null pointers.
In perl (yea I know, I know) it's common to see && and || used in place
of an if() or if(!). I used to be disgusted by that. One of the reasons
people do it is because perl requires brackets on a block, even for
one-liners. So
>if you do if clauses, put the cheap conditions to the left, since the
>computer evaluates it left to right. Stuff like IsEmptyStr() is real
cheap,
>while strcmp isn't.
I never quite got to the point where I trusted short circuit evaluation.
Gotta work on that.
19 matches
Mail list logo
