16,004,647 members
Sign in
Sign in
Email
Password
Forgot your password?
Sign in with
home
articles
Browse Topics
>
Latest Articles
Top Articles
Posting/Update Guidelines
Article Help Forum
Submit an article or tip
Import GitHub Project
Import your Blog
quick answers
Q&A
Ask a Question
View Unanswered Questions
View All Questions
View C# questions
View C++ questions
View Javascript questions
View Visual Basic questions
View .NET questions
discussions
forums
CodeProject.AI Server
All Message Boards...
Application Lifecycle
>
Running a Business
Sales / Marketing
Collaboration / Beta Testing
Work Issues
Design and Architecture
Artificial Intelligence
ASP.NET
JavaScript
Internet of Things
C / C++ / MFC
>
ATL / WTL / STL
Managed C++/CLI
C#
Free Tools
Objective-C and Swift
Database
Hardware & Devices
>
System Admin
Hosting and Servers
Java
Linux Programming
Python
.NET (Core and Framework)
Android
iOS
Mobile
WPF
Visual Basic
Web Development
Site Bugs / Suggestions
Spam and Abuse Watch
features
features
Competitions
News
The Insider Newsletter
The Daily Build Newsletter
Newsletter archive
Surveys
CodeProject Stuff
community
lounge
Who's Who
Most Valuable Professionals
The Lounge
The CodeProject Blog
Where I Am: Member Photos
The Insider News
The Weird & The Wonderful
help
?
What is 'CodeProject'?
General FAQ
Ask a Question
Bugs and Suggestions
Article Help Forum
About Us
Search within:
Articles
Quick Answers
Messages
Comments by Wolfgang_Baron (Top 11 by date)
Wolfgang_Baron
18-Oct-11 19:18pm
View
Deleted
Reason for my vote of 1
The article is way too short to explain anything it wants to show. If you know boost::bind(), the article will not show you anything new. If you don't know, you will have to find out what boost::bind() does by yourself, if you want to understand the article. Apart from that, your knobs are "too big" to replace a mere boolean and "too small" to replace a more complex setup, which requires something more powerful than a state variable and a few guarding methods. If you really need more power, you should go after something like QState (of the Qt framework).
Wolfgang_Baron
15-Oct-11 12:40pm
View
Deleted
No dude, you should not use iexplore. First, it is a silly, slow and retarded program. Second, it will only start itself and not the user's preferred browser. Third, it is not in the default search path and will therefore fail in many situations (the command line in the windows start menu has special handling to make it work).
Wolfgang_Baron
7-Apr-11 12:07pm
View
Deleted
Surely anyone can program whatever he wants for himself and I am not insulted (though maybe a bit frustrated), if you continue to produce code with multiple returns. I was only pointing out, that if you want to be nice to other people by keeping your code readable, you will certainly refrain from using multiple returns.
As an example, look at the function QueryLocalGroupSIDs() in CoreCode.cpp of the codeproject article "GUI-Based RunAsEx". Clearly, a nice program and a good job. However, the cruel things the author does to the lpData2 and bSuccess variables results in two return statements inside a __finally section (which is undefined behavior during termination handling btw). Most of the code does nothing at all, because bSuccess can only be TRUE if lpData2 is not NULL. There is no point in using two return statements, because just calculating a result value and returning that at the end is always easier to read. You need 5 to 10 times more time to understand what this function actually does. I even go as far as to say, that the author did not understand his own code here, or he would not have produced so much non functional code.
Again, my point is only meant as a help for anyone, who is interested in the well being of his readers and of course, you can do with your life whatever you want :)
Wolfgang_Baron
7-Apr-11 7:45am
View
Deleted
The first person wanting to add a debug statement at the end will prove you wrong.
Wolfgang_Baron
10-Feb-11 10:37am
View
Deleted
Sorry, I assumed you were going to use exceptions for your regular control flow, which is unnecessarily slow, produces extra code and makes your debugging experience a nightmare. Maybe you could show a little example to clarify, what you mean?
Wolfgang_Baron
9-Feb-11 11:35am
View
Deleted
Reason for my vote of 1
Not to repeat the other reasons for not using exceptions for regular control flow, just try to debug a program like this. You would have to turn off exception catching, which would make debugging a real pain.
Wolfgang_Baron
9-Feb-11 11:32am
View
Deleted
Multiple returns look clear only to those, who have written the code. It is a classical write-only construction. Please be kind to you readers and never ever use multiple returns. Finding bugs in non trivial code using multiple returns easily gets as hard as bad constructions using goto.
Wolfgang_Baron
9-Feb-11 10:44am
View
Deleted
Reason for my vote of 2
While your code would look nice, performance would greatly suffer and there is no finally in C++. Cleanup should always be done in destructors.
Wolfgang_Baron
9-Feb-11 10:40am
View
Deleted
Reason for my vote of 1
Having one only one return statement is not only about cleanup. It's about readability and the effort of the reading having to asses, what the function does. Also, appending a piece of common code to the end of the function is a pain!
Wolfgang_Baron
9-Feb-11 10:35am
View
Deleted
Reason for my vote of 1
People who put more than one return statement into a function or method need to rethink their life!
Just try to produce debug output at the end of a function like that or generally try to analyze what a function like that does.
Wolfgang_Baron
3-Jan-11 12:45pm
View
Deleted
Reason for my vote of 1
"With" is by far the most evil language construct ever thought of. It is absolutely "write only" and invented by lazy idiots for lazy idiots that do not in the least care about their audience. NEVER EVER use it! Even only thinking about trying to infest other languages with this abomination makes me shiver.
Show More