Announcement

Collapse
No announcement yet.

Google Wants To Make C++ More Fun

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by curaga View Post
    How the heck do can you fit anything C++ to the common MSP430? The models we used had 512 bytes of RAM and 16kb of flash, and we had trouble even fitting simple C programs in there.

    Even the highest models seem to have at max 16kb RAM and about a meg of flash. That's certainly enough to fit some subset of C++ stl in the flash, but not enough RAM to do anything C++-y.
    Funny story from my industry experience: a company I worked for developing smartphones in the mid-2000s (our typical reference device had 64 MB of RAM with 128 MB on the near horizon) had a guy within the company who insisted on using C++ more in our code. Our platform was designed around using C and he thought that C++ would improve development speed without hindering performance. Well after a few long years of fighting for C++ he eventually got fired. I think he pushed a little too hard for it and management didn't want him trying to change the company's direction.

    Besides, he created a prototype build and flashed it on a device with our base libraries re-implemented in C++, and the performance was about 20% worse. Hardly a compelling argument for C++. And these libraries were designed by a guy with like 15 years of industry experience with C++ working for tons of prestigious tech companies.

    That's not to say that C++ is "slow", but it's certainly a bit slower than C, so if we could notice a performance difference on a device with 64 MB of RAM, I can't imagine how you could use it on a device with 16 KB of RAM. Even back in 2007-2008 our SoCs were probably several orders of magnitude more capable than a MSP430, being designed for flagship smartphones and all.

    Comment


    • #32
      few other things about the type() declaration solution

      -The default should be respected.
      If the platform cannot full fill the defaults.
      The programmer should not be able to use the default type().

      -The implementation details about a type should not be about internal representation.
      Should not be able to change that.
      We work in a higher language for a reason.



      -Different meaning, behaviour is a reason for making a new type.


      -Working with versions allows me to let both old and new programs work with new infrastructure.
      (making new programs work on old things will always be a problem)
      This making it possible to get stuff working and make it keep working.

      - maybe it's a good idea to have the default number of bits very low?
      Like 16 bits for int().
      please feedback me about this: negative feedback is okay but it has to give a reason for why it is bad: a consequence that would happen.
      Last edited by plonoma; 06-17-2012, 10:35 AM.

      Comment


      • #33
        Memory management with C still reigns supreme over C++ in terms of performance. Always will I think. A project I'm working with has people treating structs + function pointers + hideously_ugly_glue_code as "objects". I want permission to remake a prototype in C++ to see if I can make the code a bit cleaner, but the only features that would help are classes and maybe virtual functions. Not sure what the compiler would produce in the end, but it helps that everything's statically allocated.
        Of course, in my case there isn't a whole lot of difference between using C and C++. Once you go to the requirements of larger firmware....well that's still C and some custom assembly routines.

        Comment


        • #34
          Originally posted by plonoma View Post
          few other things about the type() declaration solution

          -The default should be respected.
          If the platform cannot full fill the defaults.
          The programmer should not be able to use the default type().

          -The implementation details about a type should not be about internal representation.
          Should not be able to change that.
          We work in a higher language for a reason.



          -Different meaning, behaviour is a reason for making a new type.


          -Working with versions allows me to let both old and new programs work with new infrastructure.
          (making new programs work on old things will always be a problem)
          This making it possible to get stuff working and make it keep working.
          I'm not sure I follow you, what you describe appears to be possible in current C++.

          Code:
          myint<32> a = 3; //32 bits, specialized class template
          myint a = 3; //default, N bits
          And this is pretty much run-of-the-mill C++, nothing special about it.

          Comment


          • #35
            Originally posted by mirv View Post
            Memory management with C still reigns supreme over C++ in terms of performance. Always will I think. A project I'm working with has people treating structs + function pointers + hideously_ugly_glue_code as "objects". I want permission to remake a prototype in C++ to see if I can make the code a bit cleaner, but the only features that would help are classes and maybe virtual functions. Not sure what the compiler would produce in the end, but it helps that everything's statically allocated.
            Of course, in my case there isn't a whole lot of difference between using C and C++. Once you go to the requirements of larger firmware....well that's still C and some custom assembly routines.
            I'd be hard pressed to take this as a fact. What exactly is worse in terms of performance in C++ dynamic allocation compared to C?

            Comment


            • #36
              Originally posted by Pseus View Post
              I'd be hard pressed to take this as a fact. What exactly is worse in terms of performance in C++ dynamic allocation compared to C?
              Normally, there's not much difference. But if you don't need constructors/destructors, and/or can benefit from realloc, for example, C will win. Not by much, but enough to be worth it sometimes.

              Comment


              • #37
                Originally posted by mirv View Post
                Normally, there's not much difference. But if you don't need constructors/destructors, and/or can benefit from realloc, for example, C will win. Not by much, but enough to be worth it sometimes.
                I still don't see your point. If you need to initialize data, you will need to do that in C as well (by initializing your data after malloc). If you don't need to initialize your data, you just leave the constructor/destructor out (and avoid using data types that use them).

                There's nothing preventing you from using realloc, either. If you need that, you design your class accordingly, and call realloc when needed (you overload new/delete to call malloc and free, or you can use malloc and placement new, for instance).

                Comment


                • #38
                  Originally posted by allquixotic View Post
                  Funny story from my industry experience: a company I worked for developing smartphones in the mid-2000s (our typical reference device had 64 MB of RAM with 128 MB on the near horizon) had a guy within the company who insisted on using C++ more in our code. Our platform was designed around using C and he thought that C++ would improve development speed without hindering performance. Well after a few long years of fighting for C++ he eventually got fired. I think he pushed a little too hard for it and management didn't want him trying to change the company's direction.

                  Besides, he created a prototype build and flashed it on a device with our base libraries re-implemented in C++, and the performance was about 20% worse. Hardly a compelling argument for C++. And these libraries were designed by a guy with like 15 years of industry experience with C++ working for tons of prestigious tech companies.

                  That's not to say that C++ is "slow", but it's certainly a bit slower than C, so if we could notice a performance difference on a device with 64 MB of RAM, I can't imagine how you could use it on a device with 16 KB of RAM. Even back in 2007-2008 our SoCs were probably several orders of magnitude more capable than a MSP430, being designed for flagship smartphones and all.
                  There's nothing inherent in C++ that makes it slower than C. If your primary goal is performance (even above readability or safety) and your C++ code is slower than your C code, you're probably doing something wrong. What you describe appears to be exactly what Linus said he wants to avoid by keeping C++ developers away: dumb developers that misuse the language (the C++ guy in your example). In this regard, C is usually better than C++.

                  Edit: everything said, I do consider C a better language for memory constrained platforms (16KB of RAM). If you do use C++, you'll probably end up using a subset that pretty much looks like C, and you will need to keep and eye on all developers to avoid using heavyweight features. Not to mention that it is hard to find good C++ compilers.
                  Last edited by Pseus; 06-17-2012, 07:57 PM. Reason: clarification

                  Comment


                  • #39
                    Originally posted by Pseus View Post
                    There's nothing inherent in C++ that makes it slower than C. If your primary goal is performance (even above readability or safety) and your C++ code is slower than your C code, you're probably doing something wrong. What you describe appears to be exactly what Linus said he wants to avoid by keeping C++ developers away: dumb developers that misuse the language (the C++ guy in your example). In this regard, C is usually better than C++.

                    Edit: everything said, I do consider C a better language for memory constrained platforms (16KB of RAM). If you do use C++, you'll probably end up using a subset that pretty much looks like C, and you will need to keep and eye on all developers to avoid using heavyweight features. Not to mention that it is hard to find good C++ compilers.
                    I was trying to differentiate between "full C++" and "the C subset of C++" actually. C++ without the "fancy features" is basically C anyway.

                    Comment


                    • #40
                      If you are on Windows, you have Visual Studio.

                      All I really hear from the guy in the video is that how he likes to do stuff is how stuff should be done.

                      Me, I like Notepad and kedit and vi, they don't try to impose policy on me.

                      Comment


                      • #41
                        Originally posted by hoohoo View Post
                        If you are on Windows, you have Visual Studio.

                        All I really hear from the guy in the video is that how he likes to do stuff is how stuff should be done.

                        Me, I like Notepad and kedit and vi, they don't try to impose policy on me.
                        I use vim for C++, but I make use of stuff like vim-clang-complete (and cscope, which works okay but isn't perfect). I don't see any problem with having good tools available on Linux, especially those that can integrate with someone's editor of choice.

                        Good autocompletion which gives you quick access to function prototypes, documentation, etc. is great and so are features like jumping to function definitions and context-aware refactoring (instead of just using search-and-replace as a hammer all the time).
                        Last edited by strcat; 06-18-2012, 03:22 PM.

                        Comment


                        • #42
                          Originally posted by hoohoo View Post
                          If you are on Windows, you have Visual Studio.

                          All I really hear from the guy in the video is that how he likes to do stuff is how stuff should be done.

                          Me, I like Notepad and kedit and vi, they don't try to impose policy on me.
                          Notepad is shit, it doesn't even include line numbering or syntax highlighting.

                          Visual Studio is absolutely awesome (well, some bugs). Together with Resharper, it is amazing.
                          You can code folding, auto-completion, class browser, built-in documentation, refactoring, automatic indention, debugging, code suggestions, it points out issues and helps you fix them, etc.
                          It's invaluable!

                          A simple text editor can work on small projects. But when you do large enterprise projects and object-oriented programming its good to have a IDE.

                          Comment


                          • #43
                            Originally posted by mirv View Post
                            Care to show me an example of higher level languages for weaker MCUs "for decades"? Because those things are still mostly done in C, or assembly. If you worked with those devices, you'd know that. I do know of one group that made a python interpreter for an MSP430 chip, but it was incredibly slow and definitely not for battery operation.
                            Microsoft was formed by writing a BASIC interpreter for the Altair 8800 in 1975-1976.

                            TI-BASIC runs on TI calculators with a Z80 CPU (designed in 1976).

                            Just two examples.

                            I'll also say again: C++ is dependent upon the underlying machine architecture, and if you want to include the runtimes, then the operating system too. It's much closer to the metal than many other languages, by design, and that you're trying to compare it to languages that aren't, reflects on the well thought out design and foresight given to C++.
                            This doesn't even make sense. Convoluted logical acrobatism.

                            GLuint may be defined as 32bit now, but it doesn't mean it has to be. What about 64bit?
                            GLuint64, duh.

                            Granted, I've not gone completely over the spec to see if GLuint is always meant to be a 32bit number (it may well be) - but then, what about OpenGL on environments without stdint? You'd have to either typedef yourself (bad for OpenGL portability), or shock horror, use a library typedef.
                            Table 2.2, page 16 of the 4.2 core specification.

                            Those library typedefs wouldn't - shouldn't - be necessary in any sane language with a properly defined type system. They are a kludge for the deficiencies in C/C++ legacy.

                            If no assumptions were made about GLuint, converting it between 32bit and 16bit wouldn't break code, btw.
                            Oh really? You are either trolling or you just lack experience in OpenGL. The ways your code would break when interfacing with the gfx hardware are too many to enumerate - which is why GLuint is defined as 32bit in the first place.

                            Comment


                            • #44
                              Originally posted by Pseus View Post
                              I'm not sure I follow you, what you describe appears to be possible in current C++.

                              Code:
                              myint<32> a = 3; //32 bits, specialized class template
                              myint a = 3; //default, N bits
                              And this is pretty much run-of-the-mill C++, nothing special about it.
                              Somebody who says something, good.

                              You're working with templates. Very different way of working than with value types like int, char.
                              It's not that it looks the same way that it works the same way.
                              I'm trying to have something more specific but still have some freedom, options to work with.
                              While avoiding names explosions and typedef explosions / proliferation.
                              (templates are more generalized than what I'm proposing)
                              They won't work with each other.
                              You won't get the behaviour out of it that I'm trying to create.
                              Read about how templates work and the negative points about templates.

                              I'm trying to find a good system for simple value types.

                              By default, C/C++ does not have a fixed size (number of bits) for things like int.
                              One compiler might have a fixed size but this is no way a guarantee that all compilers or even different versions of the same compiler have the same fixed size.
                              Different sizes causes programs to behave differently! (overflow)
                              Big problem for programming in higher languages (general property)!

                              I'm trying to make things simpler by not using templates.
                              But introducing types with declaration options.

                              Allowing me to use the same name with different options.
                              Allowing library writers to be adaptable with types without having to invent new types like the current situation.
                              This system is expandable with new types and things if the need arises.
                              And because of it's novel construction (use of rounded parentheses () ) allows for defaults fully specified without interfering with backwards compatibility with existing code.
                              int <- old system
                              int() <- new system with clearly defined defaults

                              I'm also not only targetting number of bits here.
                              You have seen how this could be used for strings.
                              For strings this could make integrating new encodings and options much simpler, less adaptions needed to current code.
                              There won't be an explosion of names like now is the case.
                              Somebody with a new encoding now immediately has a way to use this new encoding in code.
                              Without introducing new types (or using templates).

                              One of the advantages is also that it does not interfere with current code.
                              If this would get added to the standard and compilers. All current code would still compile since it's an addition.

                              If a project would want to use this, they could just start using this for new code.
                              Without having to re factor old code to make things that already work, work.
                              Using it comes with zero penalty.

                              Unlike the recycling of the auto keyword. They should have used autotype as word.

                              It's also a clean slate for defaults!
                              Can have things like standard UTF-8 encoding for strings when not specified explicitly from the beginning!

                              Libraries and api's can specify what options they use, are used.
                              Last edited by plonoma; 06-19-2012, 12:39 PM.

                              Comment


                              • #45
                                Originally posted by BlackStar View Post
                                Microsoft was formed by writing a BASIC interpreter for the Altair 8800 in 1975-1976.

                                TI-BASIC runs on TI calculators with a Z80 CPU (designed in 1976).

                                Just two examples.



                                This doesn't even make sense. Convoluted logical acrobatism.



                                GLuint64, duh.



                                Table 2.2, page 16 of the 4.2 core specification.

                                Those library typedefs wouldn't - shouldn't - be necessary in any sane language with a properly defined type system. They are a kludge for the deficiencies in C/C++ legacy.



                                Oh really? You are either trolling or you just lack experience in OpenGL. The ways your code would break when interfacing with the gfx hardware are too many to enumerate - which is why GLuint is defined as 32bit in the first place.
                                I had a longer reply, but dodgy net connection here lost it.
                                Short: you're saying Basic is higher level than C/C++? Go try using it. Also, do please look up what, exactly, an MSP430 series chip is before you try to compare it to a TI-8x graphing calculator.
                                Go try keep portable code across different architectures using only uint8_t, uint32_t, etc. Sometimes, using plain old "unsigned int" is actually easier.

                                Comment

                                Working...
                                X