Const and macro

This is a discussion on Const and macro within the C++ Programming forums, part of the General Programming Boards category; No stretching of the rules required....

  1. #16
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    No stretching of the rules required.

  2. #17
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    Modify const? No stretching? Const isn't supposed to be modified...
    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.

  3. #18
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,113
    Have you an example, Thantos? Assignment to a const seems illegal by definition.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  4. #19
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    const doesn't have to be universal to all that can see it.

  5. #20
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Off the top of my head

    foo.h
    Code:
    #ifndef FOO_H_
    #define FOO_H_
    
    #ifndef FOO_C_
    extern const int x;
    #endif
    
    void changevalue(int v);
    
    #endif
    foo.c
    Code:
    #define FOO_C_
    
    #include "foo.h"
    
    int x = 5;
    
    void changevalue(int v)
    {
    	x = v;
    }
    bar.c
    Code:
    #include <iostream>
    #include "foo.h"
    
    int main()
    {
    	std::cout<<"Before: "<<x<<std::endl;
    	changevalue(4);
    	std::cout<<"After: "<<x<<std::endl;
    }

    Granted that isn't the same as having:

    const int foo = 5;

  6. #21
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,113
    const doesn't have to be universal to all that can see it.
    Oh, but then in the given context it implies that the variable is not const.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  7. #22
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    22,897
    I'll accept that one, though! You can protect certain files from writing to a global variable, yet being able to read it.
    But this wouldn't be possible with a macro.
    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
    & the hat of GPL slaying Thantos's Avatar
    Join Date
    Sep 2001
    Posts
    5,681
    Quote Originally Posted by laserlight View Post
    Oh, but then in the given context it implies that the variable is not const.
    Yes and no. To everyone but the one file the variable is const. const just ensures that you can't change it. Lets say you had:
    Code:
    volatile const int x;
    Where x was tied to some hardware input. x is still const but it isn't a constant value and the compiler shouldn't assume it is.

  9. #24
    Registered User
    Join Date
    Apr 2008
    Posts
    890
    Quote Originally Posted by Daved View Post
    It doesn't sound like you understood what I was trying to get at. Then again, you accuse me of using a strawman argument, so perhaps I'm not understanding you. I think you implied that a tool cannot be considered evil. I am claiming that a tool can be considered evil.

    References are not considered evil because they do not unnecessarily allow users to do bad things with them, and there are no alternatives that are less evil.

    Macros are considered evil because they do allow users to do evil (by polluting namespaces, ignoring type rules, etc) and there are generally better alternatives (const, inline, etc).

    So, for someone to call a tool (in this case a feature of C++) evil is completely acceptable because there is an inherent difference between the evil tool and the not evil alternative.
    Macros are easier to abuse, but they still have valid uses. A chainsaw is easier to abuse than a carving knife, which is why I don't keep one at the dinner table on Thanksgiving. If someone cuts off their hand with a chainsaw carving up a bird, it isn't the chainsaw's fault.

  10. #25
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    22,113
    I think the problem is that the word "evil" is not well defined in this context, so the debate is rather pointless. Someone should write an essay entitled "Evil Considered Harmful".
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  11. #26
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    Macro's aren't evil; they have their uses. And I'm not just talking about include guards.

    But in C++, const variables are preferable to Macros, because they are type safe, and because they do not pollute the global namespace.

    When there are two ways to solve a problem, and using a macro is one of them, chances are the other option is better.

    But macros can be useful when you have a lot of repetitive code that cannot condensed within the syntax of the language. For example, if you have a lot of similar template specializations, that are nevertheless different from the default template.
    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.

  12. #27
    Registered User
    Join Date
    Jan 2005
    Posts
    7,344
    I'm basically using this definition of evil: http://www.parashift.com/c++-faq-lit....html#faq-6.15

    >> Macros are easier to abuse, but they still have valid uses.
    Did somebody claim otherwise?

    A tool that is easily abused can be called a bad tool. Whether you use the term evil or not isn't all that relevant. The point is that one should be wary of such a tool because it is easily abused. That does not imply that there are no valid uses.

  13. #28
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    I agree with your opinion on the proper use of macros.

    I disagree that there is anything wrong with macros; If I were to asked to redesign the language I would keep macros the way they are.
    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.

  14. #29
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Off the top of my head
    Instinctively, I'd say this is undefined behaviour.

    Less instinctively, gcc refuses to compile it if you pass the implementation file and at least one using file at the same time and use -combine. (-combine only works for C currently.)

    Edit: Finally found it! 3.5/10 in N2588 (most recent C++0x draft) says:
    "[...] the types specified by all declarations referring to a given object or function shall be identical [...]. A violation of this rule on type identity does not require a diagnostic."
    Last edited by CornedBee; 05-16-2008 at 04:47 PM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  15. #30
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    C99:
    Quote Originally Posted by 6.2.7 Compatible type and composite type
    2 All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.
    Quote Originally Posted by 6.7.3 Type qualifiers
    9 For two qualified types to be compatible, both shall have the identically qualified version of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers does not affect the specified type.
    Aww CornedBee beat me
    Quote Originally Posted by laserlight View Post
    I think the problem is that the word "evil" is not well defined in this context, so the debate is rather pointless. Someone should write an essay entitled "Evil Considered Harmful".
    That gets my vote.
    Last edited by robwhit; 05-16-2008 at 05:10 PM.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Errors including <windows.h>
    By jw232 in forum Windows Programming
    Replies: 4
    Last Post: 07-29-2008, 02:29 PM
  2. Macro has same name as Function?
    By coolclu3 in forum C Programming
    Replies: 10
    Last Post: 09-28-2007, 05:55 AM
  3. Defining const in a class
    By g4j31a5 in forum C++ Programming
    Replies: 5
    Last Post: 11-20-2006, 11:27 AM
  4. Is an inline function really the same as a macro?
    By Sloede in forum C Programming
    Replies: 6
    Last Post: 01-23-2004, 01:26 AM
  5. c and c++
    By Unregistered in forum C Programming
    Replies: 3
    Last Post: 04-12-2002, 05:50 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21