|
My only problem with that is that GetA and GetB are being called twice each. There is, of course, no guarantee that the second call to either will return the same value as the first. Further, there is not guarantee that either isn't an expensive operation.
I would probably go for the much clearer:
A* pa = GetA();
B* pb = GetB();
if (pa != NULL && pb!= NULL)
*pa = *pb;
Unfortunately, this method would always call GetB once, while the original would never call GetB if the first call to GetA returned NULL, so determining which is more efficient depends of how expensive the call to GetB is, and the likelihood than GetA returns null.
Which would give us this:
A* pa = GetA();
if (pa != NULL)
{
B* pb = GetB();
if (pb != NULL)
*pa = *pb;
}
Which, despite being the most keystrokes, would be the best method in terms of speed efficiency, memory efficiency (fewest assembly instructions), and code clarity.
In other words, just freakin' learn to type.
Truth,
James
modified 26-Jun-15 11:48am.
|
|
|
|
|
Amen Brother!
Was saying something similar this morning. Our Java guys have all these layers Spock, Groovy, Gradle, etc on top of the Java code to make life "simpler" and "easier". They spent the same, if not more, amount of time learning about those things as they would have just doing whatever it was by hand.
But code in Delphi mainly so what do I know?
Back when I was coding in C I was smart, now it doesn't feel like it so much because the languages take care of too much stuff for you and you don't have to think about it.
|
|
|
|
|
Ah Delphi, the evolution of my first true love. Where nothing is left to chance for knowing the types and how things are evaluated... I miss Delphi. I loath Fortran even F2003. Such is the life of maintaining aerospace code.
|
|
|
|
|
That's why I prefer to code in Java rather than C++. Though I have written small apps in C++, I prefer to focus on the logic of data flow instead of the detailed memory structure of the RAM. Indeed, this is why I prefer Java to C#, though again I have used the latter quite a lot. This might be because I write a lot of mathematical apps where the logic of data flow is hard enough without extra overheads. Java just seems relatively effortless for coding such applications. That said, I do occasionally code in C++, and even assembly language, simply because I like to be reminded how computers work for my own academic satisfaction. However, I do miss the days of C64 POKE and PEEK - one really felt as if one was in control of the computer in those days.
|
|
|
|
|
what about:
int* a;
int* b;
if ((a = GetA()) && (b = GetB()))
{
*a = *b;
}
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
That does work, but
if (a = GetA()) ... is too easy to mistake for
if (a == GetA()) ...
Which is why I never leave the comparison implied, so we get:
if ((a = GetA()) != NULL && (b = GetB()) != NULL)
which is rather unwieldy. And for what purpose? The longer version I posted will produce the exact same object code.
Truth,
James
|
|
|
|
|
James Curran wrote: The longer version I posted will produce the exact same object code. Will it? The version you and I just discussed has the advantage of short-circuiting, where the first version you posted does not. Which is a "limitation" you pointed-out.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
I was referring to the second version I posted (i.e., "the longer version", the one with nested if()s).
And that does produce identical object code. From VisualStudio 2013, Release build:
Mine:
; 21 : void Method2()
; 22 : {
; 23 : A* pa = GetA();
00023 e8 00 00 00 00 call ?GetA@@YAPAHXZ ; GetA
00028 8b f0 mov esi, eax
; 24 : if (pa != NULL)
0002a 85 f6 test esi, esi
0002c 74 0d je SHORT $LN6@wmain
; 25 : {
; 26 : B* pb = GetB();
0002e e8 00 00 00 00 call ?GetB@@YAPAHXZ ; GetB
; 27 : if (pb != NULL)
00033 85 c0 test eax, eax
00035 74 04 je SHORT $LN6@wmain
; 28 : *pa = *pb;
00037 8b 08 mov ecx, DWORD PTR [eax]
00039 89 0e mov DWORD PTR [esi], ecx
$LN6@wmain:
; 29 : }
; 30 : }
and yours:
; 32 : void Method3()
; 33 : {
; 34 : A* a;
; 35 : B* b;
; 36 : if ((a = GetA()) && (b = GetB()))
0003b e8 00 00 00 00 call ?GetA@@YAPAHXZ ; GetA
00040 8b f0 mov esi, eax
00042 85 f6 test esi, esi
00044 74 0d je SHORT $LN13@wmain
00046 e8 00 00 00 00 call ?GetB@@YAPAHXZ ; GetB
0004b 85 c0 test eax, eax
0004d 74 04 je SHORT $LN13@wmain
; 37 : {
; 38 : *a = *b;
0004f 8b 08 mov ecx, DWORD PTR [eax]
00051 89 0e mov DWORD PTR [esi], ecx
$LN13@wmain:
That's with all standard "Release mode" optimizations on, except "Whole Program Optimization" (to prevent it from inlining GetA & GetB)
Truth,
James
|
|
|
|
|
Interesting. Thanks.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Your code will be correct if both GetA and GetB return pointer on GLOBAL or STATIC variable same type ofcorse.
It is possible to code on C++ without C-knowledge, but not to programm
|
|
|
|
|
It would also be correct within the context of the code for a class where the functions are returning pointers to data members.
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
Came across this kind of code today...
void EnableFromValue(bool enabled)
{
switch (enabled) {
case true:
FirstControl.Enabled = true;
SecondControl.Enabled = true;
...
break;
case false:
FirstControl.Enabled = false;
SecondControl.Enabled = false;
...
break;
}
}
I'm sure there must be a better way
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
I voted this a 5 because it was funny, but I could see a valid reason for that... if they wanted to encapsulate the logic of which controls were affected into a single resource I could see me doing that. Especially if it's called in more than one area.
Jeremy Falcon
|
|
|
|
|
I see a reason for the function but not for the switch statement. Except if you are paid by lines of code of course.
The good thing about pessimism is, that you are always either right or pleasently surprised.
|
|
|
|
|
Totally agree.
Jeremy Falcon
|
|
|
|
|
I have code like that. It is the "..." that is significant. For some objects, you can't just set enable = false, you have to do other things. And, in some cases, one switch branch will enable some fields and disable others.
|
|
|
|
|
So do other things in the switch, but set the common values just once outside the switch ... duh. It's the DRY principle, and duplicating the code in each branch of the switch is not only stupid, but error prone.
|
|
|
|
|
#SupportHeForShe If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Only 2 things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
If they had a default: case then I could almost see a reason. Consider the case if the bool was neither true or false. For most x86 C's there are 254 other trues and 65534 other trues on the DSP I code. I remember some very picky standards about what to do with unexpected values for space computing. Pesky alpha/beta/gamma particles flipping RAM cells around and the like.
I have fixed my share of mixed boolean true logics gone bad. Is it a one, -1 or non-zero?
If true == mySupposedBool can be very tricky to find in C when mySupposedBool = -1 from some other language interface.
At least false seems to always == 0.
-----
I love standards, there is so many to choose from!
|
|
|
|
|
DSewhuk wrote: If they had a default: case then I could almost see a reason. Consider the case if the bool was neither true or false. For most x86 C's there are 254 other trues and 65534 other trues on the DSP I code. I remember some very picky standards about what to do with unexpected values for space computing. Pesky alpha/beta/gamma particles flipping RAM cells around and the like.
Interesting; most programmers never have to consider the possibility of failure of the CPU/memory in their code. Does this imply that you must use a form of trinary logic (true / false / bad value) in such code?
DSewhuk wrote: I have fixed my share of mixed boolean true logics gone bad. Is it a one, -1 or non-zero?
My problem is - how many compilers assume that a Boolean has only 'true' or 'false' values, ignoring the 'default' clause in this case? One solution would be to have your interface code treat 'Boolean' values as appropriate-size integers, converting to an appropriate type (e.g. true / false / bad value). This leads us to the logic above, where Boolean values are not truly Boolean.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
This happens to me sometimes, until I get a few lines into and realize that there is a much simpler way.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
So better way is this?
FirstControl.Enabled = enabled;
SecondControl.Enabled = enabled;
or better yet, MVVM would help if applicable to the app.
|
|
|
|
|
That's the gist of it yep.
This is in an MVVM app, using a framework I architected. Sadly, one of the dev's has a habit of naming View Model fields too literally after the thing in the View, so it still ends up looking like code manipulating the view directly (and at the other extreme, a hell of a lot of business logic has polluted the view model). So, while the controls may not be called "FirstControl" etc., its really not that far off - properties with names like "CustomerListBoxSelectedCustomer".
I try to clear up as much as I can as I work with stuff, but it seems some people just don't want to learn to work with architecture.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Someone needs to sit down with the guy and give him some 'help' to understand decent coding practices. Keep a hammer ready ...
My plan is to live forever ... so far so good
|
|
|
|
|
Code Reviews
Code Reviews
Code Reviews
Here is a great rule. When someone gets multiple "mandatory" changes needing to be made as a result of a Code Review. Then you must review weekly, ALL of their code. This continues until they no longer require "mandatory" changes for a few weeks in a row.
The goals are:
1) Slow them down
2) Get them to proactively ask people how they should code/name something
3) Show them the right way (for your group) to do things
Our Code Reviews have 3 Comment Levels:
- Mandatory: We will not let this stand in production, must be rewritten
- Suggested: We are not thrilled, but if you can "really" defend it.
- Noted: We are just making a note, take it or leave it (Variable names, Variable comments)
Make Code Reviews fun. Friday starting at lunch time with pizza brought in. It helps you to detach from the depth of coding for the weekend. Besides, Code Reviews are how Good Developers help new Developers!
|
|
|
|
|