Thread: toupper() & tolower() problem?

  1. #16
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Except when you want to do
    T a = i++;
    So they have different uses.
    And usually i++ or ++i does not matter - the compiler can usually optimize such things and the speed impact is usually negligible.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    I agree that if you use the result, then the choice is based entirely on that. I'm talking about cases where the result is not used.

    The compiler can only optimize if the operator is inline. There is no reason to assume that the compiler will choose to do this for say map iterators. Best to have the same habits for everything.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  3. #18
    Registered User C_ntua's Avatar
    Join Date
    Jun 2008
    Posts
    1,853
    Quote Originally Posted by Elysia View Post
    No, we should not prefer one over the other. It is a matter of style and where one form fits better than the other. Neither is better than the other.
    They don't do the same thing anyway. The only situation that I can think of that they do same thing is when the value of the variable is not used. Like "++i;" or "i++;". In those cases the compiler will optimize, because it is too simple not to do so. You simply don't care about the "pre" vs "pro". You just have an increment.

    For custom type (classes) you can have something like this

    Code:
    myClass& operator++() //pre-increment
    {
        this->value += 1;
        return *this;
    }
    
    myClass operator++(int)  //post-increment
    {
        myClass temp(*this);
        this->value += 1;
        return tmp;
    }
    So the post increment will have to make a copy. The compiler will probably not optimize in this case.

    So post-increment is guaranteed to be equal or faster.

    If you know that they are the same (because they are fundamental types for example) then it is a matter of style. But that is an if. If you see a code that has
    Code:
    for (i=0; i < count; i++) ...
    then "i" might not be an int. It can be a custom class. In which case the "i++" would probably be wrong.
    if you see
    Code:
    for (int i=0; i < count; i++) ...
    then you know "i" is an int and no problem.

    If you don't overload ++ or -- I don't think you will have to worry which one to use...

  4. #19
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    If you're using i, then it better be an int (or similar). Iterators names should have at least a few characters to them.

    Just saying.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  5. #20
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    The notion that optimizations cannot be done if the the code isn't inline and the compiler cannot see it at the time of instantiation is wrong. There is link-time optimizations that can be done. Both MSVC and GCC supports this.
    Habits are a subjective thing, also. One should always adapt habits best to oneself. Always using ++i, for example, is also a subjective thing. Whether we use i++ or ++i when the statement is used on its own is meaningless to debate; it's a preference.
    Whether it's an iterator, an object or an integer doesn't matter.

    All I am saying is that when using ++i or i++ alone, it is a matter of style.
    When you use objects, it still probably does not matter, but even if you want to use ++i, I still do not agree it is a good habit to always use. So ++i is NOT always better than i++ (which was the original statement). They have different uses, so use them accordingly.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #21
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Your claim, that MSVC and GCC will eliminate temporaries that are used solely for the return value of a function when a function is called from another file and the result is not used, is hard to believe. It's not an easy optimization to do, and would require two object code functions to be generated for each C function.

    ++i is always no worse than i++, when the return value is unused. That's the point I'm supporting. Therefor using ++i in such cases is a better habit.

    Preference does not exist for new users. Certainly, I have no problem with you using i++ in your code. But for a novice to C, who does not have a preference, it is best to be introduced to the best practice.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    I do not claim they will optimize temporaries. I claim they can optimize without seeing the function.
    But for the best practice bit, I simply disagree. Habits can cause problems, but they are also individual.

    Btw, for that matter, for this code:

    Code:
    #include <iostream>
    
    class Iterator
    {
    private:
    	int m_i;
    
    public:
    	Iterator(): m_i(0) {}
    	Iterator& operator ++ () { m_i++; return *this; }
    	Iterator operator ++ (int) { Iterator temp(*this); m_i++; return temp; }
    	bool operator < (int i) { return m_i < i; }
    	int operator * () { return m_i; }
    };
    
    int main()
    {
    	for (Iterator it; it < 10; it++)
    		std::cout << *it;
    	for (Iterator it; it < 10; ++it)
    		std::cout << *it;
    }
    I get this assembly output with optimizations (even better with inlining):
    00D21010 inc dword ptr [eax]
    00D21012 ret

    00D21020 mov ecx,dword ptr [edx]
    00D21022 mov dword ptr [eax],ecx
    00D21024 inc ecx
    00D21025 mov dword ptr [edx],ecx
    00D21027 ret

    Hardly expensive.
    Last edited by Elysia; 11-13-2009 at 12:29 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  8. #23
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Elysia
    All I am saying is that when using ++i or i++ alone, it is a matter of style.
    When you use objects, it still probably does not matter
    It may well be the case that even if the relevant optimisations are not performed, and there is actually a penalty in efficiency, that this penalty does not matter because it has a negligible effect compared to the overall execution cost. But since this possible inefficiency can be avoided without obscuring the code in any way, it is a matter of good style to use ++i instead of i++ where the expressions are standalone.

    Quote Originally Posted by Elysia
    but even if you want to use ++i, I still do not agree it is a good habit to always use. (...) They have different uses, so use them accordingly.
    I agree, if the expression is not standalone, it may be the case that post-increment is preferable.

    Quote Originally Posted by Elysia
    So ++i is NOT always better than i++ (which was the original statement).
    No, the original statement was just a suggestion by RockyMarrone to use ++i instead of i++. The part about it being an optimisation in this case may be misguided, but it was not a statement that ++i is always better than i++. saqib_'s recommendation that we should prefer ++i to i++ probably comes closest, but still the word "prefer" is not so strong as to imply that ++i is always better than i++.

    Quote Originally Posted by Elysia
    I do not claim they will optimize temporaries. I claim they can optimize without seeing the function.
    Are you sure? Such an optimisation sounds like it can change the meaning of the program, since ++i and i++ may well do completely different things.

    Quote Originally Posted by Elysia
    But for the best practice bit, I simply disagree. Habits can cause problems, but they are also individual.
    In what way can this particular habit (of using pre-increment instead of post-increment where the choice does not matter other than possible avoidance of needless inefficiency) cause problems?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  9. #24
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by laserlight View Post
    It may well be the case that even if the relevant optimisations are not performed, and there is actually a penalty in efficiency, that this penalty does not matter because it has a negligible effect compared to the overall execution cost. But since this possible inefficiency can be avoided without obscuring the code in any way, it is a matter of good style to use ++i instead of i++ where the expressions are standalone.
    A good point, and one I do not argue. It may be preferable to use ++i when using objects.

    No, the original statement was just a suggestion by RockyMarrone to use ++i instead of i++. The part about it being an optimisation in this case may be misguided, but it was not a statement that ++i is always better than i++. saqib_'s recommendation that we should prefer ++i to i++ probably comes closest, but still the word "prefer" is not so strong as to imply that ++i is always better than i++.
    I interpreted the way the conversation was going akin to:
    Use only ++i because it was/is better in some way i++, so we should always use it whenever possible.
    That is the claim I refute, because that is a matter of style.

    Are you sure? Such an optimisation sounds like it can change the meaning of the program, since ++i and i++ may well do completely different things.
    I was talking generally, not about removing the returning of a temporary.
    The link-time code generation option of MSVC allows the compiler to inline functions in other source files, and after inlining them, it can also perform some more optimizations on that inlined code. GCC also has such an option some time ago.
    So the claim that code cannot be optimized unless the compiler can see it is untrue. But any claim that the compiler will and can optimize away the returning of temporaries is mostly likely untrue. I have yet to see such a compiler.

    In what way can this particular habit (of using pre-increment instead of post-increment where the choice does not matter other than possible avoidance of needless inefficiency) cause problems?
    Sigh. I am voicing an opinion here, not an argument.
    Which is better is a matter of much debate, one of which I would rather not get into.
    But I do not believe in habits. I believe in free style - allowing the programmer to choose what is best for him or her.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  10. #25
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Elysia
    But I do not believe in habits. I believe in free style - allowing the programmer to choose what is best for him or her.
    Heheh...
    I know all the rules and then I know how to break 'em
    And I always know the name of the game.
    In my opinion, one needs to have some idea of the good habits in order to "free style" properly. Otherwise, the "free style" would just be the exercise of bad habits.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  11. #26
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    In a Coding Standard at a previous company, I believe this is how they worded that particular issue:
    Prefer pre-increment/decrement operators over post-increment/decrement operators unless you actually need to use a post-increment/decrement.
    Since ++i and i++ are equally easy to read, using ++i does not fall into the category of premature optimization, and it's always better than or equal to i++ whether the compiler optimizes it or not.

    Just because the language is called C++ doesn't mean you should prefer post-increment.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  12. #27
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Just because ++i is better does not mean you should prefer it over i++.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #28
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Elysia
    Just because ++i is better does not mean you should prefer it over i++.
    Kindly elaborate, otherwise your statement just sounds like nonsense.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  14. #29
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    I see it like a debate over C vs C++. Prefer whichever one suits you best.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #30
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by Elysia
    I see it like a debate over C vs C++. Prefer whichever one suits you best.
    Then you are just ignoring the facts in order to maintain your unreasonable position.

    The facts are that, when the expressions are standalone, pre-increment is no worse than post-increment in terms of efficiency, and can even be better. Therefore, there is no advantage in using post-increment instead of pre-increment in such a context. To say "pick whichever one suits you best" is thus bad advice.

    It would be good advice when we are faced between the choice of a standalone use of pre-increment along with another expression, or the combined expression with post-increment, in which case the choice is one of style: do you prefer to have two statements, or a single slightly more complex statement? However, the phrase "just because ++i is better" rules this situation out, since in this situation it is not clear if "++i is better".
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Memory problem with Borland C 3.1
    By AZ1699 in forum C Programming
    Replies: 16
    Last Post: 11-16-2007, 11:22 AM
  2. Someone having same problem with Code Block?
    By ofayto in forum C++ Programming
    Replies: 1
    Last Post: 07-12-2007, 08:38 AM
  3. A question related to strcmp
    By meili100 in forum C++ Programming
    Replies: 6
    Last Post: 07-07-2007, 02:51 PM
  4. WS_POPUP, continuation of old problem
    By blurrymadness in forum Windows Programming
    Replies: 1
    Last Post: 04-20-2007, 06:54 PM
  5. tolower function problem
    By Jack-Bauer in forum C++ Programming
    Replies: 6
    Last Post: 05-18-2006, 11:17 PM