- "Why does the C programming language refuse to die?" - 7 Updates
- Concatenating strings efficiently - 5 Updates
- In template class, temporaries are substituted for [...] - 1 Update
| Lynn McGuire <lynnmcguire5@gmail.com>: Oct 24 02:03PM -0500 "Why does the C programming language refuse to die?" https://hub.packtpub.com/why-does-the-c-programming-language-refuse-to-die/ "Portability leads to true ubiquity" "Programmer-driven memory management" "Structure is all I got" "Applications that stand the test of time" "C: the backbone of our operating systems" "What does the future holds for C?" Lynn |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 24 09:54PM +0200 On 24.10.2018 21:03, Lynn McGuire wrote: > "Applications that stand the test of time" > "C: the backbone of our operating systems" > "What does the future holds for C?" Disclaimer: I haven't read that article. It's an interesting (to me) question whether C++ can be evolved so that all the intrusive runtime support relative to C, which stands in the way of using C++ in some contexts, is removed. The most offensive feature in that respect is IMHO exception handling, but there Herb Sutter has proposed a much more elegant scheme than the current, with minimal/no runtime support. More like Eiffel. Nom nom. Then we have thread support. The current C++11 stuff can probably be made optional, like a library. After all it started out as a separate library, in Boost. But the upcoming transactional memory stuff, with dedicated keywords, sounds much more entangled with the core language, difficult to remove. And is designed from the start as an integrated part of the language: no history (that I'm aware of) as a separate library. So, no guidance and experience in how to factor that out. :( Dynamic memory management may have some default C++ specific runtime support, e.g. for all I know some implementation might have an efficient small objects sub-allocator involved, but one can always just define `::operator new` etc. to use the C `malloc`-family facilities. I think that's it, roughly (am I very wrong there?), and if so, then the main thing that stands in the way of using C++ where C is now used, is the upcoming transactional memory stuff. Let's hope it's not adopted. But if history serves as guidance, it will be. :( :( :( Cheers!, - Alf |
| Ian Collins <ian-news@hotmail.com>: Oct 25 09:13AM +1300 On 25/10/18 08:54, Alf P. Steinbach wrote: > The most offensive feature in that respect is IMHO exception handling, > but there Herb Sutter has proposed a much more elegant scheme than the > current, with minimal/no runtime support. More like Eiffel. Nom nom. Yes, I have used C++ without exceptions and RTTI in places (drivers) which are usually the exclusive domain of C. You can also statically link the C++ run-time, but that's a bit of an overkill. -- Ian. |
| scott@slp53.sl.home (Scott Lurndal): Oct 24 08:23PM >It's an interesting (to me) question whether C++ can be evolved so that >all the intrusive runtime support relative to C, which stands in the way >of using C++ in some contexts, is removed. Sans Exceptions, Sans RTTI and sans STL, we have built two operating systems and a large-scale hypervisor using C++ (consider it the C++ 2.1 subset) at various large companies (Unisys, SGI, 3Leaf Systems). All dynamically allocated data structures override operator new/delete and use pool allocators. All we needed to add was this: /* * This is called by setup64.S to call the constructors of global objects, * before it calls dvmm_bsp_start(). * * GNU LD lays out the __CTOR_LIST__ as an array of function pointers. The * first element of the array (index == 0) contains an integer which * represents the value derived from subtracting two from the actual number * of entries in the table. Thus the content of the first element is * one less than the index of the last entry in the table. * * Call in reverse order XXX - why? Check crt0.o for canonical behavior */ extern "C" void __call_constructors() { size_t count = *(size_t *)__CTOR_LIST__; for(count++; count; --count) { __CTOR_LIST__[count](); } } /* * G++'s generated code calls this if a pure virtual member is ever called. */ extern "C" void __cxa_pure_virtual() { panic("pure virtual function called\n"); } /* * This is needed even though we don't ever use the delete operator because * G++ generates an extra (unused) virtual destructor that calls it. */ void operator delete(void *) { panic("operator delete(void*) called\n"); } /* * Catch unintended calls to new. */ void* operator new(size_t) { panic("operator new(void*) called\n"); } /* * G++ generates code for shared library support, even though it isn't * relevant (or called). That code looks for this symbol. */ void *__dso_handle; /* * Global object constructors call this to register their corresponding * destructor. We just ignore it; we never call global object destructors * because we never exit. */ extern "C" int __cxa_atexit(void (*f)(void *), void *p, void *d) { return 0; } |
| David Brown <david.brown@hesbynett.no>: Oct 24 10:25PM +0200 On 24/10/2018 21:54, Alf P. Steinbach wrote: > difficult to remove. And is designed from the start as an integrated > part of the language: no history (that I'm aware of) as a separate > library. So, no guidance and experience in how to factor that out. :( There is no problem with features in the core language as long as they don't cost if they aren't used. C++11 threads and atomics, for example, are not a problem - if you don't use these, they cause almost no overhead because the relevant functions from libraries are not linked in. The same applies to C11 threads and atomics. (There is one PITA - thread-safe static initialisation. It is a cost that is, for the most part, completely unnecessary. There should be some way to define variables that are static, local to a function, but initialised pre-main just like namespace scope statics.) I expect the same will apply to transactional memory stuff - if you don't use any of these features in your code, the library overhead will not need to be linked in. Exceptions are a different matter. The way exceptions work in C++ today is that they are enabled and active by default, in all functions. You pay for them everywhere - you have the stack unwind tables that can be a very significant code cost in embedded systems, and you have the (small but non-zero) optimisation limitations from the requirements of being able to unwind the stack. RTTI is in the same bag - it costs by default. So as far as I can see, it's fine to have new things in the core language and support libraries, as long as they don't lead to more linked library code when they are not used. > main thing that stands in the way of using C++ where C is now used, is > the upcoming transactional memory stuff. Let's hope it's not adopted. > But if history serves as guidance, it will be. :( :( :( The new exception system, if implemented, will help a lot. But there are other reasons why C is more popular than C++ with -fno-exceptions -fno-rtti flags in small embedded systems. Part of it is FUD and conservatism - a lot of embedded code is written in C90, rather than C99 or C11, and C++ is still viewed as "new and complicated". |
| bitrex <user@example.net>: Oct 24 04:30PM -0400 On 10/24/2018 03:54 PM, Alf P. Steinbach wrote: > But if history serves as guidance, it will be. :( :( :( > Cheers!, > - Alf I get the impression that C is still successful is because what the people who made it set out to make was a programming language. the later "Better Cs" were made by people who set out to make a programming language....because they hate C! ugh! C's the worst! Arrrghhh.... It shows |
| bitrex <user@example.net>: Oct 24 04:43PM -0400 On 10/24/2018 04:25 PM, David Brown wrote: > -fno-rtti flags in small embedded systems. Part of it is FUD and > conservatism - a lot of embedded code is written in C90, rather than C99 > or C11, and C++ is still viewed as "new and complicated". it is misplaced conservatism IMO. I see few advantages to using C on embedded platforms in year of our Lord 2018, even platforms like the MSP430. C++ makes the lack of intrinsic dynamic memory management on devices with small amounts of RAM _easier_ to live with, not less so |
| Christian Gollwitzer <auriocus@gmx.de>: Oct 24 08:53AM +0200 Am 24.10.18 um 01:06 schrieb Öö Tiib: > express that but you considered it good idea to cut it in reply: > "Implementing it separately feels pointless in modern world where > non-naive implementation of LZW is often quicker than memcpy." Sorry I missed that. I thought you were saying this is a theoretical concept, while I was trying to say that it is indeed part of one of the most widely used compression schemes. So I think we agree :) Christian |
| boltar@cylonhq.com: Oct 24 09:44AM On Tue, 23 Oct 2018 12:40:40 -0400 >> of javascript and python programmers demonstrate every day. >Poor bitrex has to formulate algorithm from scratch but interviewer gets >to pull problem from Wikipedia. Hmph. I see how it is. So what? The company isn't testing the interviewers abilities, its testing yours and they don't owe you a job. If you can't implement an algorithm from scratch then perhaps move over to web coding where your lack of ability won't be such an issue. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 24 11:41AM On Sat, 2018-10-20, Ralf Goertz wrote: > complicates things as Manfred put it and I still see no point in being > allowed to do so. (I guess this is true for you as well if I read your > other post correctly.) Yes. I'm sure there /is/ a point, but I don't see it. > I know very little about optimisation but I think > the need to check for one special value of "pos" can a heavy burden > performance-wise. I suppose the way to satisfy the s[s.size()] thing is to keep operator[] as-is, but make sure there's always padding at the end of the string. The same padding, I guess, makes it possible to implement s.c_str() without an extra buffer. >> (Not that there's really a '\0' in any C string either; it's halfway >> there, halfway not. Traditionally, a fertile source of bugs.) > Is there not? I thought that's how strings are terminated in C. Someone who shares my view answered that. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| bitrex <user@example.net>: Oct 24 03:51PM -0400 > yours and they don't owe you a job. If you can't implement an algorithm > from scratch then perhaps move over to web coding where your lack of ability > won't be such an issue. The tech biz needs more arrogant, humorless nerds. That's what it needs! |
| bitrex <user@example.net>: Oct 24 03:55PM -0400 > yours and they don't owe you a job. If you can't implement an algorithm > from scratch then perhaps move over to web coding where your lack of ability > won't be such an issue. Get a load of this cat. Motherfucker probably thinks he's doing people a favor by hiring them. I somehow doubt that. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 24 05:16AM -0700 On Tuesday, 23 October 2018 23:09:42 UTC+3, Jorgen Grahn wrote: > There's also the problem: if you haven't tried the less commonly > useful and more advanced techniques, how do you know when to use them? > Let others review the code, maybe. There is plenty to learn about the basic techniques like usage of standard library containers starting from std::string, usage of standard library algorithms, RAII, const correctness, rule of five and exception safety. Standard library itself is large enough and also there are lot of mature third party libraries for any topic. Accomplishing something using some of those would make one familiarized with lot of techniques. It is pointless to start from building "generic" square wheels instead. |
| 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