Thread: Do you ever feel you want OOP done with the C way of doing things?

  1. #16
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,875
    and he seems not to like OOP... I do need OOP.
    What makes you think that?


    No one has asked this, but what are you intending to program? What environment are you targetting? Did you have a design pattern in mind?
    Fact - Beethoven wrote his first symphony in C

  2. #17
    Registered User
    Join Date
    Apr 2020
    Posts
    14
    Quote Originally Posted by Click_here View Post
    What makes you think that?
    In the first page, he says he won't follow OOP mechanisms, but: "Instead, it is my intent to present implementations that utilizes the strengths of the abstraction mechanisms already included in the C language." (sic)

    Quote Originally Posted by Click_here View Post
    No one has asked this, but what are you intending to program? What environment are you targetting? Did you have a design pattern in mind?

    See below.

    Quote Originally Posted by laserlight View Post
    How would you implement generic arrays if you had to design a new OOP language with the "C mindset"?
    Generic-type arrays shouldn't need to be templates. They could be built-in types (generic type built-ins). Generic programming doesn't require the C++ templates mechanism. Arrays are so important when you write with a low level approach, that you'd consider them first-class citizens if you were developing an OOP language with a C mindset, rather than leaving arrays for later as an add-on, as a template written for the standard library.

    Quote Originally Posted by laserlight View Post
    Also, I note that generic programming with templates in C++ is another programming paradigm, not OOP. So if you're saying that generic programming in C++ differs significantly from both the "OOP mindset" and the "C mindset" in terms of programming paradigm, of course that is true, but it has nothing to do with "OOP done with the C way of doing things" because it is not OOP.
    Templates is one approach for Generic programming, but Generic programming != templates (or at least not in the way C++ implements templates).

    Quote Originally Posted by laserlight View Post
    Are you aware of move semantics in C++? To some extent it can address your concerns about such temporaries when chaining binary operators [...]
    Precisely. Now you are arriving to my point: Why something like moveable objects appeared 30 years after the language was introduced? This should be even more important than classes when you take a "C mindset" (ie: low-level control approach)... which by the way reminds me of another point that shows the mindset difference behind both languages: the realloc() difficulty. When C++ was designed, one of the very first things decided was that malloc() and realloc() were evil. Why? They claimed that it was because objects need constructors. But, in reality, that's not true, because malloc() and realloc() could be reimplemented with support to basic very fast constructors (in fact, you can consider calloc() to be just that, as it initializes data to zeros... the same you have calloc(), you could have another implementation that initialized data with initialization lists. The real reason for discarding malloc() and realloc() is that the C++ designers weren't thinking with a low-level mindset, and because of this, objects were non-moveable.

    And, to make things even farther from the C way of doing things, they made arrays second-class citizens, by proposing a template approach instead of built-in arrays.

    If you have ever looked at C++ source code written in the years from 1995 to 2005 or so, you'll know how different the mindset was from C development: inefficient constructors, inefficient operators, templates that generated cryptic compile errors, crazy amounts of temporaries in every operation (people didn't even know what temporaries were, because the C++ books at that time didn't talk about that too much, as they thought the C++ developer shouldn't care for that), etc, etc, etc.

    But, as I said at the beginning, this is not about C or C++ being better than each other. I'm not saying one is best, but that they have different priorities behind. And I also argue that the C priorities are compatible with OOP programming, and that C++ implemented OOP taking other priorities.

    I'd love to start a new cfront-like source to source translator implementing OOP in the way I expect it to be: pure OOP but with C-like low-level mindset from the very beginning and in everything. However, this would require from me a dedication I'd better invest in other projects I'm doing.

    So, taking a practical decision, as @Sir Galahad said in a previous post, I have no remedy but to continue using C++, because it implements the things I need, even if I'd prefer them to be done with another mindset.

    A mid-ground practical solution could be to just move to C++17, and learn all the new techniques for efficient coding with it.

    I selected the following books, but please tell me if there's any other good book (or document) related to efficient coding with modern C++:


    • The last edition of "A Tour of C++" by Stroustrup, for getting quick yet good explanation of later features of the language in C++17 and C++20.
    • "Effective Modern C++", by Meyers (as well as reviewing older Efficient C++ books by Meyers)
    • "Optimizing Software in C++" by Agner Fog.
    • "Efficient C++ Performance Programming Techniques" by Bulka and Mayhew.


    BTW, I'm going to open a new thread about arithmetic expressions optimization, but this will go in the C++ programming board, as it's a coding question.

  3. #18
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,794
    Quote Originally Posted by ccafe
    Generic-type arrays shouldn't need to be templates. They could be built-in types (generic type built-ins). Generic programming doesn't require the C++ templates mechanism. Arrays are so important when you write with a low level approach, that you'd consider them first-class citizens if you were developing an OOP language with a C mindset, rather than leaving arrays for later as an add-on, as a template written for the standard library.
    I don't see how is this peculiar to an "OOP language". Generic arrays don't necessarily have anything to do with OOP. By this same reasoning, C itself wasn't designed with a "C mindset", since it doesn't have such generic dynamic arrays as a built-in type other than the limited and now-optional variable length arrays.

    Having said that, when I say "OOP", I mean programming according to OO design, which typically means using some kind of inheritance (but not necessarily) mechanism to achieve some kind of (typically runtime, but not necessarily so) polymorphism among objects so as to achieve the open-closed principle, Liskov substitution, etc. I don't mean programming that merely organises code according to some notion of an "object" mainly as an abstraction with or without encapsulation and data hiding (though these form a basis for OOP).

    Quote Originally Posted by ccafe
    And, to make things even farther from the C way of doing things, they made arrays second-class citizens, by proposing a template approach instead of built-in arrays.
    Yet this provided a way to do low level control of the memory backing the dynamic array thanks to allocators, and while it did require compiler support for optimisation, doesn't require a high level penalty due to inlining. Granted, these could have been done with a built-in type too, but the low level aspect and efficiency is still there. Consequently, while I see your point because you are right that a most fundamental data structure arguably should receive native language support, it isn't clear to me that this is necessarily a sign of lacking a low level mindset in the design of C++.

    Quote Originally Posted by ccafe
    Templates is one approach for Generic programming, but Generic programming != templates (or at least not in the way C++ implements templates).
    Of course. My point is that generic programming is not OOP.

    Quote Originally Posted by ccafe
    The real reason for discarding malloc() and realloc() is that the C++ designers weren't thinking with a low-level mindset, and because of this, objects were non-moveable.
    I think you're stretching things a bit by taking advantage of the benefit of hindsight: malloc and realloc were not strictly discarded as they could still be used to back allocators. The reason for discarding their direct use wasn't just constructors, it was type safety, however poor C++'s type safety might be in hindsight. We now know (and as you implied have known for quite awhile) that C++ references aren't enough, but in 1979 it wouldn't have been so obvious. Consider also that the very first C++ standard included the precursor to move semantics, i.e., named return value optimisation.
    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

  4. #19
    Registered User
    Join Date
    Apr 2020
    Posts
    14
    Why can’t I see my last message but however @laserlight was able to quote it? Was my message deleted after @laserlight replied?

  5. #20
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    38,070
    > Was my message deleted after @laserlight replied?
    No, it was put into the moderation queue - presumably because you used @.
    Laserlight can see moderation pending posts anyway, but didn't actually approve your post.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #21
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    138
    Quote Originally Posted by Salem View Post
    > Was my message deleted after @laserlight replied?
    No, it was put into the moderation queue - presumably because you used @.
    Laserlight can see moderation pending posts anyway, but didn't actually approve your post.
    Hardly surprising, if you ask me...
    The power of null.

  7. #22
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,794
    I don't think the @ thing for tagging people even works, so it's more likely just a "special character" plus new membership triggering the moderation queue, and I just missed it when reading.
    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

  8. #23
    Registered User
    Join Date
    Apr 2020
    Posts
    14
    Quote Originally Posted by Sir Galahad View Post
    Hardly surprising, if you ask me...
    Indeed, it's not easy to find a forum where you can talk about points that would be nice to see improved in a language: if you talk about C++ in a (Python,Java,Go,Swift,etc) forum, users will reply how great (Python,Java,Go,Swift,etc) is compared to C++ and how the things you don't like will be instantly gone forever if you move to their beloved language. If you talk about C++ in a forum from a non-OOP language, users will reply that OOP is evil. If you talk about the weak points from C++ in a C++ forum, people will fight to defend the language, making it extremely difficult not to turn the conversation into a flamewar unless you stop participating.

    Perhaps a non-language-specific programming forum might be more successful, but doubtful because users will try to recommend languages as well...

    Anyway, don't worry, everything Ok, we speak different idioms. As I said, I program in C++, and there are no other alternatives I'd consider. I think nobody understood this, but, anyway, because my post was a question ("Do you ever feel you want OOP done with the C way of doing things?"), it's obvious it's possible to answer such question with a definite "not here"

  9. #24
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,794
    Quote Originally Posted by ccafe
    Indeed, it's not easy to find a forum where you can talk about points that would be nice to see improved in a language
    I did not approve your post because I didn't realise that it was in the moderation queue; usually the posts that require moderation approval are entirely new topics, not posts to an existing topic. It is as simple as that. I hope that you don't think that I didn't approve your post because I didn't agree with it: if I wanted to do that, why would I have replied and quoted the relevant parts of your post?

    Quote Originally Posted by ccafe
    if you talk about C++ in a (Python,Java,Go,Swift,etc) forum, users will reply how great (Python,Java,Go,Swift,etc) is compared to C++ and how the things you don't like will be instantly gone forever if you move to their beloved language. If you talk about C++ in a forum from a non-OOP language, users will reply that OOP is evil. If you talk about the weak points from C++ in a C++ forum, people will fight to defend the language, making it extremely difficult not to turn the conversation into a flamewar unless you stop participating.
    On one hand, I think it is only natural that programmers who are invested in a particular language or set of languages so much so that they participate in a relevant online forum would advocate for and defend these programming languages. On the other hand, programmers should also be open to the flaws in their programming languages of choice. Yet, just because they disagree with particular criticisms that you might propose doesn't mean that they are not open to the flaws in these programming languages.

    Quote Originally Posted by ccafe
    As I said, I program in C++, and there are no other alternatives I'd consider. I think nobody understood this
    What is there to understand about that though, other than it being good that you have a C++ background to inform your critique? Anyone who has used C++ long enough would -- or at least should -- also have some critique of C++ to make. That doesn't mean that other C++ programmers cannot disagree on those particular points of critique. It also doesn't mean that C++ programmers who disagree with you think that you don't program in C++ or that you hate C++ or something like that.

    Quote Originally Posted by ccafe
    because my post was a question ("Do you ever feel you want OOP done with the C way of doing things?"), it's obvious it's possible to answer such question with a definite "not here"
    As I have tried to explain, I don't think you're clear as to what you mean by "OOP done with the C way of doing things". You've somewhat elaborated that it involves some notion of "low level" and contrasted it with C++'s design, but I am not convinced that the (historical) efficiency issues with C++ that you've brought up is really a manifestation of that being inherently lacking, and even if it were, that doesn't really inform what's lacking in C++ today such that it lacks "the C way of doing things" while retaining the element of OOP, especially since some elements that you've mentioned concerning C++ don't necessarily involve the OO paradigm in the first place.
    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

  10. #25
    Registered User
    Join Date
    Apr 2020
    Posts
    14
    Quote Originally Posted by laserlight View Post
    [...] I hope that you don't think that I didn't approve your post because I didn't agree with it: if I wanted to do that, why would I have replied and quoted the relevant parts of your post?
    No idea. I suppose you are not asking me, because I'm not the one who said that "it's hardly surprising" that my post wasn't approved. What I said is "Why can’t I see my last message but however laserlight was able to quote it? Was my message deleted after laserlight replied?". The rest of hypotheses didn't come from me, I just said I didn't understand what was going on.

    Quote Originally Posted by laserlight View Post
    [...] As I have tried to explain, I don't think you're clear as to what you mean by "OOP done with the C way of doing things". You've somewhat elaborated that it involves some notion of "low level" and contrasted it with C++'s design, but I am not convinced that the (historical) efficiency issues with C++ that you've brought up is really a manifestation of that being inherently lacking, and even if it were, that doesn't really inform what's lacking in C++ today such that it lacks "the C way of doing things" while retaining the element of OOP, especially since some elements that you've mentioned concerning C++ don't necessarily involve the OO paradigm in the first place.
    As I said, you have already answered the question I wrote in the title even if you didn't realize, because by expressing that you don't consider the things I said as weak points in C++, you are expressing that you agree with the design criteria behind C++. So you answered the question, there's no alternative design criteria you miss in C++.

    Granted, I didn't write an accurate description of the design criteria I find missing, because it's not easy to write a global explanation that concisely defines the differences, but it's obvious that
    • (I) Stroustrup had different priorities to Kernighan and Ritchie in regards to what has higher priority and what's secondary, and
    • (II) that these different priorities have nothing to do with OOP, so
    • (III) C++ could have been designed with the same priorities that Kernighan and Ritchie had, while having a clean OOP concept and allowing generic programming.


    Now you could insist that you don't see any difference in the priorities by Stroustrup and KR, and by doing that, I insist you are answering my question.

    BTW, just as another add-on, like I wrote in this other thread, if C++ had been designed with the same priorities as C, arithmetic operators would be able to be defined specifying the mathematical properties for them, so that the compiler could optimize expressions taking custom types. There's no way for optimizing matrices expressions in C++, because of this (again, a symptom of different priorities).

    The same goes to considering that temporaries were of secondary importance, to be addressed in the future rather than from the beginning, or arrays (secondary priority, not caring for having efficient reallocatable arrays in the first C++ version, adding move/copy semantics 30 years after C++ was introduced), or lack of some kind of reflection (how can you take OOP to its full meaning if you cannot write automatic serialization for a class without using preprocessor macros for registering class members manually?).

    If you reply saying that the design is 100% correct in all these things, you are just answering my question, which can be much easier written like "no", rather than discussing topics we are not going to agree with, because our preferences are different.

    I want an "OOP assembly language", just like C was a "high level equivalent for assembly". You share Stroustrup's preferences, so we are not going to agree in this topic
    Last edited by ccafe; 04-20-2020 at 07:03 AM.

  11. #26
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,794
    Quote Originally Posted by ccafe
    No idea. I suppose you are not asking me
    I was asking you, because you replied to Sir Galahad's post in a way that might infer some attempt to be unfair, and I wanted to assure you that this is not so.

    Quote Originally Posted by ccafe
    As I said, you have already answered the question I wrote in the title even if you didn't realize, because by expressing that you don't consider the things I said as weak points in C++, you are expressing that you agree with the design criteria behind C++.
    Well yes, that is a compelling point, although it isn't a very useful one from my perspective where understanding your perspective is concerned.

    Quote Originally Posted by ccafe
    So you answered the question, there's no alternative design criteria you miss in C++.
    That is not true. Rather, among what you have outlined, with the exception of the lack of built-in reflection, there is no alternative design criteria that I miss in C++. I really do like the particular mix of multiparadigm programming that C++ provides, even as I dislike certain details.

    Quote Originally Posted by ccafe
    Stroustrup had different priorities to Kernighan and Ritchie in regards to what has higher priority and what's secondary
    This I can agree with, although I also note that having less than the highest priority don't mean that something is necessarily missing: it just means that there are other things to consider. Additionally, Kernighan did not design C, although he surely played a part in its early continued development.

    Quote Originally Posted by ccafe
    BTW, just as another add-on, like I wrote in this other thread, if C++ had been designed with the same priorities as C, arithmetic operators would be able to be defined specifying the mathematical properties for them, so that the compiler could optimize expressions taking custom types. There's no way for optimizing matrices expressions in C++, because of this (again, a symptom of different priorities).
    As I pointed out earlier: you're criticising with the benefit of hindsight, in a very specific area. Are you so sure that if dmr had designed C with operator overloading, he would have included this feature that you have in mind, given the state of compiler technology at the time? Having said that, I agree that this is a good example of priorities, e.g., you mentioned "define properties such as commutativity, associativity". The argument that this might help with compiler optimisation is sound, but it does indeed ignore other priorities like whether this would break the principle of least surprise, which I believe is why some newer languages decided to do away with operator overloading entirely (so no overloading + to mean square root, but also no Boost.Spirit).

    Quote Originally Posted by ccafe
    I want an "OOP assembly language", just like C was a "high level equivalent for assembly". You share Stroustrup's preferences, so we are not going to agree in this topic
    You wrote earlier: "I program in C++, and there are no other alternatives I'd consider", and perhaps because of that it may be tempting to believe that just because someone favours design choices for a particular programming language, they must be stuck in that programming language. I program in C++, but I also program in several other programming languages; just because I share Stroustrup's preferences with respect to C++ doesn't mean I cannot want an "OOP assembly language".
    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

  12. #27
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    138
    Quote Originally Posted by laserlight View Post
    I was asking you, because you replied to Sir Galahad's post in a way that might infer some attempt to be unfair, and I wanted to assure you that this is not so.
    And I apologize for implying such a thing, that was rather unfair of me.The internet just seems to have developed this cold-hearted culture over the past few years. I really gets to me! Anyway, I was probably just reacting from that sentiment. I'm sorry.
    The power of null.

  13. #28
    Registered User
    Join Date
    Mar 2020
    Posts
    12
    Dude templates are one of *the* good things in C++ that I wish were available in some at least limited capacity in C. I'd much rather use macro tricks to replicate templates than void*s and loose type safety (and for primitive types, performance).

  14. #29
    Registered User
    Join Date
    Apr 2020
    Posts
    14
    Quote Originally Posted by Sir Galahad View Post
    And I apologize for implying such a thing, that was rather unfair of me.The internet just seems to have developed this cold-hearted culture over the past few years. I really gets to me! Anyway, I was probably just reacting from that sentiment. I'm sorry.
    Thanks a lot, Sir Galahad, don't worry. I'm also sorry if I wrote harshly. As you mention, not falling into the cold-hearted trend is a virtue that needs to be cultivated, it doesn't come for free, and I forget it too often.

    Quote Originally Posted by cronus View Post
    Dude templates are one of *the* good things in C++ that I wish were available in some at least limited capacity in C. I'd much rather use macro tricks to replicate templates than void*s and loose type safety (and for primitive types, performance).
    Well, generic programming *is* a good thing. But I believe templates in C++ could be better. I must say here that the syntax doesn't help: choosing <> as the characters for enclosing the type brings a connection to the preprocessor in my subconscious ...and the way most C++ books explain templates reminds you of preprocessor stuff as well. And then the errors... most of the times, template-related errors look like hard to debug macro-related preprocessor errors. I mean, generic programming *is* a good thing (and I need it), but, again, I feel I don't share the same priorities as its implementation in C++

    Quote Originally Posted by laserlight View Post
    As I pointed out earlier: you're criticising with the benefit of hindsight, in a very specific area.
    That's the thing, I'm not criticising, I'm saying that whenever I've written C++ all these years, I felt it pushes me in a direction opposite to my preferences, so I found myself pushing back for compensating. That's not criticising, but I agree it can be understood as such if extra care is not put in the wording.

    Also, I'm not taking the benefit of hindsight: at the time C++ was standardized (in the 90s) I was writing (in C) real time graphics applications in UNIX workstations. So, when I had my first contact with C++, this push-away <> push-back fight I mentioned above was obvious from the beginning: I couldn't enjoy the priorities taken within C++, because treating temporaries or resizable arrays as second-class topics was really a problem, when they were some of my #1 priorities.

    This is not hindsight, but just a symptom that Stroustrup was not interested at all neither in triangles per second nor in interactive user interfaces where the user had to create and delete items in arrays all the time.

    And I realize this can be understood as if I'm criticising, but I'm not. Stroustrup comes from a theoretical field, and it's natural he would consider of little importance things that are #1 issues when your field is not theoretical. Moreover, it's natural this can be felt like of even less importance today, given that the speed of processors can make a lot of people believe that these things are not that important. But efficiency is not about speed, but about doing things clean and optimal. Speed is just a consequence.

    Quote Originally Posted by laserlight View Post
    Are you so sure that if dmr had designed C with operator overloading, he would have included this feature that you have in mind, given the state of compiler technology at the time?
    It's not about what he would have done. That, we don't know. I'm not saying somebody was wrong or right, but that the things I dislike from C++ wouldn't be there if C++ was created with the same philosophy as C (an "OOP assembly language" just like C was thought as a "high level assembly language").

    Even if the first C++ release missed reflection or customizable mathematical properties for operators, if it had been designed with the same priorities as C, I would feel with it like at home.

    And, BTW, I'm feeling now like if it could be suspected that I consider C perfect. No I don't. I consider its philosophy has the same priorities as my programming preferences. But there are quite a few things that I consider weaknesses, like for example treating enums just like if they were macro definitions, and to make things worse they are non-scooped. It does have weak points, but its priorities match mine at coding. Then C++ is the best OOP language I know of, but with priorities different to mine.
    Last edited by ccafe; 04-21-2020 at 03:04 AM.

  15. #30
    Registered User Sir Galahad's Avatar
    Join Date
    Nov 2016
    Location
    The Round Table
    Posts
    138
    Quote Originally Posted by ccafe View Post
    Thanks a lot, Sir Galahad, don't worry. I'm also sorry if I wrote harshly. As you mention, not falling into the cold-hearted trend is a virtue that needs to be cultivated, it doesn't come for free, and I forget it too often.
    Well exactly. We are all brothers and sisters on this Earth. Lacking kindness only serves to suck all of the good out of a person, not to mention the effect it has on others.

    Quote Originally Posted by ccafe View Post
    Well, generic programming *is* a good thing. But I believe templates in C++ could be better. I must say here that the syntax doesn't help: choosing <> as the characters for enclosing the type brings a connection to the preprocessor in my subconscious ...and the way most C++ books explain templates reminds you of preprocessor stuff as well. And then the errors... most of the times, template-related errors look like hard to debug macro-related preprocessor errors. I mean, generic programming *is* a good thing (and I need it), but, again, I feel I don't share the same priorities as its implementation in C++
    It's weird that they chose <> over say []. The latter would have been much less ambiguous to parse IMO.

    Quote Originally Posted by ccafe View Post
    And I realize this can be understood as if I'm criticising, but I'm not. Stroustrup comes from a theoretical field, and it's natural he would consider of little importance things that are #1 issues when your field is not theoretical. Moreover, it's natural this can be felt like of even less importance today, given that the speed of processors can make a lot of people believe that these things are not that important. But efficiency is not about speed, but about doing things clean and optimal. Speed is just a consequence.

    It's not about what he would have done. That, we don't know. I'm not saying somebody was wrong or right, but that the things I dislike from C++ wouldn't be there if C++ was created with the same philosophy as C (an "OOP assembly language" just like C was thought as a "high level assembly language").
    Stroustrup was also quite ahead of his time though. C++ may not be a "perfect" language, but what you can do with it is still absolutely magical.

    But I do agree, something better would be great. Care to volunteer?
    The power of null.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. how do you feel...
    By ILoveVectors in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 08-16-2005, 05:47 AM
  2. I feel.....clean....
    By jdinger in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 04-11-2003, 06:46 PM
  3. win xp look&feel
    By aym_7 in forum Windows Programming
    Replies: 9
    Last Post: 05-11-2002, 08:28 PM
  4. I feel sorry for...
    By Betazep in forum A Brief History of Cprogramming.com
    Replies: 43
    Last Post: 11-25-2001, 03:50 AM
  5. I feel sorry for
    By Betazep in forum A Brief History of Cprogramming.com
    Replies: 10
    Last Post: 10-28-2001, 11:23 PM

Tags for this Thread