Thread: Unofficial extensions to C, structs with functions, does that exist?

  1. #16
    Registered User
    Join Date
    May 2010
    Location
    Naypyidaw
    Posts
    1,314
    C++ backward compatibility with C is Evil!

  2. #17
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Yes, it is.
    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
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    Nuh uh!!!

  4. #19
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Yes, it is. It has caused problems before and is likely to do so again.
    C++ should support C natively and not be backwards compatible. That would be the best things, but is unlikely to happen.
    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.

  5. #20
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    > C++ should support C natively and not be backwards compatible.
    That's contradictory.

    I was just being contrary. I agree, I guess.

  6. #21
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Not exactly. C++ is backwards compatible with C in a sense that any C code should be able to compile with a few modifications under C++. This is bad, because it means C++ must inherit whatever nonsense C has, such as void* pointers.
    OTOH, if C++ supported C natively, it means that it would support low-level features that completely supports C++'s approach. No more void*. No more passing native arrays. Etc. Etc.
    Plus there's no problems with features clashing, such as auto. It was delayed until the 0x standard due to problems with the C standard. It is much easier to change such things if it within the same standard.
    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.

  7. #22
    Registered User
    Join Date
    Jul 2010
    Posts
    33
    I don't think C++ would of been as popular as it is, if it had not been backwards compatible with C. But that can never be proved. So...

    Also with the function name being equal to the address of the function, I don't think it is evil at all. Why is it evil compared to &get_a?
    ( if you ask me &get_a confuses me because get_a is the address of the function so that would mean &get_a is the address of the address of the function, in a semantic sense, no?)

    I also disagree with the void pointers comment, sure if used incorrectly they cause problems but so could any language feature. I use void pointers to implement generics and I find it a rather useful language feature. Of course, I'm not an expert...

  8. #23
    Registered User
    Join Date
    Jul 2010
    Posts
    33
    Quote Originally Posted by User Name: View Post
    I know, if I want OOP I should go to cpp, but I still prefer C for no real reason. Is there a C compiler that supports defining structure members that are functions? GCC by default, doesn't. I didn't try any other standards.
    You can implement OOP in C using structs, function pointers, etc. Have you read Object Oriented Programming With ANSI C?

  9. #24
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by CSaw View Post
    Also with the function name being equal to the address of the function, I don't think it is evil at all. Why is it evil compared to &get_a?
    Because a function is not a variable. You cannot copy the contents of a function into somewhere else. That is why get_a makes no sense.

    ( if you ask me &get_a confuses me because get_a is the address of the function so that would mean &get_a is the address of the address of the function, in a semantic sense, no?)
    No, it doesn't. get_a is the contents of the function, similarly to a variable. And to take the address of something, you must the use the address of operator. Hence it makes perfect sense while get_a makes no sense at all.

    I also disagree with the void pointers comment, sure if used incorrectly they cause problems but so could any language feature. I use void pointers to implement generics and I find it a rather useful language feature. Of course, I'm not an expert...
    In C you will find it useful, but in C++ it is completely redundant and pretty much only supported for backwards compatibility. That is because templates can completely replace void*.
    So having to support it is just a pain, extra baggage, so to speak, for C++. That is one area where backwards compatibility hurts the language.
    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
    27,272
    Quote Originally Posted by Elysia
    Because a function is not a variable. You cannot copy the contents of a function into somewhere else. That is why get_a makes no sense.
    I do not follow your reasoning. You are pretty much ignoring the fact that function designators are converted to function pointers.

    Quote Originally Posted by Elysia
    No, it doesn't. get_a is the contents of the function, similarly to a variable.
    I would say that get_a is the name of the function.

    Quote Originally Posted by Elysia
    And to take the address of something, you must the use the address of operator.
    No, that is not true. The C standard contradicts you on this point.

    In a way, this is an illusion: functions are not really first class objects in C, but this syntax, along with the corresponding ability to call the function via the function pointer without explicitly dereferencing the pointer, makes it such that in this context of argument passing functions appear to be first class objects.
    Last edited by laserlight; 07-21-2010 at 09:41 AM. Reason: converts -> converted
    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
    Registered User
    Join Date
    May 2010
    Location
    Naypyidaw
    Posts
    1,314
    When the name of a function appears in an expression, it ``decays'' into a pointer (that is, it has its address implicitly taken), much as an array name does.
    Question 1.34
    Question 4.12

  12. #27
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Consider variables. To create one, we use a declaration. Similarly, we create functions (though we must also define what they contain later).
    To assign the contents of a variable somewhere else, we type the name of the variable. Example:
    Code:
    int x = my_other_var;
    Imagine that my_other_var is now a function. What is the contents of a function? In the current C standard, you cannot copy an array, let alone a function, so this assignment would make no sense.
    Now, how about we take the address of said variable?
    Code:
    int* x = &my_other_var;
    This is intuitive. We use the address-of operator. apply similar logic to functions and we see it makes sense because functions have an address in memory where its code is placed.

    This might be strict "standardese," but it follows the basic C syntax and principles.

    We might also consider arrays. We can indeed create a pointer to an array. That is a pointer to an array. Incrementing it skips forward one array.
    For some reason, probably convenience, it is also possible to omit the address-of operator when assigning or passing arrays. This gives us a pointer to its first element.
    Does that make sense for a function? Not in the current standard.

    Special syntax for things only serve to confuse people and make the language more difficult to learn and parse.
    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
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,612
    My favorite site, function-pointer.org, says that using the address of operator is the most compatible thing across compilers. Strangely, no such statement is made for the dereference operation.

    2.3 Assign an address to a Function Pointer

    It's quite easy to assign the address of a function to a function pointer. You simply take the name of a suitable and known function or member function. Although it's optional for most compilers you should use the address operator & infront of the function's name in order to write portable code. You may have got to use the complete name of the member function including class-name and scope-operator (::). Also you have got to ensure, that you are allowed to access the function right in scope where your assignment stands.

    2.5 Calling a Function using a Function Pointer

    In C you call a function using a function pointer by explicitly dereferencing it using the * operator. Alternatively you may also just use the function pointer's instead of the funtion's name. In C++ the two operators .* resp. ->* are used together with an instance of a class in order to call one of their (non-static) member functions. If the call takes place within another member function you may use the this-pointer.
    If we are to believe this text is completely up to date with standards, then it appears that address of came first, and is the "evil backwards-compatibility feature" according to Elysia. Actually, I agree. Find me a compiler people actually use that doesn't call/assign by function name and I will eat this post. Implementations that can't do this simple thing ought to be broken.

    But that's just me. & also happens to be the most erotic ASCII character. I don't have anything against it, but I will perhaps question why fubarc 2.1 was the best compiler around for the project.

    To me, there is nothing confusing or contrary about function names being pointers. Think of it like having a pointer named after the function already in scope, and then assigning it to other function pointers becomes completely consistent with even C++ syntax. How about that?
    Last edited by whiteflags; 07-21-2010 at 10:00 AM.

  14. #29
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,272
    Quote Originally Posted by Elysia
    For some reason, probably convenience, it is also possible to omit the address-of operator when assigning or passing arrays. This gives us a pointer to its first element.
    Does that make sense for a function? Not in the current standard.
    I disagree. I think that it makes sense, if you can understand it as an exception for convenience, or possibly even my conjecture about the illusion of functions as first class objects in this context. The same thing applies to arrays: it does not make sense for an array to decay to a pointer to its first element, using your reasoning.

    Knowing your preference of C++, allow me to cite a problem you have following your logic all the way to function pointers and function objects. Taking your reasoning to its logical conclusion, we should indeed call a function through a function pointer f as (*f)(args), because f(args) is inconsistent with pointer notation. Now, if we were to write a generic algorithm that is supposed to apply say, a predicate, we complicate matters: if the predicate is a function pointer, we should dereference it, but if it is a function object, we should not.

    Quote Originally Posted by Elysia
    Special syntax for things only serve to confuse people and make the language more difficult to learn and parse.
    I can agree with this, but this special syntax is common and well understood. Trying to avoid it is futile.
    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

  15. #30
    Password:
    Join Date
    Dec 2009
    Location
    NC
    Posts
    587
    I think w/o & is better because it fits with the pattern that when calling a location you don't put & in front of it.
    Code:
    void realfunc();
    int main()
    {
        ((void (*) ()) 10) ();
        ((void (*) ()) realfunc) (); // same as "realfunc();" not "&realfunc();"
        return 0;
    }
    void realfunc(){}
    It's hard to explain what I mean, but I think you'll understand.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Expression Manipulator v0.2 (bug fixes, functions)
    By ygfperson in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 05-26-2003, 04:52 PM
  2. Replies: 4
    Last Post: 04-01-2003, 12:49 AM
  3. passing structs to functions?
    By Neildadon in forum C++ Programming
    Replies: 1
    Last Post: 12-13-2002, 04:31 PM
  4. API "Clean Up" Functions & delete Pointers :: Winsock
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 05-10-2002, 06:53 PM
  5. probs with structs and functions
    By Unregistered in forum C Programming
    Replies: 10
    Last Post: 05-08-2002, 11:52 PM

Tags for this Thread