|
asrelu wrote: And your point is that it's absurduous to check the validity of the pointer INSIDE the function. Because that function is a class member, you can call it only having a valid pointer to an instance of that class. If the pointer is invalid, the call will fail and the execution of the function will not even begin.
More specifically, a call like pObject->LogID() will fail with ASSERT if pObject is invalid. The call will execute the function only and only if pObject is valid. To check later, in the function, the validity of pObject (locally known as "this") makes no sense.
You're wrong (after all MFC developers are skilled people). Try the following code:
class A
{
public:
void foo(){ printf("%p\n", this); }
};
int main()
{
A * p;
p = NULL;
p->foo();
}
BTW invalid pointers references cause runtime errors not assertions (ASSERT it's only a debug tool to intercept such occurrences).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Quote: "You're wrong (after all MFC developers are skilled people). Try the following code..."
You mix MFC with non-MFC, your sample has nothing to do with the MFC framework. I can only hope you'll not compile the release version without fixing an error signalled in the debug phase so I hope you'll not get a runtime error.
Thank you for your remark that
"invalid pointers references cause runtime errors not assertions (ASSERT it's only a debug tool to intercept such occurrences)".
In return, I want to offer you an advice having the same value:
If you want to fill a glass with water you shouldn't hold it upside down because the glass will not fill.
modified on Saturday, May 17, 2008 10:49 PM
|
|
|
|
|
asrelu wrote: Quote: "You're wrong (after all MFC developers are skilled people). Try the following code..."
You mix MFC with non-MFC, your sample has nothing to do with the MFC framework. I can only hope you'll not compile the release version without fixing an error signalled in the debug phase so I hope you'll not get a runtime error.
MFC is C++ or am I wrong (i.e. MFC designers use C++ , do you realize)? My code simply shows that you assumption is definitely wrong.
asrelu wrote: Thank you for your remark that
"invalid pointers references cause runtime errors not assertions (ASSERT it's only a debug tool to intercept such occurrences)".
Don't be so upset, I fixed your terminology beacause it was wrong: nothing personal.
asrelu wrote: In return, I want to offer you an advice having the same value:
If you want to fill a glass with water you shouldn't hold it upside down because the glass will not fill.
Maybe it has the same value for you. For me it is simply a crap.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
if (this) than that(); else damn (it);
Mostly, when you see programmers, they aren't doing anything. One of the attractive things about programmers is that you cannot tell whether or not they are working simply by looking at them. Very often they're sitting there seemingly drinking coffee and gossiping, or just staring into space. What the programmer is trying to do is get a handle on all the individual and unrelated ideas that are scampering around in his head. (Charles M Strauss)
|
|
|
|
|
The if (this != NULL) is not required and is just overkill; although I have personally seen this equal NULL once or twice in my career (probably a compiler dependent thing).
Now the fact that the method is not actually returning anything is much scarier.
INTP
"Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra
|
|
|
|
|
In my case, it's not an error check. The linked list is searched for a specific object. If the object is not found, the search returns NULL . The member functions in question return a default value if the this pointer is NULL . That way, the caller can do this:
obj->Value() instead of
if (obj != NULL) {
value = obj->Value()
}
else {
value = DefaultValue;
} every place he needs it.
|
|
|
|
|
John R. Shaw wrote: Now the fact that the method is not actually returning anything is much scarier.
Fixed .
|
|
|
|
|
Class* obj = 0;
obj->Method();
The behavior of the call to Method() is not defined. It just happens that most (if not all?) implementations of the C++ language, implements methods like ordinary C functions, but with an added parameter: this.
Had the method been virtual, it would've crashed on the spot due to vtable lookups.
I'd say it's a code horror.
--
Kein Mitleid Für Die Mehrheit
|
|
|
|
|
Jörgen Sigvardsson wrote: Had the method been virtual, it would've crashed on the spot due to vtable lookups.
Aha!
I knew there was a concrete reason why this was a bad idea. I just couldn't think of it. Thanks!
|
|
|
|
|
Just tidying up some code I wrote when I started learning C#(some four months ago).
I found the following two horrors:
itemDups += 0;
goto Skip;
So I thought I better fess up and hang my head in shame.
Oh the shame...
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
Well, not horrors:
GuyThiebaut wrote: itemDups += 0;
Simply exploiting sum neutral element.
GuyThiebaut wrote: goto Skip;
Time-travel to find out C# roots.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Embarassed? What for?
You will always find some interesting things when taking a close look at your older code. It simply means you have made some progress since then.
|
|
|
|
|
Thanks,
I think embarrassed because I have been coding for twenty years and I did not think I still wrote code like this.
You are right though , what is important is progress, we all have to start somewhere.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
What shall I say? The little program I work on right now is a top candidate for this effect. The boss wanted a quick and dirty solution which will have to do until we come up with a better one. Along the way several things did not worke well and sometimes I had to take a step back and try something else.
The code is full of quick and dirty code to try out different approaches and also some remains of previous experiments. The whole structure and design has suffered from this tinkering. Now I'm cleaning it up a little, but still there will remain a lot to be improved. In a few weeks I will probaly plan the real solution and take this as a prototype. No doubt there will be many things which can be solved in a less error prone and better designed fashion.
But as I wrote, this little project has to be working quickly. In a few weeks it will have served its purpose and the encountered issues will help when planing the real solution. Quick and dirty is not always a bad thing. You just have to take it for what it's worth.
|
|
|
|
|
CDP1802 wrote: Quick and dirty is not always a bad thing
Definitely. But then you have to discard it and build the real one, exploiting acquired knowledge.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Usually I do that by redesigning the whole thing as a reusable module where it makes sense. In future projects I then can rely on code which has already proven it's worth.
|
|
|
|
|
Very good.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
|
|
|
|
|
Luckily I have a boss who gives me time to do such things. A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked I say things about the results which nobody understands. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
Your last sentence is definitely signature material!
Luca
The Price of Freedom is Eternal Vigilance. -- Wing Commander IV
En Það Besta Sem Guð Hefur Skapað, Er Nýr Dagur.
(But the best thing God has created, is a New Day.)
-- Sigur Ròs - Viðrar vel til loftárása
|
|
|
|
|
Wait until I post a picture of my new outfit.
How about a dark robe, covered with mystic symbols like the hex codes from 00 to FF. A matching pointy hat and some kind of staff or wand. Growing the obligatory beard my take a while
Edit: Just for fun, I just took it as my signature
modified on Thursday, May 15, 2008 5:32 AM
|
|
|
|
|
Hehe, you should see the wonders I've coded on my first coding job. And I was paid for that.
No one is immune from writing bad\weird code, but some folk just insist they are right, and the rest of us gather here
I wonder how nobody hasn't put some of my early gems here.
|
|
|
|
|
Luckily, for all of us, code is examined less often the older it is. And, over time, someone else may have had to work on it and disposed of the evidence
|
|
|
|
|
Everyone pontificates about lofty and complicated concepts such as declarative programming, boxing, garbage collection, IDL, delegates, generics, etc. But I like your bold use of some very simple and perfectly legal constructs. Too bad the VisStudio compiler abhors this common contruct:
itemDups /= 0;
|
|
|
|
|
rokhead wrote:
itemDups /= 0
Yeah, my code won't even compile with this.
Talk about VS being Stooooooopid.
Maybe I will post a question on the C# forum saying:
<heading>Plz Help
Why does this code not work
itemDups /= 0
You write code for me, now, urgent
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
Im assisting a friend, and I request to see the C# code he is working on, so that I may understand it more clearly.
He uploads, I download.
Visual Studio causes issues, and refuses to open the Project, so I look at the Files.
I see only 2 .cs file's - Program.cs and AssemlyInfo.cs
This NORMALLY means that either they're coding .NET 1.1 (Form1.cs came out in 2.0), or a Command Line App. I'm assuming it's .NET 1.1, as it's a Windows App.
I look at the code (Terrible Form Generation, mixed with manually coded Events.. Yep... Looks like .NET 1.1)
After trying to convert to .NET 2.0, I decide to ask...
"What .NET are you using... ?" in the hope to move him onto .NET 2.0, and hopefully make life easier for him...
To my complete and utter surprise, he replies ".NET 2.0"
I go back to the Folder to re-check the files, and to the recently downloaded archive - Nope - I have everything he uploaded...
Then comes the next question...
"Which Compiler are you using... ?"
He replies...
"SharpDevelop"
I cry....
I ask why he doesn't use Visual Studio Express
He responds that he doesn't have enough free space...
I cry again....
Moral of the Story:
Sometimes Microsoft DOES Release Useful Products... For the love of god... Please use them
-= Reelix =-
|
|
|
|