-8

I want to know that whether storage is an issue with respect to current hardware and software market when we talk about the large size of C++ programs?? Because in certain conditions we have to choose between some types of programming etc like between OOP and procedural programming. I know that object oriented programs are of larger size than procedural programs. But does storage is even an serious issue while choosing the best method to solve our problem?

16
  • 3
    "I know that object oriented programs are of larger size than procedural programs." - Why do you think that? – Sebastian Redl Jan 25 '18 at 16:28
  • 1
    Sorry, I have trouble with the notion that C++ programs are bigger. They are not. You must consider all that is involved in installing some other kind of system. C++ is as close as you can get to the metal. Storage hasn’t been an issue for normal compute systems for a while. Embedded is always a special case. – Bill Door Jan 25 '18 at 18:21
  • 1
    Can you build a 4K "binary" in another language? You have to count all the parts. Java, JVM is MB, Node is 22M, Python 25k (plus lots of libraries to do more). (Debating in comments, not that great of an idea.) – Bill Door Jan 25 '18 at 18:40
  • 1
    I don't know if Embedded C++ is still an active concern. en.wikipedia.org/wiki/Embedded_C%2B%2B. Guess not. "the official English EC++ website has not been updated since 2002. " – Bill Door Jan 25 '18 at 22:41
  • 2
    @TeamUpvote I/O streams are just bad. Deep inheritance hierarchies don't actually cost space (unless you have virtual inheritance or virtual functions), but they're also pointless if your program is so small that it fits into 4k. (Also, they are generally bad from a modern OOP viewpoint.) In general, equivalent functionality in procedural isn't smaller than OOP, but interfaces (or more generally virtual functions) provide flexibility, something tiny programs have no need of. If you do the same flexibility in C you end up with binaries just as big, you just wrote more code to do it. – Sebastian Redl Jan 25 '18 at 23:05
-1

Ok, I will give you my uninformed opinion. I have edited this to be more specific based on the comments of the original post and of the comments that I received below.

As for the choice of language, storage tends not to be an issue with current systems.

One of the nice features of C is that it has the smallest runtime library. So if you compile "Hello World" in either K&R C or ANISI C (I think I was using either "Power C", or "Turbo C" compiler under DOS), it would build an executable that was approximately 4K. This fits nicely under the storage limits at the time (C++ was being developed, but was not widely available).

When C++ came out (I started playing with it about 1993), the "Hello World" exe would go to 20M due to the runtime library being much that much larger. Switch back to C, and you would get a 4K exe. So yes, C++ is larger, however, with current servers, desktops and even smart phones having gigabytes of memory - the compiled size of the executable is not as important.

My original assertion "With current systems, storage is not an issue." was too ambiguous.

When you are dealing with an 8085 and 2 k of memory with no external memory, then storage is a hugh issue and you probably will choose assembly over any other language. Hugh issue in 1975, I would guess it is not a current issue in embedded systems given the options for memory that currently exist (disclaimer, I don't work with embedded systems).

Based on what I learned in college and from job interviews (about 1990), embedded processors didn't have a large amount of memory and you really didn't have the option to get more. You may have the choice of C or assembly, but you certainly didn't have the 4M available for C++.

That said, now you have have options. Granted it is $0.5 dollars more per chip (see the informed opinion below), and if you are in the business of shaving a fraction of cent off of your consumer products, and then it may be an design issue.

5
  • 2
    Memory still is an issue in embedded devices - a typical 1$ MCU has 64k ROM and 20k RAM. With the next size (128k) being 0.5$ more expensive. And the total cost of parts around 10$ - it's an issue. Also many embedded Linux systems still work with raw NAND flash, meaning something on the order of 256 or 512MB base storage for the system. That's when your base distro has to be around 30 megs and you can't add MySQL without somehow expanding memory. And 2k ROM MCUs are still pretty much alive (alylthough fading). – Jan Dorniak Jan 25 '18 at 17:47
  • If you don't think that data storage is an issue today, then that's because you aren't dealing with programs that have to deal with a lot of data. The only reason computers today have more storage than the computers of the 1980s is because the market demanded it: Data got bigger, programs got bigger, and new computers have always been just big enough to keep up with the demand. If, on the other hand, you are only talking about code size, then that is less of an issue today. It's less of an issue because data gets bigger faster than the code that pushes it around. – Solomon Slow Jan 25 '18 at 20:44
  • @Jan Dorniak: It has been a while since I looked at the embedded market. I agree that a blanket statement that it is not an issue is too broad, however, would you agree that now you have options as compared with the 1970's 1980's, they may cost more, but they are there. – Robert Baron Jan 26 '18 at 12:05
  • @James Large: There is also technical reason, transistors became smaller, and you could fit more on a single die. My interpretation of the original question was the language choice being based on the storage requirements, ie, the executable size. It has alway been the case that you will want to collect more data than you have memory to do so. – Robert Baron Jan 26 '18 at 12:10
  • @RobertBaron they ARE there, and an example of that could be the i.MX RT - it's a powerful MCU with lots of RAM and not much in terms ROM - it's intended to be used with external permanent storage. – Jan Dorniak Jan 26 '18 at 12:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.