Like Tree7Likes

Decision Making

This is a discussion on Decision Making within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Tamim Ad Dari So learning C and C++ basics will be helpful because in some problems It ...

  1. #16
    Registered User
    Join Date
    Mar 2010
    Posts
    535
    Quote Originally Posted by Tamim Ad Dari View Post
    So learning C and C++ basics will be helpful because in some problems It is easier to solve in C than C++ and vice versa.
    I think I agree with that.

    Some problems feel like they would be most naturally solved in C++ over C. I don't necessarily mean the ones that cry out for full OO -- but sometimes you really want objects with functions and state -- and that's less natural in C. On the other hand, I wouldn't use C++ for a problem I could solve in C.

    Still, given that, I think learning C and C++ at the same time isn't a great idea. I think C++ without OO, templates, STL, etc... is going to be confusingly similar-yet-different to C. My advice would be to focus on your university C course first, since that's what you're meant to be doing at the moment.

    Quote Originally Posted by Elkvis
    the advice you'll get from most members (including myself) on the C++ forum here is to learn C++ first. chances are, if you learn C++, you'll understand C readily
    Really? I would have thought it'd be easier to go the other way - learn C first. Because you can do everything in C++ that you can do in C, and more. Whereas going the other way I'd expect you to be often confounded by not being able to do something. I suppose C is a lot simpler so maybe it is a good way around to do it.

    I sort of learned C-like-C++ (it was C++, but I was just learning the C bits of it) first, then C properly, then improved my C++ knowledge somewhat (it's not great). It wasn't a good way to learn -- so OP, if you do decide to learn both, try to keep them separate in your head.

  2. #17
    Registered User
    Join Date
    Jun 2005
    Posts
    6,679
    Quote Originally Posted by Elkvis View Post
    I recommend learning both C and C++, but the advice you'll get from most members (including myself) on the C++ forum here is to learn C++ first.
    I agree with you that it is a good idea to - eventually - learn both C and C++. But in terms of the advice from "most members" I must be in a minority - I don't advocate any order in which they should be learned.

    The general advice I give is to pick one, and learn that. If you know enough to know you will need to use one or the other, pick that one. If courses available to you only teach one of them, pick that. If you clearly have the option of learning one or the other, and no real reason to prefer one, flip a coin.

    Whichever way you learn C and C++, there will be an unlearning and relearning (of practices that are considered good in one of them, but not the other) element of transitioning from one to the other.


    It is possible to learn C and C++ together. That is not really a good option for beginners to programming though - it would be difficult without a decent level of experience with other programming languages (or, for those with a theoretical bent) an understanding of computer science.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  3. #18
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Quote Originally Posted by smokeyangel View Post
    ...On the other hand, I wouldn't use C++ for a problem I could solve in C.
    That's just silly.
    If you can use C++ instead of C, then you should do it (I am purposefully ignoring factors such as cost, availability, etc that can an effect on what language to choose here to make this simple).
    C++ is, at the very least, a stronger C. If the problem does not naturally lend itself to an OOP solution, C++ still have way more features that help you solve your problem than C.
    Choosing C over C++ simply because you can is just silly.
    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. #19
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,763
    To be fair, your preferences are equally silly. You're reading too much into that statement.

  5. #20
    Registered User
    Join Date
    Mar 2010
    Posts
    535
    Quote Originally Posted by Elysia View Post
    That's just silly.
    If you can use C++ instead of C, then you should do it (I am purposefully ignoring factors such as cost, availability, etc that can an effect on what language to choose here to make this simple).
    C++ is, at the very least, a stronger C. If the problem does not naturally lend itself to an OOP solution, C++ still have way more features that help you solve your problem than C.
    Choosing C over C++ simply because you can is just silly.
    If you say so I know C a lot better (there's less to know...) so I'm less likely to make some horrible inefficiency bungle or other mistake.

    I'll use C++ when appropriate - I just don't think it's appropriate all the time. If I were to write a little program that took some input and printed output, I'd use cstdio rather than iostream. It's those kinds of cases where I don't have anything to gain by using C++.

  6. #21
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Well, I mean, clearly if you know a language better than something other, you would want to use the one you are more familiar with. That's natural.
    But that was not my point. If you know C and C++, both roughly equally well, then it would be silly to use C when you can use C++.
    The fact that you seem to prefer to use C over C++ for simple tasks seems to imply that you simply are not familiar enough with C++ yet. But it's a personal preference, so don't sweat it. So long as it is a hobby, using whatever language you are most familiar with is fine.
    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 whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,763
    Thanks for contributing essentially nothing.

    But that was not my point. If you know C and C++, both roughly equally well, then it would be silly to use C when you can use C++.
    He doesn't, he admits this in his own posts.

    The fact that you seem to prefer to use C over C++ for simple tasks seems to imply that you simply are not familiar enough with C++ yet. But it's a personal preference, so don't sweat it. So long as it is a hobby, using whatever language you are most familiar with is fine.
    He also says that he works, so programming is more than a hobby.

  8. #23
    Registered User
    Join Date
    Mar 2010
    Posts
    535
    She

    Yep, I'm a software engineer. Of all things, I work on a C/C++ compiler. It's written in C++ -- parts of it are very C++y, full of templates and polymorphism, but quite a lot of it is C-like. I'm competent in C++, not afraid of it, I just prefer C.

    It's a personal preference. And as I said, I will use C++ if it seems appropriate.

    I'm not sure exactly what I'm supposed to be missing out on. What's so much better about C++ when the task does not need any of the extra features of C++? Most people I know share the same preference for C -- but the ones who prefer C++ don't seem to be noticably more productive.

    [edit] -- just to repeat what whiteflags already repeated for me: I do not know C++ as well as I know C. For C, I know exactly what the executable will look like - I know what happens for e,.g. a function call, library init, stack use, heap use.
    C++ I don't have the same depth of knowledge about. There's a lot to know -- it's so much more complicated than C. I know how virtual functions are handled by the compiler and runtime, but I've no idea about things like exception unwind tables etc etc. The standard library appears to be a goliath, and I don't know anything about that either.

    I'm not saying that I won't code in a language until I know exactly how it's compiled -- I'm just saying I prefer C and that my C++ knowledge is not equal to my C knowledge.
    Last edited by smokeyangel; 02-23-2013 at 02:34 PM.

  9. #24
    Registered User
    Join Date
    Jan 2013
    Posts
    114
    In contests , It is better to use C I think. Cause some functions in C like printf,scanf works faster than cout and cin. So using C++ there is a chance to get the time limit exceeded.

  10. #25
    Registered User
    Join Date
    Jun 2005
    Posts
    6,679
    Quote Originally Posted by Tamim Ad Dari View Post
    In contests , It is better to use C I think. Cause some functions in C like printf,scanf works faster than cout and cin. So using C++ there is a chance to get the time limit exceeded.
    That has got to be the weakest argument I've ever heard for preferring any programming language over another.

    You're comparing the speed of two snails. I/O is a performance bottleneck, regardless of programming language, and regardless of how library capabilities are implemented.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  11. #26
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Quote Originally Posted by whiteflags View Post
    Thanks for contributing essentially nothing.

    He doesn't, he admits this in his own posts.

    He also says that he works, so programming is more than a hobby.
    Thanks for your pointless contribution.

    Quote Originally Posted by smokeyangel View Post
    I'm not sure exactly what I'm supposed to be missing out on. What's so much better about C++ when the task does not need any of the extra features of C++? Most people I know share the same preference for C -- but the ones who prefer C++ don't seem to be noticably more productive.
    Better type safety, templates, objects that can store state, lambdas, the ability to write more generic code (ie, auto, decltype). A massive library of pre-written code with common containers and algorithms. Compile-time computation. Etc. Etc. Etc.
    And don't tell me that there is no program that will not benefit from any of these features. I find that extremely hard to believe. Most will benefit from at least one.

    Also, you really don't need to be aware of exactly what happens in the executable when you write your code. That's the whole point of portability and genericness - write once, deploy anywhere. If you must know what something does, then you have violated this rule. Yes, I know there are sometimes you must know certain things. In embedded systems, for example, it is almost critical to know what memory ends up where (for example, embedded memory or sdram). But that's just one little detail. The rest you can mostly ignore.
    smokeyangel likes this.
    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.

  12. #27
    Registered User
    Join Date
    Jun 2005
    Posts
    6,679
    Quote Originally Posted by smokeyangel View Post
    It's a personal preference. And as I said, I will use C++ if it seems appropriate.
    A lot of people say "I prefer X over Y, but will use Y if it seems appropriate." It's amazing how often their preference then seems to influence what they consider appropriate.

    Quote Originally Posted by smokeyangel View Post
    I'm not sure exactly what I'm supposed to be missing out on.
    If you don't know what you're missing out on, then you will make decisions on the premise that you are missing out on nothing. That is human nature.

    Quote Originally Posted by smokeyangel View Post
    What's so much better about C++ when the task does not need any of the extra features of C++? Most people I know share the same preference for C -- but the ones who prefer C++ don't seem to be noticably more productive.
    I wouldn't actually read anything into that observation. Those who prefer C++ will probably make the same observation about those who prefer C.

    The value of the extra features of C++ depends on the task at hand. There are some things that a C++ programmer can achieve significantly faster than a C programmer. There are other things that a C programmer can achieve significantly faster than a C++ programmer.

    I would certainly not ask someone who openly prefers C and who questions the value of C++ to assess the productivity of a C++ developer. Similarly, I would not ask someone who openly prefers C++ and who questions the value of C to assess the productivity of a C developer. Both assessments will exhibit cognitive bias. They will each, for example, tend to pick measures or metrics that suit their preference.

    Quote Originally Posted by smokeyangel View Post
    There's a lot to know -- it's so much more complicated than C.
    Sure, but once you get a handle on those complications, a lot can be done quite quickly in C++.

    There are plenty of examples where making use of the C++ standard library allows writing a few lines to do what takes orders of magnitude more code than in C. That catch is that the knowledge and thought (i.e. intellectual effort) to write the C++ code and the C code can be equivalent, depending on experience of the developers. An advantage of C++, in this scenario, is that a few lines of code are easier to get right than a lot of lines while an advantage of C is that the developer will probably have more understanding of the implementation details. Either of those advantages, however, can be disadvantages, depending on the task at hand.

    Quote Originally Posted by smokeyangel View Post
    I know how virtual functions are handled by the compiler and runtime,
    Your words imply there is only one approach to handling virtual functions, which is wrong. That suggests you know one strategy for handling of virtual functions by the compiler and runtime (presumably, the virtual function table, which is often used). There are other strategies, each with different trade-offs.



    Quote Originally Posted by smokeyangel View Post
    The standard library appears to be a goliath, and I don't know anything about that either.
    That's ironic. One of the reasons for advocacy of some other languages is their "comprehensive" library - which usually refers to a library considerably larger than the C++ library.

    In any event, the C library is not exactly small. It is true that the C++ library is larger. And that there are plenty of things that can be achieved with the C++ library that require a significant body of code to implement in C.

    Quote Originally Posted by smokeyangel View Post
    I'm not saying that I won't code in a language until I know exactly how it's compiled.
    No, but you are suggesting that you will lean toward a language if you (think you) know exactly how it is compiled.

    In some ways, expecting to have an exhaustive model of how a language is compiled is at odds with the philosophy of C++ - where the point is to focus on what you seek to achieve, rather than in how to build it from the ground up.

    Given the complexity of some modern C compilers, the fact that a lot of C compilers are actually C++ compilers, and the fact that C and C++ compilers both do significant code transformation and optimisation it is a fair bet that you have one mental model of how C compilation works, but that model is quite different from reality.
    Elysia and smokeyangel like this.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

  13. #28
    Registered User
    Join Date
    Mar 2010
    Posts
    535
    Quote Originally Posted by Elysia View Post
    Better type safety, templates, objects that can store state, lambdas, the ability to write more generic code (ie, auto, decltype). A massive library of pre-written code with common containers and algorithms. Compile-time computation. Etc. Etc. Etc.
    "Objects that store state" is very useful and something I use quite often. I also use containers when I need to.

    I think very hard before I use templates. If I find myself copy/pasting a function and changing just one thing in each.... I'll use templates.
    For more interesting and complicated situations where you'd have multiple template parameters, I'd stop and think. In my experience, complicated template stuff is surprisingly easy to write and shockingly difficult for anyone else to read.
    Just because you can parameterise your code to hell and back doesn't mean you should!

    I honestly don't find myself in need of the swishy features of C++ very often. I'm familiar enough with some bits of C++ to know when I should be using them - but other parts... I'll obviously make a limited judgement based on limited knowledge.
    So that's not saying "I prefer C" - that's "I don't know C++ very well" again.

    If there's no need to use any of the snazz, then I think a C++ programmer and a C programmer would write pretty similar programs. I imagine we'd differ on new/delete vs malloc/free, iostream vs stdio, and possibly char* vs string.

    I don't care about malloc at all, I'd happily use new instead.

    I do prefer printf though. I don't see why I should be forbidden from using it, it's allowed in C++ isn't it? I know it's not typesafe, but I'll live. I like writing output as a string with format specifiers. The cout way of doing it is harder to visually relate to the output you'll see.
    char* and string.... I'm perfectly happy with char* -- I don't feel the need for a class. If I were to use string, I think I'd have to jump on the stream bandwagon as well, since that seems to provide the functionality you'd ususally use sprintf() for.

    I've definitely seen char* and stdio used in C++ programs before. Is this a Bad Thing? Why?

    Quote Originally Posted by grumpy View Post
    The value of the extra features of C++ depends on the task at hand. There are some things that a C++ programmer can achieve significantly faster than a C programmer. There are other things that a C programmer can achieve significantly faster than a C++ programmer.

    I would certainly not ask someone who openly prefers C and who questions the value of C++ to assess the productivity of a C++ developer. Similarly, I would not ask someone who openly prefers C++ and who questions the value of C to assess the productivity of a C developer. Both assessments will exhibit cognitive bias. They will each, for example, tend to pick measures or metrics that suit their preference.
    That's fair.

    After I replied, I realised I did recently write something in C that would have been better in C++ (needed persistent state and needed to prepend something to a string -- both easier in C++). And I've just remembered I had to call realloc a couple of times. Yes, I should have written that in C++.

    Quote Originally Posted by grumpy
    Your words imply there is only one approach to handling virtual functions, which is wrong. That suggests you know one strategy for handling of virtual functions by the compiler and runtime (presumably, the virtual function table, which is often used). There are other strategies, each with different trade-offs.
    Quite right. I should have said that I knew how it worked on one specific compiler. Although I thought vtable structure was part of the generic C++ ABI?

    Quote Originally Posted by grumpy
    That's ironic. One of the reasons for advocacy of some other languages is their "comprehensive" library - which usually refers to a library considerably larger than the C++ library.

    In any event, the C library is not exactly small. It is true that the C++ library is larger. And that there are plenty of things that can be achieved with the C++ library that require a significant body of code to implement in C.
    So, I have a rough idea of some of the sorts of things supported in the libraries. If I needed to use some sort of resizable container I'd know that a number are available. I wouldn't be able to name the right one for the job without looking them up.
    There are doubtless tons of things in there that I've never even heard of.

    Quote Originally Posted by grumpy
    No, but you are suggesting that you will lean toward a language if you (think you) know exactly how it is compiled.
    Quote Originally Posted by Elysia
    Also, you really don't need to be aware of exactly what happens in the executable when you write your code.
    I've had to think about this a bit and about what I was trying to say before, and have changed my mind

    I think it would have been more accurate for me to say "know exactly how it behaves at runtime" and then soften that to "know roughly how it might behave at runtime".

    To explain: When I think about it further, it wasn't working on a compiler that made me understand C better - it was spending a lot of time looking at machine code when I first started working on embedded stuff. Suddenly a lot of 'fluffy' C concepts made sense, So it's not really anything to do with knowing how the compiler does its business.

    Now - these days I work on code compiled for x86 (Linux and Windows) so I expect much of the mental model I have of C is invalid. That doesn't bother me though -- I have *a* mental model of how it works, which helps. Less so now, but when I was unfamiliar with C it helped a lot.

    It's my natural instinct to try to break something down into its most basic form and figure it out from there. I think that's fairly common and I don't think it's wrong. However, I don't think staring at disassembly of C++ objects all day would improve my C++ expertise - especially given that my main blind spot is the library support.

    I still think that understanding how things are implemented is a good thing. An interesting thing. But probably not a necessary thing, and may have no tangible benefit. For example, I used printf for years without knowing how it handled all those arguments. I didn't gain any additional printf powers by looking into it, but I'm pleased to know (for one toolchain/architecture).

    So, I think my revised stance on C++ is that there's a lot of it that is still "magic" to me (e.g. iostream), and I'll be happier once i know a bit more about them,

  14. #29
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Quote Originally Posted by smokeyangel View Post
    I do prefer printf though. I don't see why I should be forbidden from using it, it's allowed in C++ isn't it? I know it's not typesafe, but I'll live. I like writing output as a string with format specifiers. The cout way of doing it is harder to visually relate to the output you'll see.
    char* and string.... I'm perfectly happy with char* -- I don't feel the need for a class. If I were to use string, I think I'd have to jump on the stream bandwagon as well, since that seems to provide the functionality you'd ususally use sprintf() for.
    I squirm when I hear you say you prefer char* over std::string and you are working on a compiler. A compiler! For two extremely popular platforms!
    Do you understand what you are doing? I don't think so. Your limited experience with higher level languages is causing you to make bad decisions and those decisions are going to reflect on whomever is using your software.
    You should really, really, really start learning C++, C#, Java, whatever. Any higher-level language than C will do. Get familiar with them, and start using them as replacements for C as much as possible to break your habits on using C stuff instead of higher-level stuff.
    C stuff is dangerous. C will cause more bugs, harder-to-read code (yeah, good luck reading all that reallocation and stuff with arrays and dynamic buffers), and are prone to many more security issues than higher-level code.
    You have a very dangerous mindset for a software engineer. Your goal is to create flexible, easy to read, bugfree and secure code. C was not made to fulfil those goals on modern platforms. C is much more suited for platforms where resources are scarce and behemoth languages cannot work.

    Quote Originally Posted by smokeyangel View Post
    I honestly don't find myself in need of the swishy features of C++ very often. I'm familiar enough with some bits of C++ to know when I should be using them - but other parts... I'll obviously make a limited judgement based on limited knowledge.
    So that's not saying "I prefer C" - that's "I don't know C++ very well" again.
    Quote Originally Posted by smokeyangel View Post
    If there's no need to use any of the snazz, then I think a C++ programmer and a C programmer would write pretty similar programs. I imagine we'd differ on new/delete vs malloc/free, iostream vs stdio, and possibly char* vs string.
    I beg to differ. There is always place for the "snazz". std::string by itself even is a huge difference. Stop trying to convince yourself that you may not certain features. Start trying to convince yourself if these features can make a difference. std::string makes a huge difference in terms of bugs, security and bugs.

    Quote Originally Posted by smokeyangel View Post
    I've definitely seen char* and stdio used in C++ programs before. Is this a Bad Thing? Why?
    Depends on the context. Sometimes they are necessary, but more than often it is used by "C+" programmers who are somewhat stuck between C and C++. Unless you absolutely need them, don't use them. They are mostly unsafe and complex, whereas C++'s features are typically (everything is not always better, so typically it is) safer and easier.

    Quote Originally Posted by smokeyangel View Post
    I think very hard before I use templates. If I find myself copy/pasting a function and changing just one thing in each.... I'll use templates.
    For more interesting and complicated situations where you'd have multiple template parameters, I'd stop and think. In my experience, complicated template stuff is surprisingly easy to write and shockingly difficult for anyone else to read.
    Just because you can parameterise your code to hell and back doesn't mean you should!
    No, it doesn't. It's always a trade-off, but unless you are familiar enough with a language, you can't make those decisions very well.


    Quote Originally Posted by smokeyangel View Post
    I still think that understanding how things are implemented is a good thing. An interesting thing. But probably not a necessary thing, and may have no tangible benefit. For example, I used printf for years without knowing how it handled all those arguments. I didn't gain any additional printf powers by looking into it, but I'm pleased to know (for one toolchain/architecture).
    It may also be a bad thing, because the assumption you make on one platform might not hold on another platform and you are unknowingly doing a bad thing™ by drawing on experience on how a specific platform works.
    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
    Registered User
    Join Date
    Jun 2005
    Posts
    6,679
    Quote Originally Posted by smokeyangel View Post
    In my experience, complicated template stuff is surprisingly easy to write and shockingly difficult for anyone else to read.
    I won't argue with that. It can also be quite difficult to get right.

    Quote Originally Posted by smokeyangel View Post
    Just because you can parameterise your code to hell and back doesn't mean you should!
    Yep. I tend not to parameterise things unless I have a number of specific use cases that are supported by doing so. In other words, when the need for parameterisation has been demonstrated by being useful more than once (and preferably much more than once).

    Quote Originally Posted by smokeyangel View Post
    I do prefer printf though. I don't see why I should be forbidden from using it, it's allowed in C++ isn't it? I know it's not typesafe, but I'll live. I like writing output as a string with format specifiers. The cout way of doing it is harder to visually relate to the output you'll see.
    It's just a way of thinking. There are quite a few people who find printf/scanf format strings counter-intuitive too.

    Yes, printf() is allowed in C++. Type safety, however, does help with eliminating quite a few common errors.

    char* and string.... I'm perfectly happy with char* -- I don't feel the need for a class. If I were to use string, I think I'd have to jump on the stream bandwagon as well, since that seems to provide the functionality you'd ususally use sprintf() for.

    Quote Originally Posted by smokeyangel View Post
    I've definitely seen char* and stdio used in C++ programs before. Is this a Bad Thing? Why?
    Two of the most common classes of error in C are pointer molestation and mismatched format specifiers. With C strings, one of the common classes of error involves misplacing the zero sentinel (terminator). Things have improved somewhat with modern compilers (eg diagnosing printf() calls at compile time), but these types of programming errors are a common cause of bugs. And of exploitable security holes.

    I would suggest mixing manipulation of C-strings with manipulation of C++-strings, and mixing stdio and stream I/O on the same stream, are often "bad things". Because they tend to introduce bugs that are hard to track down.

    Quote Originally Posted by smokeyangel View Post
    Quite right. I should have said that I knew how it worked on one specific compiler. Although I thought vtable structure was part of the generic C++ ABI?
    As a side effect, yeah. However, the name "generic C++ ABI" is misleading. It is a separate specification from any C++ standard, and therefore not required of all compilers.

    Quote Originally Posted by smokeyangel View Post
    So, I have a rough idea of some of the sorts of things supported in the libraries. If I needed to use some sort of resizable container I'd know that a number are available. I wouldn't be able to name the right one for the job without looking them up.
    There are quite a few corners of the C library that require access to a good reference as well. That is true of any large library.

    Quote Originally Posted by smokeyangel View Post
    Now - these days I work on code compiled for x86 (Linux and Windows) so I expect much of the mental model I have of C is invalid. That doesn't bother me though -- I have *a* mental model of how it works, which helps. Less so now, but when I was unfamiliar with C it helped a lot.
    Everyone has to have a mental model of something if they are going to use it reliably.

    The difference is that the preferred style of mental model to use C++, or its standard library, is a mapping from code construct to detectable effect. Whereas a common mental model encouraged for using C is a mapping of code constructs to lower level instructions.

    In practice, it is also possible to program in C with a mental model concerned with mapping code construct to detectable effect. In fact, quite a bit the C standard specifies things in that manner. However, it is much harder - as you have observed - to build a mental model for mapping a lot of C++ code constructs to lower level instructions. This is described using "higher level of abstraction" and terms like that. Higher levels of abstraction are powerful, as they can support large scale development (eg complex systems, or algorithms built up using more machine instructions and low level coding constructs than a mere mortal can wrap their mind around). The weakness of higher levels of abstraction is that it takes more effort to learn, and quite a few people have trouble grasping the concepts.


    Quote Originally Posted by smokeyangel View Post
    It's my natural instinct to try to break something down into its most basic form and figure it out from there. I think that's fairly common and I don't think it's wrong.
    I don't think it's wrong either. It is one way of approaching problems. Like any approach to problems, it has strengths and weaknesses, depending on how your mind works, your comfort zones, experience levels, the size of problems you're working on, and things like that.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Sunshine, and read this, this, and this before posting again.

Page 2 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Try again decision problem
    By hawkeye10 in forum C Programming
    Replies: 4
    Last Post: 02-03-2012, 03:08 AM
  2. The decision
    By Leeman_s in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 12-09-2003, 03:23 AM
  3. Tough decision - help!
    By da_fall_guy in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 03-31-2003, 10:10 AM
  4. Help - Decision in a do loop
    By dp174 in forum C Programming
    Replies: 3
    Last Post: 12-05-2002, 02:40 PM
  5. Help with some complex decision making
    By mlupo in forum C Programming
    Replies: 3
    Last Post: 11-17-2001, 01:45 PM

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