- "Jonathan Blow: "C++ is a weird mess"" - 6 Updates
- Namespace indentation - 3 Updates
- How exceptions are implemented? - 2 Updates
- Concept for location - 3 Updates
- Like, who's sabotaging who, or is buggy, wrt. locales? - 2 Updates
| boltar@cylonHQ.com: Jul 20 08:58AM On Thu, 19 Jul 2018 15:43:12 GMT >boltar@cylonHQ.com writes: >Yes, they were altered to avoid exposing proprietary designators. I doubt a class name is going to give us any insight into your proprietary code. >>>derived class constructor completes). >>And if the derived class constructor doesn't complete but throws an exception? >They cannot, by design. It still seems a very obtuse way to obtain a thread. Perhaps its just because I prefer things to be explicit as it makes it a lot easier to maintain and debug. If someone in my team ever wrote code that created a thread in a base class constructor that then called a method in a child class I'd throw it back at them and tell them to rewrite it in a sane manner. |
| scott@slp53.sl.home (Scott Lurndal): Jul 20 01:10PM >>> essentially the same environment I had in 1988. >> If it works for them, why should they change? >30 years ago I was writing C. C worked for me, why should I change? False analogy. In any case, there is quite a bit of C code still being developed and maintained. |
| scott@slp53.sl.home (Scott Lurndal): Jul 20 01:32PM >>Yes, they were altered to avoid exposing proprietary designators. >I doubt a class name is going to give us any insight into your proprietary >code. no point in taking chances. >debug. If someone in my team ever wrote code that created a thread in a >base class constructor that then called a method in a child class I'd throw it >back at them and tell them to rewrite it in a sane manner. It works just like this: https://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html "There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated and started." |
| Thiago Adams <thiago.adams@gmail.com>: Jul 20 06:39AM -0700 On Friday, July 20, 2018 at 10:10:26 AM UTC-3, Scott Lurndal wrote: > False analogy. > In any case, there is quite a bit of C code still being developed > and maintained. The problem I see is not check the new just because the old is working. What is important is to check the new and compare with the old. Something new is not necessary better, but people tend to like more the new and think it is better. This is natural considering we want to improve something and not to make it worst. For computer languages I think all ideas must be taken in account, but also it doesn't mean that we need a new language for that. Sometimes is easy insert new ideas into an existing language. For instance, one feature I like in C++ is the member initializer for non static member. This was added latter and its fine. |
| boltar@cylonHQ.com: Jul 20 01:46PM On Fri, 20 Jul 2018 13:32:43 GMT > to declare a class to be a subclass of Thread. This subclass > should override the run method of class Thread. An instance > of the subclass can then be allocated and started." Its always good to be reminded why I gave up on java and went back to C++. |
| legalize+jeeves@mail.xmission.com (Richard): Jul 20 08:51PM [Please do not mail me a copy of your followup] Vir Campestris <vir.campestris@invalid.invalid> spake the secret code >30 years ago I was writing C. C worked for me, why should I change? If your needs haven't progressed beyond what you were writing 30 years ago, then no need to change. A current example of where that might be the case is coding for small embedded processors. There is limited memory and ROM storage space, so the kinds of situations where large scale problems appear just don't occur. However, I find myself working in larger problem spaces now and C doesn't scale well to larger code bases because of its limited ability to express abstractions directly in code. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://computergraphicsmuseum.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com> |
| Ian Collins <ian-news@hotmail.com>: Jul 20 08:17PM +1200 On 20/07/18 08:55, Vir Campestris wrote: > sure that all tabs are 8, and the code must fit on a VT52. > Nowadays we have bigger screens. Nesting deeply is not the issue it used > to be. <snip> It's not screen size that matters, it is text window size.. -- Ian. |
| Thiago Adams <thiago.adams@gmail.com>: Jul 20 05:41AM -0700 On Thursday, July 19, 2018 at 6:36:33 PM UTC-3, Mr Flibble wrote: > Is this a deliberate troll? I sincerely hope so as the alternative is too > depressing to think about. > /Flibble Try to say something useful about the subject instead of think about depressing stuffs. |
| Thiago Adams <thiago.adams@gmail.com>: Jul 20 01:04PM -0700 On Thursday, July 19, 2018 at 6:13:02 PM UTC-3, Thiago Adams wrote: ... > If the code looks like many layers of abstraction > and the layers are represented by namespace this is > a bad sign for me. Just like class hierarchies. I just found this video from Jon Blow: I agree on this part about layers. https://youtu.be/uZgbKrDEzAs?list=PL_LX30v0VQqEMTTX3uG93_tUnTUPMG6X6&t=351 |
| boltar@cylonHQ.com: Jul 20 08:54AM On Thu, 19 Jul 2018 08:50:50 -0700 (PDT) >a simple world you live in! Mine's a bit bigger and more complicated than y= >ours. How many different countries are there in your world? How many differ= >ent languages? Religions? How small is it, really? *guffaw*, you should do stand up mate! gcc, clang and vc++ probably cover 90% or more of the C/C++ compilers used in the world. Feel free to mention any others that matter that default to C99. And if you're using a specialised C compiler to write to a microcontroller or other proprietary devices there's a good chance that A) It doesn't support C99 anyway B) You don't have a main() function at all C) There will be language extensions and modifications that stretch the definition of "C" |
| David Brown <david.brown@hesbynett.no>: Jul 20 08:11PM +0200 > *guffaw*, you should do stand up mate! > gcc, clang and vc++ probably cover 90% or more of the C/C++ compilers used in > the world. Your numbering is confused. Probably 90% or more of C or C++ programmers use one of these three compilers. But there are a great many compilers in daily use - a hundred or more, I'd guess, and that is not counting variations like the dozens of different targets for gcc or the very significantly different versions of different compilers (there are people using gcc 2.7 today). Most of these are quite specialised, or long out of date and only used because people working with serious projects often insist on keeping the toolchains unchanged. But these are still C compilers in use for real work. (And then, of course, there are the hobby compilers or experimental compilers with a few users each - $DEITY knows how many of these there are around.) > Feel free to mention any others that matter that default to C99. Why would "defaults to C99" have the slightest significance? Neither gcc, clang nor MSVC have ever defaulted to C99. You might, I suppose, ask for /support/ for at least most of C99 as an indication of being a modern tool, which would certainly reduce the number of C compilers in use somewhat. > if you're using a specialised C compiler to write to a microcontroller or > other proprietary devices there's a good chance that > A) It doesn't support C99 anyway Most do support C99, at least the parts that are relevant to the target. > B) You don't have a main() function at all I have only twice seen an embedded C program without a main() function - and in both cases, that was because I choose to write my own pre-C startup code and didn't bother naming a function "main". > C) There will be language extensions and modifications that stretch the > definition of "C" Most have language extensions of some sort, but that does not stop them being C compilers. Certainly /some/ have enough extensions that are important to coding, or enough non-conformities, or require such particular coding styles to get efficient results, that they are arguably a dialect of C or a C-like language. But most embedded compilers are used mainly with standard C. |
| stayprivate@gmail.com: Jul 19 05:46PM -0700 Le jeudi 19 juillet 2018 09:11:57 UTC-4, Paavo Helde a écrit : > building blocks. Restricting the object placement without a very good > reason limits this flexibility and should be enforced by project > guidelines/policies, not by the software libraries themselves. Point taken > > I have two scenarios: > > - Enforce at compile time that an object can only be instanciate on the stack. This is to implement a "safe" dynarray type like object. > What do you mean by "safe dynarray"? What is "unsafe dynarray"? dynarray was a proposed implementation of dynamic array, was voted in working paper in 2013, it was removed from C++14 later in the same year. Definitely cancel in March 2016. For more details: http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0785r0.html > Anyway, I do not see a reason why something which can be placed on the > stack should not be allocated dynamically. In some very rare > circumstances one might even want to allocate a mutex lock dynamically. dynarray is the motivation I have in mind. > I have no idea what could be such a Big object so that its size is huge > and known at compile time already. A table of possible Rubic cube > states? Seems more like a non-existing issue. The OS I'm working with has a defaults stack size of 128K. Some embedded system have less. That being said I understand that it would not be a way to safely control stack usage at compile time, but still. I've often seen issues with something like std::vector::resize where a temporary is created to be copied onto the newly allocated slots. This temporary was busting the stack. > > Does this idea make any kind of sense? > Not much, to be honest. I am even doubting my own long-winded efforts to > suppress stack initialization. Thanks. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 20 05:06AM +0200 > I have two scenarios: > - Enforce at compile time that an object can only be instanciate on > the stack. This is to implement a "safe" dynarray type like object. Since you mention elsewhere that the /purpose/ is to use stack allocation like a VLA or alloca, there is as far as I know no portable way to differentiate whether an object is allocated in automatic memory, as a static variable, or as part of an array or class type object that in turn can be allocated anywhere. Semi-portably you might compare the object's address to an address obtained in `main`, assuming that the stack has some maximum size (that you might infer from a preprocessor symbol) and that it grows down in memory (again probably best to let the build commands specify). That approach gives you runtime checking. As a convenience measure, getting some ungood usage errors up front at compile time, I would then "= delete" the class' allocation functions, `operator new` and `operator new[]`. > - Enforce at compile tiem that an object can only be instanciate on > the heap. This is to ensure That no "Big" object are instanciated > on the stack. I would make the destructor non-public, i.e. implement the restriction with one or two lines: protected: virtual ~Dynamic_only() {} That works nicely with e.g. `std::make_shared`, at the cost of having to use a simple wrapper function. It doesn't work quite so nicely with `std::make_unique`, requiring per-class boilerplate code. But doable, as exemplified below. The `std::make_shared` support below, the `std::make_shared` wrapper, can easily be moved to a reusable mix-in class, I think. Note: the FAQ instead recommends making the constructors non-public and defining factory functions. In C++03 that wasn't so practical, requiring one factory function per constructor. And so I argued a bit with Marshall Cline (the FAQ maintainer at the time), to change the FAQ to recommend the non-public destructor approach, but to no avail. However, with C++11 we now have ~perfect argument forwarding, so that the umpteen factory functions of C++03 can be rolled into one per class, so that the FAQ's advice isn't so impractical anymore. :) So that's an alternative. However I like being able to use the usual instantiation code instead of calling factory functions. ---------------------------------------------------------------------- #include <memory> // std::make_shared #include <type_traits> // std::is_base_ #include <utility> // std::(enable_if_t, forward) using namespace std; template< class T > using ptr_ = T*; template< class T > using ref_ = T&; class Dynamic_only { protected: virtual ~Dynamic_only() {} public: Dynamic_only() {} Dynamic_only( const int, const int, const int ) {} // A default unique_ptr doesn't store a unique deleter, so one must // use indirection via a specialization of std::default_delete. This // works for direct use of this class, but a derived class needs to // duplicate the effort. std::unique_ptr is just deleter-challenged, // which is a cost of zero overhead for the default instantiation. static void destroy( ptr_<Dynamic_only> p ) { delete p; } // A default shared_ptr stores a unique deleter obtained at the point // where the shared_ptr is constructed, e.g. in the return stm below: template< class... Args > static auto make_shared( Args&&... args ) -> shared_ptr<Dynamic_only> { struct Accessible: Dynamic_only { using Dynamic_only::Dynamic_only; // Constructors. ~Accessible() override {}; // Just to be explicit. }; return std::make_shared<Accessible>( forward<Args>( args )... ); } }; #ifndef TEST_UNSUPPORTED_MAKE_UNIQUE // Annoyingly verbose support for std::unique_ptr: namespace std { template<> struct default_delete<Dynamic_only> { constexpr default_delete() noexcept {} template< class U , class = enable_if_t< is_convertible_v< ptr_< U >, ptr_< Dynamic_only > > > default_delete( ref_<const default_delete<U>> ) noexcept {} void operator()( const ptr_<Dynamic_only> p ) const { Dynamic_only::destroy( p ); } }; } // namespace std 
Subscribe to:
Post Comments (Atom)
|
No comments:
Post a Comment