- Can 'this' be assigned a pointer to it? - 1 Update
- "Linus Torvalds Was (Sorta) Wrong About C++" - 21 Updates
- "Linus Torvalds Was (Sorta) Wrong About C++" - 3 Updates
| Martijn Lievaart <m@rtij.nl.invlalid>: Mar 12 03:15PM +0100 On Wed, 11 Mar 2015 16:48:51 +0000, Greg Martin wrote: > The tutorial was suggesting the user should debug the program so it > would make sense there should be an error for the reader to fix. Fair enough, might have the subgoal of reiterating that this is const. M4 |
| "Öö Tiib" <ootiib@hot.ee>: Mar 11 04:44PM -0700 On Wednesday, 11 March 2015 23:31:32 UTC+2, JiiPee wrote: > variable (defined in a same place where "a" is defined). Why 8? size is > 4 bytes.... > you mean the function needs another size variable as an argument? 'std::vector' is typically implemented as 3 pointers: pointer of start of reserved memory pointer one after reserved memory pointer one after used/initialized memory We usually need all that information in C as well if the array is going to be allocated dynamically and its contents and size will be changed dynamically. Having only two is inefficiently non-lazy and will fragment the dynamic memory too quickly. However if that is not really what you need then you are no way enforced to use 'std::vector<int>'. You do not need to use 'int*' in C++ anyway. If you know there are always 10 elements then you can use 'std::array<int,10>' instead. If you know the size isn't known compile time but won't change dynamically and you care about the 8 bytes then you can use std::unique_ptr<int[]> instead. |
| woodbrian77@gmail.com: Mar 11 05:16PM -0700 On Wednesday, March 11, 2015 at 1:12:16 PM UTC-5, Johannes Bauer wrote: Please don't swear here. Brian |
| BGB <cr88192@hotmail.com>: Mar 11 08:34PM -0500 On 3/11/2015 4:41 PM, JiiPee wrote: >> everything else.. >> /Flibble > but the issue here is using as little RAM memory as possible yeah. for example, if writing code for microcontrollers, these don't really have an abundance of RAM. a higher-end microcontroller may have double-digit kB of RAM, but many have only single-digit kB, and some don't even have kB (you get maybe 256 or 512 bytes of RAM and maybe a few kB of ROM). granted, ARM SoCs tend to be a lot more powerful, but there are few good options if one wants something fairly cheap and available in DIP packages (vs QFP or BGA or similar). or such... |
| Ian Collins <ian-news@hotmail.com>: Mar 12 05:05PM +1300 > On Wednesday, March 11, 2015 at 1:12:16 PM UTC-5, Johannes Bauer wrote: > Please don't swear here. He didn't.... -- Ian Collins |
| Ian Collins <ian-news@hotmail.com>: Mar 12 05:08PM +1300 JiiPee wrote: > std:: cout << sizeof(b) << std::endl; > prints 4 > So an empty vector seems to take 12 bytes, and empty C-array 4 bytes I should have said flexible array not dynamic array. -- Ian Collins |
| Paavo Helde <myfirstname@osa.pri.ee>: Mar 12 01:27AM -0500 JiiPee <no@notvalid.com> wrote in > int size = 10; > X* x = new X[size]; > With 8 bytes overhead. And losing all the other goodies. This should be at least wrapped in a proper RAII class whose destructor calls delete[]. Thankfully, my last experience with a computer where saving 4 bytes was important was with Elektronika MK-61, 30 years ago. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Mar 12 07:22AM On Wed, 2015-03-11, Wouter van Ooijen wrote: > (For the record: C++ is may favourite language, crappy or not, for > resource-constrained work. For other work I tend to use Python (which > has its own unqiue share of crappyness.) For Python's big standard library: yes. For rapid prototyping or small, quick tasks: yes. Otherwise, nowadays I think C++ is a better choice for more tasks than you'd think. It's not just about resounce usage: it's about things like static type checking and (for me) more attention to proper error handling. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 12 09:26AM +0100 On 11.03.2015 19:37, Wouter van Ooijen wrote: >> understand why. > That's like saying that paper is generally used for wiping your ****, so > something written on paper must be shitty. No, it's like saying: Paper is generally used to wipe your ass so we'll write on slate in order to prevent idiots from coming along and wiping their feces all over our code. > I sort of agree that C++ is a crappy language, but as that is mostly due > to its C legacy, I am not gona take such insults from a C lover! That is definitely false, too. The parts that suck about C++ when people misuse it are exclusively "new" features. Template metaprogramming (oh the horrors), deeply nested weird inheritance hierarchies and use of the STL which is unsuited for LOTS of tasks (space constrained, like embedded for example). > (For the record: C++ is may favourite language, crappy or not, for > resource-constrained work. For other work I tend to use Python (which > has its own unqiue share of crappyness.) I like some features about C++ as well. Strongly typed enums are amazing. Static assertions are great. Polymorphic functions can be very useful, too. And I actually use it also in embedded environments, but for exactly those features. As a "C with benefits", not as C++. You won't see any inheritance at all in my embedded C++ code (you will see interfaces, though). My hope is that at least strongly typed enums ("class enums") will go into C at some point, that would be super cool. I think C11 already as static assertions, so that's definitely a plus. Cheers, Johannnes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 09:37AM +0100 Johannes Bauer schreef op 12-Mar-15 om 9:26 AM: > the horrors), deeply nested weird inheritance hierarchies and use of the > STL which is unsuited for LOTS of tasks (space constrained, like > embedded for example). I can only state *my* opinion. The things I hate in C++ are nearly all inherited from C (like the weird type conversion rules, the wrong-way-round way of declaring types, and the overall feel of a language optimized for a 110 baud teletype. I grew up with Pascal and loved Ada, I guess it shows). Template programming is one of the things in C++ I like most, and IMO it is one of the most powerfull tools in writing re-useable code for very resource constrained systems. I agree that large parts of the C++ libraries (and even some parts of the language) are unsuited to programming very small systems. But even with those features discarded I still like C++ better for such work than anything else. > those features. As a "C with benefits", not as C++. You won't see any > inheritance at all in my embedded C++ code (you will see interfaces, > though). I am experimenting with (virtual!) inhertitance in combination with the de-virtualization available in recent gcc and I am positively amazed by the results. In the appropriate situations (where direct calls would be using in C) the compiler eliminates all VFT's and can even be persuated to inline the calls. Wouter van Ooijen |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 09:41AM +0100 Jorgen Grahn schreef op 12-Mar-15 om 8:22 AM: > choice for more tasks than you'd think. It's not just about resounce > usage: it's about things like static type checking and (for me) more > attention to proper error handling. I agree that Pythons duck-typing is a real PITA. But there are benefits: I like indent-equals-structure, and in my experinece it is much esasier to grab a library and do something simple with it in Python than in C++ (like I recently did: generate a my invoices in rtf, or grab the pictures from all pages liked from a certain webpage). And I can distribute the source and the customer can just run it with the appropriate Python implementation on his platform. But I'd never consider wrting let's say a compiler in Python. Wouter van Ooijen |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 12 10:05AM +0100 On 12.03.2015 09:37, Wouter van Ooijen wrote: > Template programming is one of the things in C++ I like most, and IMO it > is one of the most powerfull tools in writing re-useable code for very > resource constrained systems. Ooooh I think template programming is dreadful. Not because of the results, the results are really amazing. But because of the debugging and readability issues. Oh and the horrors of compiler errors with templates. It's dreadful. And, since you said you think duck-typing is annoying in Python, you get similar results in C++ templating code: You can introduce type errors that aren't ever reported until someone changes something about the code that uses templating when all the sudden everything just blows up. It is annoying. And for resource constrained systems, templates are the aboulte worst because they introduce a TON of code duplication. I'm not sure what systems you're referring to, but I'm wokring on Cortex-M microcontrollers. So let's say a Cortex-M0 with 64k flash. I dare to to use one, only a single one of those templated STL library functions and your ROM will be full already. > the language) are unsuited to programming very small systems. But even > with those features discarded I still like C++ better for such work than > anything else. I just tested it, have a project here that does a ton of work on a Cortex-M3, compiled in C. 62k of code, with many parts of the C standard library in there (printf and friends). Now I added one single file: #include <string> #include <iostream> void foo(const std::string &moo) { std::cout << moo; } And linked the whole thing again with g++. First observation: New syscalls are drawn in. kill, getpid and open. What? kill and getpid, seriously? What is going on? In any case, after implementing stubs for those, it links: 293 kB of binary! That is almost a FIVE FOLD increrase in code side fo doing pretty much nothing. I must admit that I expected horrible results, but the sheer amount of useless code that is pulled in actually did shock me. And I double checked to see if my measurement was correct, and it was. The code is full of monstrosities like 800f324: d809 bhi.n 800f33a <std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > std::num_get<wchar_t, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> > >::_M_extract_int<unsigned int>(std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const+0x1be> And I guess if for every variation of every parameter those compiled template binaries are duplicated, then, yes, you get a fivefold increase in code size. > the results. In the appropriate situations (where direct calls would be > using in C) the compiler eliminates all VFT's and can even be persuated > to inline the calls. Sounds very interesting. Do you have any pointers, I wasn't aware of that feature. It sounds like something like that could be very useful for very small systems indeed. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Johannes Bauer <dfnsonfsduifb@gmx.de>: Mar 12 10:23AM +0100 On 12.03.2015 10:18, Stefan Ram wrote: >> And for resource constrained systems, templates are the aboulte worst > Templates fit small-memory systems well when the > programmer is knowing what he is doing. But this is exactly the criticism about C++ in the original article: You absolutely *have* to know the implications of what you're doing in detail or you can introduce a vast array of problems by a single line or reference (like std::string). It's not transparent by any means what is efficient (and can maybe even resolved at compile-time) and what will introduce tons of overhead. By contrast in a language as simple as C it is simply not possible to intruduce such overhead by seemingly subtle changes in code. Cheers, Johannes -- >> Wo hattest Du das Beben nochmal GENAU vorhergesagt? > Zumindest nicht öffentlich! Ah, der neueste und bis heute genialste Streich unsere großen Kosmologen: Die Geheim-Vorhersage. - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org> |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 10:33AM +0100 Johannes Bauer schreef op 12-Mar-15 om 10:23 AM: > resolved at compile-time) and what will introduce tons of overhead. By > contrast in a language as simple as C it is simply not possible to > intruduce such overhead by seemingly subtle changes in code. foo(); Do you know what the effects are? I don't. I can probably find out, but that holds for everything. You are clearly comfortabale with finding out what the effect of an 'innconect' C statement are, but not with the corresponding situation in c++. Fine, but that's no reason to dismiss C++. Wouter van Ooijen |
| David Brown <david.brown@hesbynett.no>: Mar 12 10:57AM +0100 On 12/03/15 09:41, Wouter van Ooijen wrote: > distribute the source and the customer can just run it with the > appropriate Python implementation on his platform. But I'd never > consider wrting let's say a compiler in Python. Actually, Python might not be a bad choice for a compiler - especially if it is for a "small" language. It has parsing libraries, and the string manipulation, pattern matching, regular expressions, dictionaries (hash maps), etc., would all be very useful in such a program. The lack of static checking is the biggest disadvantage of Python in my experience. It's far too easy to make a typo somewhere in a variable name, or mix up types (like 1 and "1") - you don't find the error until the code actually runs. |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 11:00AM +0100 Johannes Bauer schreef op 12-Mar-15 om 10:05 AM: > results, the results are really amazing. > But because of the debugging and readability issues. Oh and the horrors > of compiler errors with templates. It's dreadful. As with all features, it is important how they are used. When I write a class template, the very first lines check the classm arguments for suitability. The error messages are still not as clear as they are for a straight error in your code, but you only need to look at the first three error lines (the assert failure, dismiss the location of that assert, and the next line is the template invocation). > And for resource constrained systems, templates are the aboulte worst > because they introduce a TON of code duplication. Again, not when used correctly. I mostly use templates for very thing Adapters, where inlining saves more code than the duplaction costs. But in other situations I derive (or implemnet) the template class from/on-top-of a not-template base class. I guess this pattern has a name, but I don't know it. > I'm not sure what > systems you're referring to, but I'm wokring on Cortex-M > microcontrollers. So let's say a Cortex-M0 with 64k flash. That's a *large* chip in my book. I mostly use LPC1114 level chips. > I dare to to > use one, only a single one of those templated STL library functions and > your ROM will be full already. STL offers run-time flexibility in the size of what you are storing/handling/computing. If you need that flexibility, OK, but most small systems don't: they have a fixed-sized task that must be done, no matter what. Doing more is not a plus. So the STL approach as it is *implemented* in the current STL is totally unsuited for (very) small systems. But some of the basic principles could be very usefull, if implemented appropriately (fixed-maximum-size containers, allocated without heap). > seriously? What is going on? In any case, after implementing stubs for > those, it links: 293 kB of binary! That is almost a FIVE FOLD increrase > in code side fo doing pretty much nothing. I agree the the implementation of std:ostream *sucks* for using on small systems. But I do like the opeartor<< approach, so I have been struggling to find alternatives. So far no real solution, but someday... > useless code that is pulled in actually did shock me. And I double > checked to see if my measurement was correct, and it was. The code is > full of monstrosities like When you switch to the desktop-mindset (memory is cheap, but only cache is fast, average performance is what counts, and better be safe (catch exceptions) that sorry) the design choices that produce this result are not that weird. It is just that small embedded systems require a very different mindset. > Sounds very interesting. Do you have any pointers, I wasn't aware of > that feature. It sounds like something like that could be very useful > for very small systems indeed. No, I have not found much beyond the very technical descriptions of how it is implemented. I use the latest ARM GCC from https://launchpad.net/gcc-arm-embedded , with -fdevirtualize. I compile 'all-at-one', which might or might not be needed. I did a talk on Meetting C++ about my previous approach, based purely on templates called "objects? no thanks": http://meetingcpp.com/index.php/tv14/items/14.html IMO C++ is a wonderfull language for developing code (especially re-useable code) for very small systems, but is difficult to find the correct subset of the language, libraries and programming paradigms (juk, I hate that word) because 1. the vast majority of C++ users work in different fields and hence have very differnt priorities 2. many very-small-systems developers don't appreciate the advantages of C++ and are scared away by the horror stories of linking in large libraries. Wouter van Ooijen |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 11:14AM +0100 Stefan Ram schreef op 12-Mar-15 om 10:40 AM: > programming in C++. He should have come across texts such as (quote): > »Most of the standard and third-party C++ libraries don't > adhere to these limitatins, so they are not useable.« Hey, that's my text, with misspellings and all :) > (German-language) C++ tutorial has a small lesson on > embedded programming containing this advice: > · avoid exceptions (code size) IMO exceptions are not that bad (and often better than the alternatives), if the common implementations would avoid dragging in dynamic memory. More at http://www.voti.nl/blog/?p=40 > · possibly avoid dynamic memory IMO this is the root problem. Dynamic memory is a defense-in-depth, a flexible response, a way to use an unknown amount of resource (memory), at the cost of some unpredicatbility (both in timing and in 'will the memory be available' and what to do when it is not). For a (very) small system those costs often outweight the advantages. > · possibly avoid virtual classes and templates I used to agree on virtual classes, but the upcoming devirtualization might change that completely. I like to use the mechanism, but I hate the cost (it is an optimization and dead-code-removal barrier). When I can have it without the costs: jummy! For me templates are essential. > · possibly avoid iostreams Avoid the current implementations. At a high level I like the operator<< syntax. > · possibly avoid RTTI, dynamic_cast and the container library IMO RTTI and dynamic_cast should be avoided anyway. > · possibly avoid temporary objects I would not know why. Wouter van Ooijen |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 11:16AM +0100 Stefan Ram schreef op 12-Mar-15 om 11:08 AM: >> suitability. > Isn't that what we got concepts for in C++? Oh, wait, > there are no concepts in C++! That's why some people were very eager to get concepts in. IMO something like that is realy needed, but I could not grok the proposals, so maybe they were right to defer it to a later version. Wouter |
| Cholo Lennon <chololennon@hotmail.com>: Mar 12 10:20AM -0300 On 03/11/2015 03:12 PM, Johannes Bauer wrote: > All Linus is saying is that he WON'T. Judging from the amount of > extrodinarily shitty C++ code I have seen in my life, I kind of > understand why. I don't understand your point, In 30 years I've already seen a lot of shitty, really shitty C code too. IMHO the language is not the problem (the programmers are) Regards -- Cholo Lennon Bs.As. ARG |
| Wouter van Ooijen <wouter@voti.nl>: Mar 12 02:47PM +0100 Stefan Ram schreef op 12-Mar-15 om 2:31 PM: > education managers who choose C++ for pupils and students as > a first language to gain some programming experience when > they only have little time for that class.) Now hat's one I can agree on. If you want someone to have a quick programming experience, throw out all the Pascal and C derivates, and go with Python. Wouter |
| Martijn Lievaart <m@rtij.nl.invlalid>: Mar 12 03:11PM +0100 On Thu, 12 Mar 2015 01:27:11 -0500, Paavo Helde wrote: > Thankfully, my last experience with a computer where saving 4 bytes was > important was with Elektronika MK-61, 30 years ago. Funny, my latest experience where 4 bytes was important was twice today, once in a binary protocol where every bit counts, the there in a performance critical app where saving bytes means better cache line efficiency. Having said that, I would use std::vector over malloc/realloc every day unless I know I cannot afford it. M4 |
| Luca Risolia <luca.risolia@linux-projects.org>: Mar 12 03:17PM +0100 On 12/03/2015 10:23, Johannes Bauer wrote: > resolved at compile-time) and what will introduce tons of overhead. By > contrast in a language as simple as C it is simply not possible to > intruduce such overhead by seemingly subtle changes in code. Nonsense. Try to implement all the functionalities of a std::string in C and then you will see what you are talking about. |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 09:18AM >And for resource constrained systems, templates are the aboulte worst Templates fit small-memory systems well when the programmer is knowing what he is doing. |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 09:40AM >absolutely *have* to know the implications of what you're doing in >detail or you can introduce a vast array of problems by a single line or >reference (like std::string). When a programmer is writing code for microcontrollers in C++, he - of course - first has to learn C++ and then microcontroller programming in C++. He should have come across texts such as (quote): »Most of the standard and third-party C++ libraries don't adhere to these limitatins, so they are not useable.« I am by no means an expert in this topic, but my own (German-language) C++ tutorial has a small lesson on embedded programming containing this advice: · avoid exceptions (code size) · possibly avoid dynamic memory · possibly avoid virtual classes and templates · possibly avoid iostreams · possibly avoid RTTI, dynamic_cast and the container library · possibly avoid temporary objects (additions or modifications to this list are welcome) I also have a remark that templates might increase or sometimes decrease code size. An example for the last would be a template instantiation where the compiler only puts those parts of a class into the object file that are really used while without template instantiation the whole class might get included IIRC. |
| ram@zedat.fu-berlin.de (Stefan Ram): Mar 12 10:08AM >As with all features, it is important how they are used. When I write a >class template, the very first lines check the classm arguments for >suitability. Isn't that what we got concepts for in C++? Oh, wait, there are no concepts in C++! |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment