- What is easiest to use static C++ code analyser? - 1 Update
- ""Rust is the future of systems programming, C is the new Assembly": Intel principal engineer, Josh Triplett" - 19 Updates
- Order of designated initializers in C++20 - 3 Updates
- forward variable number of arguments precisely to a template method - 2 Updates
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 10:44AM +0200 The best code analyzer is: printing the code out, having a bath with the printouts in the hand or lying in the bad with the code in the hand and a purring cat beside. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 08:39AM +0200 > when they never actually work on those systems). They don't extrapolate > wildly from one small area of software, and they don't make wild claims > with no evidence or reference. No one here has experience with systems where they think exception -handling should be inappropriate for performance-reasons; that's all pure phantasy. |
| David Brown <david.brown@hesbynett.no>: Sep 03 08:31AM +0200 On 03/09/2019 06:49, Bonita Montero wrote: >> in them. > He was talking about flight-computers. And almost every flight-computer > uses VxWorks. No, they don't. VxWorks is certainly a possible option for flight computers, but it is by no means dominant. Indeed, /no/ OS is dominant for such uses - you use redundant systems with different software and hardware. And he was talking about flight recorders (black boxes), not flight computers. > And you don't have any "experience" on that. Nor do you. The difference is, others understand their experiences and limitations, understand the differences in various fields of programming, and try to expand their knowledge beyond their fields (even when they never actually work on those systems). They don't extrapolate wildly from one small area of software, and they don't make wild claims with no evidence or reference. |
| David Brown <david.brown@hesbynett.no>: Sep 03 09:06AM +0200 On 03/09/2019 08:39, Bonita Montero wrote: > No one here has experience with systems where they think exception > -handling should be inappropriate for performance-reasons; that's > all pure phantasy. Sorry, you are wrong again. I have worked on several systems where exception handling would have been ruled out for performance reasons (had the software been written in C++, rather than C). They would have been ruled out of those projects for several reasons, in fact - exceptions are often not suitable where you have tight safety requirements. (You'll be shocked to hear that dynamic memory is also banned in such software.) For most of my C++ projects, exceptions are not used at all. It would simply be unacceptable for there to be errors where throwing an exception could be at all useful - therefore any exception support is pure overhead, and they are disabled at the tool level. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 09:19AM +0200 > Sorry, you are wrong again. I have worked on several systems where > exception handling would have been ruled out for performance reasons > (had the software been written in C++, rather than C). I don't believe you. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 06:49AM +0200 > Kernel, what kernel. From my experience, most of the truly real time > systems have nothing remotely like a *nix or Windows kernel anywhere > in them. He was talking about flight-computers. And almost every flight-computer uses VxWorks. And you don't have any "experience" on that. |
| David Brown <david.brown@hesbynett.no>: Sep 03 10:30AM +0200 On 03/09/2019 09:19, Bonita Montero wrote: >> exception handling would have been ruled out for performance reasons >> (had the software been written in C++, rather than C). > I don't believe you. I don't care. |
| Richard Damon <Richard@Damon-Family.org>: Sep 03 07:11AM -0400 On 9/3/19 3:19 AM, Bonita Montero wrote: >> exception handling would have been ruled out for performance reasons >> (had the software been written in C++, rather than C). > I don't believe you. The fact that you haven't encountered significantly tight real-time requirements doesn't mean they don't exist. I can say from experience that there ARE cases with rules like this, and they have good grounds to exist. Exceptions work in many environments, but not all. Error code returns work in many environments too. Which methods are usable, and which methods are good to use, and which method is best, are VERY subject to the domain you are working in. To think that one method is best everywhere is very myopic, and says that one has been in just a small part of the total space of programming. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 01:17PM +0200 >> I don't believe you. > The fact that you haven't encountered significantly tight real-time > requirements doesn't mean they don't exist. The folks here are Nerds without any experience on that. And if there are any circumstances that would make error-handling through exception not feasible because they would be too slow, this would be very rare. Thus it is not credible that david would have many of such experiences. He is simply a liar! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 03:42PM +0200 Liar! |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 03:51PM +0200 You try to emphasize your credibility as a developer who ewas involved in a lot projects like those I told by referring to others her in this group that have similar special positions. How stupid is that? |
| Manfred <noname@add.invalid>: Sep 03 05:35PM +0200 On 9/3/2019 3:42 PM, Bonita Montero wrote: > Liar! You really love trolling, don't you? |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 05:43PM +0200 >> Liar! > You really love trolling, don't you? Liars which emphasize their competency tend to envision details of their knoweldge. But the only details he envisions are drawing relationships to other specialists here; that's really uncredibel |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:38AM +0200 >> most of the standard-library can be omitted, stack is very limited >> also if there is any and won't get more maintainability over C. > Total and complete nonsense. LOL. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:41AM +0200 > Look at Arduino. I will not argue that Arduino make sense. > ButArduino is used and Arduino uses C++ features. This doesn't mean that C++ makes sense here. > 9 bytes of static allocated RAM. I did not check RAM use for stack, > but there is good chance that stack + static use will fit in 128 > bytes. That's a proof for the advantages of C++ on arduino? > and compiler optimizations allow reasonbly small object code. > Similar approach can be used with plain C, but then one may need > a "program generator" as first step. Templates might induce specialized Boat and inlining also should be better avoided with such a small amount of flash. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:46AM +0200 > Servo's renderer isn't used in Firefox. ... Ok, thanks. > Also, technically Rust does have exceptions--a panic can unwind > the stack and invoke destructors until it gets to a handler. ... But AFAIK only for non-recoverable errors. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:42AM +0200 > printf, or any <math.h> functions - that doesn't mean I won't be using > C. And I can write the code in C++ even if it doesn't use std::string, > or vectors, or new. C++ simply hasn't any significant advantage over C on such tiny projects. |
| Ian Collins <ian-news@hotmail.com>: Sep 04 04:56PM +1200 On 04/09/2019 12:47, Clifford Heath wrote: > But please, "someone is wrong on the Internet" is not a good reason to > continue this. Bonita has that special kind of ignorance - willful > ignorance. There's none so ignorant as one who chooses to be so. Well said! The snipping of attributions is a clear sign of willful ignorance which makes engagement pointless. -- Ian. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Sep 04 04:48AM > and invoke destructors until it gets to a handler. However, much like Go > they dissuade people from thinking and using them as such. See > https://doc.rust-lang.org/nomicon/unwinding.html panic can do that but it is not required, it can just abort as well, currently one can catch panics. Regarding error handling I disagree with previous post. Each function can return discriminate union and Rust has sytnactic sugar for handling errors. -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
| Paavo Helde <myfirstname@osa.pri.ee>: Sep 04 08:31AM +0300 On 3.09.2019 23:09, Richard wrote: >> only been posted to CLC++. > The author of the article barely mentions C++; instead all the > comparisons are to C. This is because the low-level bugs presumably solved by Rust, like out-of-bounds access and memory leaks, are pretty much non-issues in C++. In C++, it is hard to get an out-of-bounds access with for(auto iter=container.begin(); iter!=container.end(); ++i) and even harder with for(auto& ref: container) Similarly, it is much harder to get a memory leak or access-after-destruction if there is not a single owning raw pointer (as produced by malloc() or new) in the program. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 03 02:07PM > than written. We already have a bad case of such silent code reordering > with the initialization lists, the committee probably did not want to > repeat that mishap. I don't really care in which order the parameters are evaluated and the elements initialized. The standard could just as well say that if the designated initializers are not listed in the same order as they are declared in the struct, then the order of evaluation and initialization is implementation-defined, and allow the compiler do whatever it wants with respect to that order. |
| Juha Nieminen <nospam@thanks.invalid>: Sep 03 02:14PM > Ok, that's a proper reason; but as I said above, this would lead to > less readable code because the inizialization isn't synchronous with > the definition. I don't think it would lead to less readable code. The members of a struct may be declared in an "illogical" order because of efficiency reasons. The order of these elements may affect the size of the struct (grouping small elements may make the struct smaller, compared to the situation where large and small elements are declared in alternation). However, in an initialization you may want to list the elements in a more logical order, eg. based on role or meaning. For example if two members are closely related, you may want to list them consecutively in the initialization (even if they aren't consecutive inside the struct, for space efficiency reasons). And, of course, as said, if you ever change the order of the member variables (eg. to optimize the size of the struct), it wouldn't break designated initializers. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 04 06:55AM +0200 >> That might be sometimes so, f.e. when declaring serialized >> data-structures, but that's not typical. > In your, what appears to be, extremely limited experience. My experience is not limited on that. > the C bindings; it's left to the implementation (or the associated > application binary interface (ABI)) to define the order and any > padding. That' proves that this is typical? In C++ you usually don't even insitialize members of structures or classes like this by hand but indirectly through a constructor. |
| Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo>: Sep 02 09:41PM -0400 Trying to write generic code for forwarding arguments via a template method to methods defined in an interface precisely (in particular, all references should be forwarded as references and values as values). Using gcc 4.8.5 and -std=c++11 (cannot change). The best code I could come up with so far is below. Taking the below code as an example, I want generated `callMethod' to have exactly same last 2 parameter types as the interface method it calls ((I,I) for ma, (const I&, const I&) for mb and (const I&, I) for mc). The below code generates, according to nm output, void Caller<IA, 1>::callMethod<void (IA::*)(I, I), I const&, I const&>(void (IA::*)(I, I), I const&, I const&) void Caller<IA, 2>::callMethod<void (IA::*)(I const&, I const&), I&, I&>(void (IA::*)(I const&, I const&), I&, I&) void Caller<IA, 3>::callMethod<void (IA::*)(I const&, I), I const&, I const&>(void (IA::*)(I const&, I), I const&, I const&) commented implementations of callMethod are also failed tries (the last one passes all Is to callMethod by value, the first two do not compile at least one of the instantiations). Any ideas? (gcc 4.8.5 / -std=c++11 is of utmost interest but any working configuration would help) TIA, -Pavel ----------- #include <iostream> #include <functional> using namespace std; struct I; ostream& operator<<(ostream&, const I&); struct I { int i_; I(int i): i_(i) {} I(const I& i): i_(i.i_) { cout << "I(c&" << i << ")\n"; } I(I&& i): i_(i.i_) { cout << "I(&&" << i << ")\n"; } }; ostream& operator<<(ostream& os, const I& i) { return os << i.i_; } struct IA { virtual void ma(I, I) = 0; virtual void mb(const I&, const I&) = 0; virtual void mc(const I&, I) = 0; }; template <class T, const int> // second parameter is to // distinguish the prototypesin nm output with certainty struct Caller { Caller(T& to): o(to) {} T& o; /* template<class... A> void callMethod(void (T::*m)(A...), A&&... args) { (o.*m)(forward<A>(args)...); } template<class... A> void callMethod(void (T::*m)(A...), A... args) { (o.*m)(args...); } template<class M, class... A> void callMethod(M m, A... args) { (o.*m)(args...); } */ template<class M, class... A> void callMethod(M m, A&&... args) { (o.*m)(forward<A>(args)...); } }; struct A: public IA { void ma(I, I) override { cout << "A::ma(I, I)\n"; } void mb(const I&, const I&) override { cout << "A::mb(const I& , const I&)\n"; } void mc(const I&, I) override { cout << "A::mc(const I& , I)\n"; } }; int main(int, char*[]) { A a; const I i1{1}; const I i2{2}; I i3{3}; I i4{4}; const I i5{5}; const I i6{6}; Caller<IA, 1>(a).callMethod(&IA::ma, i1, i2); Caller<IA, 2>(a).callMethod(&IA::mb, i3, i4); Caller<IA, 3>(a).callMethod(&IA::mc, i5, i6); return 0; } ----------- |
| Vir Campestris <vir.campestris@invalid.invalid>: Sep 03 09:29PM +0100 On 03/09/2019 02:41, Pavel wrote: > Any ideas? (gcc 4.8.5 / -std=c++11 is of utmost interest but any working > configuration would help) We're currently taking the pain of upgrading from GCC4.8. The pain of _not_ upgrading has become too much... you realise GCC 4.8 came out in 2013, and all you've had since then is bug fixes? And not all bugs get fixed? Andy |
| 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