- linus - 6 Updates
- "C++17 Is Now Official" - 1 Update
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 11 08:21PM On 11/12/2017 19:23, David Brown wrote: > grows automatically when needed - but for an OS, that is likely to be > exactly what you /don't/ want because your function could suddenly take > much longer to execute than it usually does. I hope you don't think (a lot of people do this) that using the STL means use std::vector everywhere. You are correct std::vector isn't appropriate for kernel dev due to likelihood of making a bad allocation decision/mistake. When I use the STL for Userland dev I use the full array of containers available based on what container properties are appropriate for the task in hand. For kernel dev a pool allocator + std::list is probably the way to go rather than std::vector. /Flibble -- "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| David Brown <david.brown@hesbynett.no>: Dec 11 09:48PM +0100 On 11/12/17 21:21, Mr Flibble wrote: > available based on what container properties are appropriate for the > task in hand. For kernel dev a pool allocator + std::list is probably > the way to go rather than std::vector. It is all about using the right tool for the job. That might be std::list, or std::array (which should be zero overhead). But whatever you use, you need to be careful - depending on what you use, your custom allocators, your compiler flags, your library versions, etc., it is easy to end up pulling in lots more into your code than you intended. In my world, you want your OS to be small (a few KB) - you don't want to accidentally pull in malloc, exception handling, printf, software floating point routines, and all sorts of things that can be used by large template libraries behind the scenes. (This really happens.) On the other hand, you don't want to spend time and effort reinventing the wheel when you want a hash table. So I am not saying "don't use the STL" - I am saying be careful with it, and consider different implementations of similar libraries. |
| David Brown <david.brown@hesbynett.no>: Dec 11 09:52PM +0100 On 11/12/17 20:54, Scott Lurndal wrote: > not likely to find much use in a kernel that avoids STL. Although even atomics > may be too high-level to replace the __sync_* functions GCC uses > to expose the low-level primitives. Lambdas are not related to the STL or standard library. If you find them convenient syntax, use them - if not, don't. They don't give you anything you could not do before, they just provide another syntax that can be neater than normal functions in some places. static_assert is /immensely/ useful, IMHO. But you could get the effects with macros pre C++11 - it's just the error messages were obscure. |
| Ian Collins <ian-news@hotmail.com>: Dec 12 09:57AM +1300 On 12/12/2017 09:52 AM, David Brown wrote: > Lambdas are not related to the STL or standard library. The STL became part of the standard library in 1998, it is no longer a distinct entity! -- Ian. |
| scott@slp53.sl.home (Scott Lurndal): Dec 11 09:17PM >> has be don't even bother in an operating system. >You use custom allocators to eliminate fragmentation or maintaining >locality of reference with the standard library. You can, but why? The overhead of most STL containers makes them unsuitable for real-time (which is the definition of a kernel). |
| Ian Collins <ian-news@hotmail.com>: Dec 12 10:26AM +1300 On 12/12/2017 10:17 AM, Scott Lurndal wrote: >> locality of reference with the standard library. > You can, but why? The overhead of most STL containers makes them > unsuitable for real-time (which is the definition of a kernel). The overhead isn't an issue, containers such as std::array don't have any and std::vector has no more than the equivalent hand written code. We use std:deque with a custom allocator in or driver layer. Yes we could probably roll something more specialised, but why bother? The real problem is run time support library dependency. You can work around this to some extent by using a static run time library, but that's far from ideal. -- Ian. |
| jacobnavia <jacob@jacob.remcomp.fr>: Dec 11 04:46PM +0100 Le 11/12/2017 à 07:52, Öö Tiib a écrit : > there some puzzle. Is the puzzle "boring", "tiresome", "interesting", > "challenging", "problematic", "painful" or outright "nightmare"? > On what that depends? Is the patch going to break something else somewhere else? What are the consequences of the patch? C++ is highly interconnected. Class hierarchy, template instatiations, all the features that allow highly abstract code make any change a very perilous exercise unless you master the whole. SFINAE is fine if you want to avoid template errors with types that shouldn't be used for this particular template. OK, but now, instead of an error you get nothing, just your template doesn't apply and you do not know why or which template did not work. The error (if it is an error of course) appears somewhere else, in an unrelated part of the code and you have to figure it out. Each addition offers new, interesting possibilities of course. The downside is a higher level of abstraction and distance from the error symptoms and the source of it. |
| 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