Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Is this kosher wrt Generic? Date: Sat, 11 Jan 2020 09:35:53 -0800 Organization: A noiseless patient Spider Lines: 99 Message-ID: <864kx13ngm.fsf@linuxsc.com> References: <9679a23f-e071-4b9f-a9b1-559951d351e1@googlegroups.com> <86bltlej42.fsf@linuxsc.com> <86imn38qov.fsf@linuxsc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a658bb27d1b88b897660621da5fe7a9e"; logging-data="30932"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+mhxPmyBWycV0a30NsFPSb3xjdSC+qZXg=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:q2qb3kLBSfv2iKxdWnibkgi+lGM= sha1:+nzrH7X+WWQTOk9Ul45ybboixTs= Xref: csiph.com comp.lang.c:148935 Ian Collins writes: > On 29/11/2019 13:35, Tim Rentsch wrote: > >> Ian Collins writes: >> >>> On 09/11/2019 18:03, Tim Rentsch wrote: >>> >>>> Ian Collins writes: >>>> >>>>> On 06/11/2019 01:57, Thiago Adams wrote: >>>>> >>>>>> C is dangerous but it is simple. When you know the tool you >>>>>> know exactly what the compiler is doing and you know from a long >>>>>> time what is important to do and check. How to deal with the >>>>>> details. >>>>>> >>>>>> C++ is complex and nobody knows happens under the hood. This is why >>>>>> site that shows the compiler output are so useful nowadays for C++ >>>>>> community. >>>>>> >>>>>> C is not perfect and C++ is not so bad. Personally I wish I could >>>>>> select some features from both and add some extra ones. >>>>>> This is why I created my own C front end. >>>>> >>>>> The complexity in a programming problem is a constant. You can solve >>>>> it in the C way with a large number of simple steps, which introduces >>>>> extra complexity in making sure they all work together. You can solve >>>>> it with fewer step in a higher level language, which introduces extra >>>>> complexity to the language. The overall complexity remains constant. >>>> >>>> Mother Goose comes to comp.lang.c. >>> >>> I assume by your recent tone that you have been smoking something... >> >> Ahh, and here we have another ad hominem remark. When one >> doesn't have either the facts or the law on their side, all >> that's left is attacking the character of one's opponent. > > Pot, kettle? None of my comments here have been ad hominem remarks. I have said things about what you have said, but nothing of what I have said has been about you as opposed to what you have said. >>> Take a concrete example: resource management. >>> >>> In C resource management is transparent but manual, the programmer has >>> to track what has been allocated and know when to free it. This, >>> along with the opportunity for error, gets quite complex when a >>> resource is shared, especially between threads. >>> >>> In C++, adding some extra complexity in the language (constructors and >>> automatic object destruction) removes the complexity and the >>> opportunities for error from the user code. >>> >>> The code is still doing the same work and may well compile down to >>> equivalent assembler. The overall complexity remains constant. >> >> Two problems: this assumes complexity is a scalar, which it >> isn't, and that it is simply additive, which it also isn't. > > In the example I mentioned, the complexity could be a measure of the > generated object code required to solve the problem. If C and C++ > generate the same or very similar object code, it's fair to say the > code is doing the same work and to compare the complexity of (and > opportunities for error in) the source code. If you think the complexity of a programming _problem_ is constant, then measuring generated object code cannot be a valid complexity metric. >> Furthermore it ignores the cost of all the other complexity in >> C++ that must be paid whether the program needs it or not. > > C++ has always had the philosophy of if you don't need it, you don't > pay for it. Having a philosophy doesn't mean it has been achieved. The idea that you don't need to know about language features you don't use has long been debunked. >> Very few programs, if any, need all of the complex features that C++ >> provides. > > And very few, if any, use all of the complex features that C++ provides. See above. >> I think it was Tony Hoare who pointed out that a >> programming language shouldn't the union of all features needed >> by any program, but rather the intersection of features needed >> in every program. Otherwise essentially every program is paying >> a complexity cost for some unneeded features. > > David has already said all I would have said in replay to this. If you mean David Brown, I didn't see his comments.