is C appropriate for intro to computers?

This is a discussion on is C appropriate for intro to computers? within the A Brief History of Cprogramming.com forums, part of the Community Boards category; Originally Posted by abachler Not in C it isn't. That was standard practice for decades before C++ required explicit type ...

  1. #136
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by abachler View Post
    Not in C it isn't. That was standard practice for decades before C++ required explicit type casting.
    Nevertheless, I will say bad practice (without an explicit cast). Most compilers will warn about it.
    A good programmer pays heed to warnings and silences them if the programmer needs the do what he/she does and stop the compiler from warning.

    As stated there are billions of lines of code 'out there' and people arent goign to spend the man hours to fix them all just so they can make the code C++ compliant when they dont use any C++ features.
    Again, I never said they should convert. Rather, I said they should use C++ on new projects instead and gradually phase out the old language.

    Quote Originally Posted by robwhit View Post
    > Erm, C is the base of C++. C++ is not restricted in such a sense.
    So I should cast void pointers just because some C++ guy says
    In C++ yes, because void* is not necessarily whatever-type-you-want*.
    But in C, it can be dangerous to do so due to a stupid flaw in the C89 standard and some compilers not complaining about this behavior.

    > It's better if it's aimed at the platform you're trying to develop, yes.
    C is aimed at the same platforms as C++, and more.
    C++ has a clear advantage where it's supported over C, which logically would suggest you choose C++, or some other language, over C for those platforms.

    > Just as it's better to learn PHP or Pearl
    Perl
    You mean to imply that Perl is better than PHP?
    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. #137
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,794
    You mean to imply that Perl is better than PHP?
    The language you call "Pearl" is named "Perl".
    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

  3. #138
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Oh I see the typo now. I knew that X_X
    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.

  4. #139
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    >In C++ yes, because void* is not necessarily whatever-type-you-want*.

    But why the change? It's already a generic pointer. What does adding a cast give you?

    > But in C, it can be dangerous to do so due to a stupid flaw in the C89 standard and some compilers not complaining about this behavior.

    If you're talking about implicit function declarations, then we already went over this, and it's not a problem in the real world.

    > C++ has a clear advantage where it's supported over C,

    not when you're compiling C code or C-style code.

    > which logically would suggest you choose C++, or some other language, over C for those platforms.

    By what logic?

  5. #140
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by robwhit View Post
    >In C++ yes, because void* is not necessarily whatever-type-you-want*.
    But why the change? It's already a generic pointer. What does adding a cast give you?
    void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.
    Therefore, it is good that the compiler complains or warns when convert from void* to something else.
    An explicit cast tells the compiler you know what you're doing.

    > But in C, it can be dangerous to do so due to a stupid flaw in the C89 standard and some compilers not complaining about this behavior.
    If you're talking about implicit function declarations, then we already went over this, and it's not a problem in the real world.
    So should we start teaching people to cast the return of malloc then? Is that why the FAQ states that you shouldn't cast the return of malloc?
    The problem is that this behavior still exists and some compilers do not complain at all. Casting the return actually masks the problem, which is very bad indeed.
    Should all compilers support it, then yes, it would not be a problem and the return should be cast.

    > C++ has a clear advantage where it's supported over C,
    not when you're compiling C code or C-style code.
    IMHO, yes it does. Stricter type security for one.
    But not very much, no. You are correct.

    > which logically would suggest you choose C++, or some other language, over C for those platforms.
    By what logic?
    Oh indeed, what logic?
    Why should we use C# for computer software when there's C?
    Hey, it's more portable and faster, so why should we use anything but C, regardless of for what we write it?

    The answer of why C# is used over C is the answer to why we should rather use C++ over C where possible.
    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. #141
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    > void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.

    No, there lies the genericity. People know what they're dealing with then they use a void pointer. It's a generic pointer.

    >Therefore, it is good that the compiler complains or warns when convert from void* to something else.
    An explicit cast tells the compiler you know what you're doing.

    But the compiler already knows what you're doing. It's just a matter of implicit versus explicit. As far as I am concerned, you made the choice when you chose the type of void pointer.

    > So should we start teaching people to cast the return of malloc then? Is that why the FAQ states that you shouldn't cast the return of malloc?

    Actually, I was arguing the opposite.

    > The problem is that this behavior still exists and some compilers do not complain at all.

    In that case, a compile with another compiler or a static analysis tool should fix it.

    > Casting the return actually masks the problem, which is very bad indeed.

    I was arguing for not casting, since it is unnecessary and makes cleaner code.

    > Should all compilers support it, then yes, it would not be a problem and the return should be cast.

    What compilers do not warn about implicit function declarations?

    > IMHO, yes it does. Stricter type security for one.

    And what benefit does being stricter give? You already declared that you want to use a generic pointer.

    > But not very much, no. You are correct.

    Thank you.
    Oh indeed, what logic?
    Why should we use C# for computer software when there's C?
    Hey, it's more portable and faster, so why should we use anything but C, regardless of for what we write it?

    The answer of why C# is used over C is the answer to why we should rather use C++ over C where possible.
    I don't see any logic in there. I see a different argument.

  7. #142
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by robwhit View Post
    > void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.
    No, there lies the genericity. People know what they're dealing with then they use a void pointer. It's a generic pointer.
    Therein lies the danger. It's generic. The compiler has no knowledge of the type it contains.
    A function that accepts a generic point can be difficult since you don't know type, size or how it looks like.
    Prone to mistakes. Bad for generic code.

    >Therefore, it is good that the compiler complains or warns when convert from void* to something else.
    An explicit cast tells the compiler you know what you're doing.
    But the compiler already knows what you're doing. It's just a matter of implicit versus explicit. As far as I am concerned, you made the choice when you chose the type of void pointer.
    But people make mistakes, you know.
    How is the compiler supposed to know you made it intentionally or if it was a mistake?

    > The problem is that this behavior still exists and some compilers do not complain at all.
    In that case, a compile with another compiler or a static analysis tool should fix it.
    I'm not sure I like that sound of that, though.
    But if you say it's not a problem, then I say cast the return of malloc. It's good practice.

    > Should all compilers support it, then yes, it would not be a problem and the return should be cast.
    What compilers do not warn about implicit function declarations?
    I don't know, I'm just echoing the FAQ, and various other members on the board stating that casting the return of malloc is bad™.

    > IMHO, yes it does. Stricter type security for one.
    And what benefit does being stricter give? You already declared that you want to use a generic pointer.
    A generic pointer can be anything, so the compiler is correct to be cautious.
    It stops silly mistakes and it prevents some nonsensical code from compiling (I know you're going to want examples, right?).

    I don't see any logic in there. I see a different argument.
    How so?
    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. #143
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,714
    Elysia, there is some value in keeping quiet after you've been reputably corrected by someone else. As the discussion continues, you usually learn more.

    Quote Originally Posted by Elysia View Post
    Therein lies the danger. It's generic. The compiler has no knowledge of the type it contains.
    A function that accepts a generic point can be difficult since you don't know type, size or how it looks like.
    Prone to mistakes. Bad for generic code.

    But people make mistakes, you know.
    How is the compiler supposed to know you made it intentionally or if it was a mistake?
    But it isn't the compilers responsibility to know. With void pointers, there isn't much you can do without specifying the underlying type. For assignment, it shouldn't make a difference what the type is, because a pointer contains a memory address, and all memory addresses can be expressed in a fixed number of bits. Usually this equates to the size of a word on modern platforms.

    But the point is, the programmer knows. Any function designed to work generically needs parameters to know the size of objects, to be sufficiently robust. You've probably used several examples, like memset, memcpy, qsort... I don't see the danger unless the programmer has forgotten something. If someone forgets that much they probably take a break or take a scalpel to the code. I don't see how C++ is any better in this regard either. Even if you're building something generic, you're bound to have type requirements and if you forget those, you need a break.

    You're free to call C's method an ugly hack, but don't misunderstand things. C++ didn't "fix" problems with void *, it reimplemented the whole concept of generic programming. The benefit of templates over void * is that most logical mistakes related to type will be caught by the compiler at compile-time instead of run-time. That's valuable.

    Quote Originally Posted by Elysia View Post
    void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.
    Wow, I didn't know we were in the presence of a five star programmer. *awe*
    Last edited by whiteflags; 10-09-2008 at 03:39 PM.

  9. #144
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    > Therein lies the danger. It's generic. The compiler has no knowledge of the type it contains.

    But that's the point. What type would you have malloc return?

    > A function that accepts a generic point can be difficult since you don't know type, size or how it looks like.

    Claims without evidence. Also, if you assigned something to a void *, you'd know what type and size it was.

    > Prone to mistakes.

    Perhaps if you use it wrong.

    > Bad for generic code.

    Perhaps if you use it wrong. Claims without evidence.

    > But people make mistakes, you know.
    How is the compiler supposed to know you made it intentionally or if it was a mistake?

    Explicit casts wouldn't do much to help that. What would help would be a less ambiguous API. void pointers are a means to an end, not always an end itself.

    >I'm not sure I like that sound of that, though.
    But if you say it's not a problem, then I say cast the return of malloc. It's good practice.

    edit: I messed this up a bit. here's the fix:

    Not casting malloc
    Cons:
    1. ?
    Pros:
    1. implicit function declarations are exposed
    2. Cleaner code
    3. Less to change in case you change the type
    This makes 3 advantages and no disadvantages. I'd say that not casting malloc is better, and at the least, a style issue.

    > I don't know, I'm just echoing the FAQ, and various other members on the board stating that casting the return of malloc is bad™.

    That's not what you were doing above.

    > A generic pointer can be anything, so the compiler is correct to be cautious.
    It stops silly mistakes and it prevents some nonsensical code from compiling (I know you're going to want examples, right?).

    You read my mind.

    > How so?

    I don't see how C# vs C is relevant to C++ vs C. Furthermore, you said that C was faster, presumably giving C the advantage.
    Last edited by robwhit; 10-09-2008 at 06:28 PM.

  10. #145
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Arrrh, for the last time... speed isn't everything

    This discussion is stupid, seriously. It's like trying to convince a brick wall that it's made of bricks, but it thinks it's better than that...

  11. #146
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    No, it's made of bricks and mortar.

  12. #147
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by Elysia View Post
    void* can be anything - it can be int*, it can be be double**, even your_own_struct*****. Therein lies the danger.
    No, therin lies its usefullness. Keeping track of what the generic pointer actually points to is the programmers job. If you can't remember from one line of code to the next what a pointer points to, then you don't need to be programming anything more complex than a microwave.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  13. #148
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,487
    The sheer level of stupidity in this thread is probably already epic. Even I - who can swim around a pool of stupidity and feel right at home - am having trouble keeping up.

    How can someone be told by absolutely everyone she's wrong, and still keep a straight face pouring all the that bull? Not only that, but the arguments presented are solid, sound, strong. The sheer display of ignorance is outstanding. But the lack of humility... jeebus! The lack of humility is the most dangerous I've ever met in my entire life.

    Someone who can't simply for one second admit, "look folks you are probably right. It's everyone but me so probably the problem is me. I'll think better about all this business". You deserve nothing less than my absolute disrespect because you obviously have nothing but contempt towards everyone in here wasting their breath trying to put some sense into that stupid head of yours. So screw you too.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  14. #149
    Woof, woof! zacs7's Avatar
    Join Date
    Mar 2007
    Location
    Australia
    Posts
    3,459
    Yes it is a shame. A long time ago I used to think the same, "C#, and especially Java are crap because they're slow / not powerful". Which is stupid, there are VERY, VERY, VERY few programs out there that are going to gain anything by running 0.0000001 seconds faster.

    However, I saw the light . Mainly because people such as those that can be found on this forum. Listen or you'll end up regretting it later.

  15. #150
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,663
    Quote Originally Posted by robwhit View Post
    I don't see how C# vs C is relevant to C++ vs C. Furthermore, you said that C was faster, presumably giving C the advantage.
    What I meant was...
    If you targeted a Windows PC, you could have the choice of using C or C#. Which would be better and why?
    Assume it's a company. They want software out there and they want it pronto. Lots of features, and few bugs (or they'd get complaints).

    Then put yourself in the chair and assume it was a choice between C and C++. Which would you choose in this case?

    And as not everyone seems aware... on a private level, I listen but don't accept because my individuality says not to. It's who I am and full of my opinions and I can't change it. I find code nicer and cleaner with explicit casts even.
    On a professional level, I listen closely and absorb, because jobs aren't about choice, they're about doing it and doing it right.
    You say it's a choice of what language to choose, the right one for the job. So on a private level, my own individual work, I choose C++, even though it may be inferior to C# because it's what I like, just as you would sometimes choose C for such projects because it's your language of choice. On a professional level, I will simply select the language that gets the software out the door as fast as possible and with as few bugs as possible. Simple.
    Last edited by Elysia; 10-10-2008 at 12:44 AM.
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Numeric addresses for computers
    By great in forum C Programming
    Replies: 4
    Last Post: 08-23-2010, 11:53 AM
  2. Computers as authors
    By hk_mp5kpdw in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 11-22-2004, 07:55 PM
  3. Industrial vs home computers
    By nbo10 in forum Tech Board
    Replies: 10
    Last Post: 09-01-2004, 02:04 AM
  4. Matrix and vector operations on computers
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 05-11-2004, 06:36 AM
  5. Love programming, hate computers
    By PJYelton in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 12-14-2002, 12:04 PM

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