Tuesday, September 3, 2019

Digest for comp.lang.c++@googlegroups.com - 25 updates in 5 topics

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
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 03 06:51PM +0100

On 03/09/2019 14:29, David Brown wrote:
> have a project coming up with 2K flash and 128 byte ram on the device.
 
Such a device sounds fucktarded this day and age. Get a better device or
ask your employer to stop trolling you.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"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."
Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 08:03PM +0200

>> have a project coming up with 2K flash and 128 byte ram on the device.
 
> Such a device sounds fucktarded this day and age. Get a better device
> or ask your employer to stop trolling you.
 
On such a device C++ doesn't make sense. You can't use any heap so
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.
Keith Thompson <kst-u@mib.org>: Sep 03 11:03AM -0700

>>> requirements doesn't mean they don't exist.
 
>> The folks here are Nerds without any experience on that.
 
> And you base that on what evidence?
[...]
 
David, might I suggest you not waste everyone's time arguing with this
person?
 
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
legalize+jeeves@mail.xmission.com (Richard): Sep 03 06:39PM

[Please do not mail me a copy of your followup]
 
Lynn McGuire <lynnmcguire5@gmail.com> spake the secret code
 
>"Rust is the future of systems programming, C is the new Assembly:
>Intel principal engineer, Josh Triplett"
 
>https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/
 
From the article:
>> One of the reasons why Mozilla got interested is that Firefox was
>> written in more than 4 million lines of C++ code and had quite a bit
>> of highly critical vulnerabilities.
 
Does anyone here have any familiarity with the Mozilla source code? I
know it's open source, but I've never looked at it. I'm mostly
interested in things like:
 
- How do they handle errors? Is it C-style error codes or do they use
exceptions?
- Do they introduce small abstractions or only "big" abstractions
(e.g. god class code smell)
- Are they leveraging the type system for abstractions, or are they
doing things C-style with void*?
- Is the code full of "naked new/delete"? or are they using resource
encapsulation
 
My experience has been that lots of C++ code is written in a C style
and therefore very little of the benefits of C++ are realized in
practice.
--
"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>
Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 08:46PM +0200

> My experience has been that lots of C++ code is written in a C style
> and therefore very little of the benefits of C++ are realized in
> practice.
 
The Firefox HTML-renderer Servo is writen in Rust.
Rust is a smart language, but unfortunately it lacks exception.s
Error-handling is done through returning a combined structure with
error- and return-codes. So error-handling is almost as complex as
in C.
Daniel <danielaparker@gmail.com>: Sep 03 12:16PM -0700

On Tuesday, September 3, 2019 at 2:03:47 PM UTC-4, Keith Thompson wrote:
 
> David, might I suggest you not waste everyone's time arguing with this
> person?
 
Not wasting everyone's time with arguments, at least not mine, as I don't have
experience programming on small devices, have limited real time experience,
and appreciate David's informed perspective. On the other hand, I would
suggest that writings along the lines of "ignorant ... blind, stubborn,
willful and insistent ignorance ..." is unnecessary, as of course is "liar",
not to mention "fucktarded". I would say "this person" is in many respects a
very capable programmer, judging from her other postings.
 
Best regards,
Daniel
David Brown <david.brown@hesbynett.no>: Sep 03 09:50PM +0200

On 03/09/2019 19:51, Mr Flibble wrote:
>> have a project coming up with 2K flash and 128 byte ram on the device.
 
> Such a device sounds fucktarded this day and age. Get a better device or
> ask your employer to stop trolling you.
 
It is an entirely suitable device for the task in hand. It has plenty
of flash and ram, has the required peripherals, is physically small (but
not /too/ small), and costs about $0.35. There is a good, free C and
C++ compiler (not entirely standards conforming, as you might expect -
such as no exception support). It is the best device for the job.
That's why I picked it.
 
However, if you know my job better than me, know the microcontroller
world better than me, know my customer better than me, and know this
particular project and its requirements better than me, then maybe I
should follow your advice. What would you recommend? An embedded Linux
card, for example, so that it can run your gui library? It shouldn't
increase the cost of the system by more than a few orders of magnitude,
and the customer will surely be happy with a wallet-sized solution
rather than a coin-sized solution.
 
Or perhaps you simply haven't the faintest idea what you are talking about?
David Brown <david.brown@hesbynett.no>: Sep 03 09:53PM +0200

On 03/09/2019 20:03, Bonita Montero wrote:
 
> On such a device C++ doesn't make sense. You can't use any heap so
> 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.
 
Usually such devices are programmed in C, and it is likely that I use
that here. C++ is a perfectly reasonable choice, however - you don't
have to use the full standard library in order to use C++ and take
advantage of the language's features. I won't be using malloc/free, or
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.
legalize+jeeves@mail.xmission.com (Richard): Sep 03 08:07PM

[Please do not mail me a copy of your followup]
 
BGB <cr88192@gmail.com> spake the secret code
>We add some features to support things like bounds-checked arrays and
>similar;
>We mostly call it done.
 
Been there, done that, 30 years ago. It's called C++. You only pay
for bounds-checked arrays if you want to pay for it.
--
"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>
legalize+jeeves@mail.xmission.com (Richard): Sep 03 08:09PM

[Please do not mail me a copy of your followup]
 
gazelle@shell.xmission.com (Kenny McCormack) spake the secret code
 
>Why is this posted to CLC? Surely, the comparison is more valid to
>C++, given that C++ has things like exceptions and so on. It should have
>only been posted to CLC++.
 
The author of the article barely mentions C++; instead all the
comparisons are to C.
--
"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>
David Brown <david.brown@hesbynett.no>: Sep 03 10:14PM +0200

On 03/09/2019 20:03, Keith Thompson wrote:
> [...]
 
> David, might I suggest you not waste everyone's time arguing with this
> person?
 
Yes, I think that is probably a good idea. I am not particularly happy
with some of the posts in this thread, but I have still been trying to
correct factual errors or fill in missing information.
legalize+jeeves@mail.xmission.com (Richard): Sep 03 08:14PM

[Please do not mail me a copy of your followup]
 
Anton Shepelev <anton.txt@gmail.com> spake the secret code
 
>[...] Code with exceptions is not
>transparent, because it hides the error-handling part of the
>algorithm, and incomplete information is akin to a lie.
 
Code with subroutines is not transparent, because it hides the details
of the algorithm and incomplete information is akin to a lie.
 
You are essentially arguing for code that is 100% details with 0%
abstraction.
 
Return codes and exceptions are two different strategies for handling
errors. Handling errors is bug-prone because most people don't do
sufficient unit testing to force their code down all the error
handling paths to validate the error handling. This is true whether
you use exceptions or return code style error handling. However, I've
seen far more bugs in code that uses return code style error handling
than I've seen in code that uses exceptions.
--
"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>
scott@slp53.sl.home (Scott Lurndal): Sep 03 08:33PM


>On such a device C++ doesn't make sense. You can't use any heap so
>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.
scott@slp53.sl.home (Scott Lurndal): Sep 03 08:35PM

>willful and insistent ignorance ..." is unnecessary, as of course is "liar",
>not to mention "fucktarded". I would say "this person" is in many respects a
>very capable programmer, judging from her other postings.
 
Funny, I get the opposite impression. She seems to be a "my way or the
highway" programmer; someone with strongly held, but poorly justified
positions who won't mesh well with any competent programming
team.
Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Sep 03 10:43PM +0100

On 03/09/2019 20:50, David Brown wrote:
> customer will surely be happy with a wallet-sized solution rather than a
> coin-sized solution.
 
> Or perhaps you simply haven't the faintest idea what you are talking about?
 
No I don't think you should choose a solution just so you can use a "gui
library" as that would be just as fucktarded as your decision to use this
antiquated technology. You chose wrong.
 
/Flibble
 
--
"Snakes didn't evolve, instead talking snakes with legs changed into
snakes." - Rick C. Hodgin
 
"You won't burn in hell. But be nice anyway." – Ricky Gervais
 
"I see Atheists are fighting and killing each other again, over who
doesn't believe in any God the most. Oh, no..wait.. that never happens." –
Ricky Gervais
 
"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."
antispam@math.uni.wroc.pl: Sep 03 10:08PM


> On such a device C++ doesn't make sense. You can't use any heap so
> 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.
 
Look at Arduino. I will not argue that Arduino make sense. But
Arduino is used and Arduino uses C++ features. Quick check shows
that LED blinker example takes 1066 bytes of code. It uses
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.
 
Arduino tries to make coding easy at cost of efficiency. There
are similar approaches getting more efficient and smaller code.
In particular there are examples which are much more complicated
that LED blinker that still fit into 2k code and 128 bytes RAM.
 
Coming back to C++, with small devices the idea is that you have
largish library of useful utility routines. Largish in the sense
that whole library is larger than the device. Writing program
you specialize library to specific purpose. Classes and templates
allow combinig parts of library in interesting ways. Inlining
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.
 
--
Waldek Hebisch
BGB <cr88192@gmail.com>: Sep 03 05:13PM -0500

On 9/3/2019 3:07 PM, Richard wrote:
>> We mostly call it done.
 
> Been there, done that, 30 years ago. It's called C++. You only pay
> for bounds-checked arrays if you want to pay for it.
 
I was meaning in a way which behaved more like a hybrid of Java-style
arrays and raw pointers, and worked from C, rather than something like
std::vector or std::array or similar, which has different semantics (the
usual pointer fun doesn't work on them), and they require using C++...
 
Or, if you mean doing something custom which can better approximate C
style array/pointer semantics in C++, this could be doable.
 
Granted, the big inescapable drawback with any of these options is that
using them would come with a bit of a performance overhead (so may not
ultimately solve all that much).
"Öö Tiib" <ootiib@hot.ee>: Sep 03 07:17AM -0700

On Tuesday, 3 September 2019 17:08:02 UTC+3, Juha Nieminen wrote:
> 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.
 
I would like diagnostic (like lot of compilers give on case of
misordered initializer lists) and sure, if wrong order is ill-formed
then compiling it is implementation-defined extension.
Bonita Montero <Bonita.Montero@gmail.com>: Sep 03 07:48PM +0200

> The members of a struct may be declared in an "illogical"
> order because of efficiency reasons.
 
That might be sometimes so, f.e. when declaring serialized
data-structures, but that's not typical.
scott@slp53.sl.home (Scott Lurndal): Sep 03 08:33PM

>> order because of efficiency reasons.
 
>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.
 
The standards bodies; POSIX, for example, don't even define
the order of structure members in structures that are part of
the C bindings; it's left to the implementation (or the associated
application binary interface (ABI)) to define the order and any
padding.
 
Part of the reason that C/C++ don't impose an ordering on
designated structure initializers is because the order may differ between
implementations, thus any source code that assumed a particular order
in an initializer wouldn't be portable.
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
legalize+jeeves@mail.xmission.com (Richard): Sep 03 08:17PM

[Please do not mail me a copy of your followup]
 
David Brown <david.brown@hesbynett.no> spake the secret code
 
>Another option that would be interesting for static analysis is a gcc
>plugin, possibly written in a different language (Python is a reasonable
>choice for such tasks).
 
Bwuahahahahaha! That is hilarious. Seriously. I know they've
improved gcc at this point, but Stallman et al. have literally said
that they made the internal interface as painful as possible to put
into a library on purpose because they didn't want anyone doing that.
 
Clang was designed from the ground up to be used as a library.
 
>I can't tell you whether clang or gcc would be the best starting point
>for making your own static analysis tools, but I look at both of them
>/long/ before looking at lex/yacc.
 
Don't bother looking at lex/yacc because the context-sensitive nature
of many C++ constructs makes it impossible to use lex/yacc.
 
Don't waste your time with GCC because it isn't designed to be used
this way.
 
Go straight to clang because that's what it's been designed for.
--
"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>
Juha Nieminen <nospam@thanks.invalid>: Sep 03 02:16PM

> MyFunc
> (double x);
 
> I've tried a few different code beautifiers and none of them can turn this into a one-liner.
 
What should happen if the names of the function and its parameters, and the types, are together
so long that they would make the line overly long (like several hundreds characters long)?
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.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)