I have no name, I don't exist
-
there is no "subtle bug" forum. but the intro text of this forum includes the category "embarrasing mistakes" (which, amusingly, is a spelling mistake).
-
there is no "subtle bug" forum. but the intro text of this forum includes the category "embarrasing mistakes" (which, amusingly, is a spelling mistake).
Chris Losinger wrote:
there is no "subtle bug" forum
There is such a forum. It was called 'subtle bugs' for a long time and was just recently renamed to 'Wicked Code'. See here: http://www.codeproject.com/Feature/WickedCode.aspx. Regards Thomas
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software. -
there is no "subtle bug" forum. but the intro text of this forum includes the category "embarrasing mistakes" (which, amusingly, is a spelling mistake).
-
Chris Losinger wrote:
there is no "subtle bug" forum
There is such a forum. It was called 'subtle bugs' for a long time and was just recently renamed to 'Wicked Code'. See here: http://www.codeproject.com/Feature/WickedCode.aspx. Regards Thomas
www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.again, the intro text to this forum reads:
We all come across code that simply boggles the mind. Lazy kludges, embarrasing mistakes, horrid workarounds and developers just not quite getting it.
if you feel that is in error, there is a Suggestions forum, too. ;)
image processing toolkits | batch image processing
modified on Monday, June 1, 2009 7:11 AM
-
I have a little timer class that i use in optimizing code. It's a simple thing:
class CISTimer { public: CISTimer() {m\_p = NULL; m\_t = GetTickCount();} CISTimer(const char \*p) {m\_p = p; m\_t = GetTickCount();} ~CISTimer() { DWORD d = GetTickCount() - m\_t; char buf\[30\]; \_snprintf(buf, 29, "%4.2f (%d)\\n", (double)(d) / 1000.0, d); if (m\_p) {OutputDebugString(m\_p);} OutputDebugString(buf); } protected: const char \*m\_p; DWORD m\_t; };grabs the time when it's created and outputs the elapsed time when it's destructed. so, i'm working on a new project and want to see how long certain chunks of code are taking. i put the function calls inside curly braces, and drop some counters in:
{
CISTimer("Func1");
Func1(...);
}
...
{
CISTimer("Func2");
Func2(...);
}so the counters will print their elapsed time when they go out of scope, thus telling me how long the function took, so i'll know where to start optimization. but they're all coming up with an elapsed time of 0. that can't be true. so i switch from GetTickCount to QueryPerformanceCounter. but, all those come up with 15 ticks - far too fast. the calls should be in the .25 second range. so, i step through the code. the breakpoint gets to the counter instantiation, i step over it, and the timer immediately destructs - before going out of scope. did i break C++'s deterministic destruction? after much head-scratching, i realized that i forgot to give names to those CISTimer objects. they were anonymous, and so they disappeared as soon as they were created. duh. this is an unpleasant feature of C++.
So you think (compiler) optimization is unpleasant? :confused:
-
So you think (compiler) optimization is unpleasant? :confused:
i think allowing anonymous variables outside the context of a function call is unpleasant.
-
i think allowing anonymous variables outside the context of a function call is unpleasant.
I'm not sure what you mean by anonymous variables. It is quite normal in C to have expressions yield a value which is ignored. Even "intvar=5" is an expression which yields the value five. It is also quite common to have functions return a value which is ignored. To be sure, there are places where return values shouldn't be ignored but are anyway; on the other hand, it would be annoying if one always had to explicitly use the return value of something like memcpy() instead of just letting it vanish into the ether.
-
I'm not sure what you mean by anonymous variables. It is quite normal in C to have expressions yield a value which is ignored. Even "intvar=5" is an expression which yields the value five. It is also quite common to have functions return a value which is ignored. To be sure, there are places where return values shouldn't be ignored but are anyway; on the other hand, it would be annoying if one always had to explicitly use the return value of something like memcpy() instead of just letting it vanish into the ether.
supercat9 wrote:
I'm not sure what you mean by anonymous variables.
anonymous = "without a name".
supercat9 wrote:
It is quite normal in C to have expressions yield a value which is ignored.
right. but that has nothing to do with the code i posted above. this isn't about return values. in C++ you can do this:
CPoint(5,15);
that will construct a CPoint object and immediately destruct it because the variable is anonymous, it has no name, and it isn't used anywhere. you can also do this:
MyFunc(CPoint(5,15));
this will create a CPoint and pass it to MyFunc. the latter case us useful - and it's very common to do this when you need to re-package some data that you already into the types that the function expects. but the former case is much less useful. if the c'tor and d'tor have side-effects, you could possibly use that to take advantage of those side-effects. but it's very non-intuitive. you would be better off moving those side effects to a function that you could call explicitly.
-
supercat9 wrote:
I'm not sure what you mean by anonymous variables.
anonymous = "without a name".
supercat9 wrote:
It is quite normal in C to have expressions yield a value which is ignored.
right. but that has nothing to do with the code i posted above. this isn't about return values. in C++ you can do this:
CPoint(5,15);
that will construct a CPoint object and immediately destruct it because the variable is anonymous, it has no name, and it isn't used anywhere. you can also do this:
MyFunc(CPoint(5,15));
this will create a CPoint and pass it to MyFunc. the latter case us useful - and it's very common to do this when you need to re-package some data that you already into the types that the function expects. but the former case is much less useful. if the c'tor and d'tor have side-effects, you could possibly use that to take advantage of those side-effects. but it's very non-intuitive. you would be better off moving those side effects to a function that you could call explicitly.
this will create a CPoint and pass it to MyFunc. A constructor is essentially a function call. The function returns a value, which may be used like any other rvalue. The expression "somevariable = CPoint(5,15)" has a value which would typically be ignored, but could be used as part of a larger expression. The compiler doesn't particularly care whether or not it makes sense for the result of a particular expression to be ignored; while one typically ignore the value of an assignment expression, and would not typically ignore the value of a constructor, there are situations where one might very reasonably want to do the opposite of the usual case. One may, for example, wish to follow a 'next' pointer and check whether it points anywhere, or force the early creation of a singleton object one is not immediately interested in using.
-
this will create a CPoint and pass it to MyFunc. A constructor is essentially a function call. The function returns a value, which may be used like any other rvalue. The expression "somevariable = CPoint(5,15)" has a value which would typically be ignored, but could be used as part of a larger expression. The compiler doesn't particularly care whether or not it makes sense for the result of a particular expression to be ignored; while one typically ignore the value of an assignment expression, and would not typically ignore the value of a constructor, there are situations where one might very reasonably want to do the opposite of the usual case. One may, for example, wish to follow a 'next' pointer and check whether it points anywhere, or force the early creation of a singleton object one is not immediately interested in using.
i'm not sure why you refuse to acknowledge my point.
supercat9 wrote:
The compiler doesn't particularly care whether or not it makes sense for the result of a particular expression to be ignored
i'm not complaining about what the compiler does. i'm complaining about the fact that the language allows such a thing to happen. it makes no sense at all to construct an anonymous object outside of the context of a function call. this makes sense:
CString t1 = CString ("sdfs");
this also makes sense:
MyFunc(CString ("sdfs"));
this makes no sense:
CString ("sdfs");
-
i'm not sure why you refuse to acknowledge my point.
supercat9 wrote:
The compiler doesn't particularly care whether or not it makes sense for the result of a particular expression to be ignored
i'm not complaining about what the compiler does. i'm complaining about the fact that the language allows such a thing to happen. it makes no sense at all to construct an anonymous object outside of the context of a function call. this makes sense:
CString t1 = CString ("sdfs");
this also makes sense:
MyFunc(CString ("sdfs"));
this makes no sense:
CString ("sdfs");
Chris Losinger wrote:
i'm not sure why you refuse to acknowledge my point.
I am. :)
-- Kein Mitleid Für Die Mehrheit