Friday, December 16, 2022

Digest for comp.lang.c++@googlegroups.com - 18 updates in 3 topics

Lynn McGuire <lynnmcguire5@gmail.com>: Dec 15 06:44PM -0600

> anyway. When I worked in defense the code to control actuators was never
> more than a few thousand lines which given you had to write it to high SIL spec
> was about as much as humanly possible to vet properly.
 
This article says that the new F-150 in 2016 has 150 million lines of C
code.
https://www.greencarcongress.com/2016/05/20160505-ford.html
 
"Software plays a growing role in new vehicles as demonstrated by the
all-new F-150 that features more than 150 million lines of code, whereas
a typical smartphone operating system has approximately 12 million
lines. Engineers are capitalizing on software to deliver precise control
over aspects of vehicle performance such as engine and transmission
calibration to improve fuel economy and for the connectivity experience
by giving customers hands-free access to their smartphones through SYNC 3."
 
Bill Ford gave a TED talk recently where he said that the average Ford
vehicle has over 100 cpus on the EMS and daughter boards in it.
 
This inforgraphic claims that the average car has 100 million lines of
code which blows my mind:
https://www.visualcapitalist.com/millions-lines-of-code/
 
Lynn
"Öö Tiib" <ootiib@hot.ee>: Dec 15 09:54PM -0800

> hand written, _not_ generated by tools. A recursive descent parser is not that
> difficult to write, and writing by hand gives more control in a number of areas
> including syntax error reporting.
 
Yes, there is need for common errors to be diagnosed in form of easy to
understand to human so not "syntax error" and even not "unexpected
token [ after 'end' token" but something like "end can not be indexed".
That often takes some extra parsing after error has been met. Similar
issue is with parsers for syntax highlighting ... should not just underline
half of text red because of missing ) or something.
 
The textual formats are often contextual so meaning of >> may be
one "greater than" token or two "end of template argument list" tokens but
generated parsers can not typically shew through such cases.
 
Generated parsers can be also tricky to debug ... I can't imagine how fun
was to debug Boost.Wave C++ preprocessor. Person must be extra
motivated to do such work.
 
About common formats like JSON the parser making is like kind of
competition. There benchmarks are biased and it is hard to hand-optimize
generated parsers to be competitive with those biased inputs. At
the same time there are always plenty of competitors ... so why not
to use the fruits of their labor?
 
So generated parsers are typically used on cases when it is hard to
reason why stock syntax and parser of JSON, YAML, MD, MathML,
LaTeX etc. wasn't used.
Muttley@dastardlyhq.com: Dec 16 10:14AM

On Thu, 15 Dec 2022 20:09:23 +0100
 
>Driving aids are not perfect, and they get things wrong sometimes. But
>maybe in the big picture (statistics, not individual cases) they are
>still a win.
 
The problem is if you market a driver aid as "autopilot" then people get the
wrong idea and stop paying attention with the inevitable results especially
if the car "vision" is more falible than human vision in certain circumstances.
Other car companies call it Lane Assist or similar which makes it pretty clear
its not 100% autonomous.
Muttley@dastardlyhq.com: Dec 16 10:24AM

On Thu, 15 Dec 2022 18:44:50 -0600
>lines. Engineers are capitalizing on software to deliver precise control
>over aspects of vehicle performance such as engine and transmission
>calibration to improve fuel economy and for the connectivity experience
 
Yet still does single digit mpg around town. If they really wanted to save fuel
they'd build it out of aluminium and literally save a ton of weight but that
wouldn't get the Kool Kids on board.
 
>by giving customers hands-free access to their smartphones through SYNC 3."
 
>Bill Ford gave a TED talk recently where he said that the average Ford
>vehicle has over 100 cpus on the EMS and daughter boards in it.
 
Ie there'll be a whole heap of faults and trouble awaiting the 3rd or 4th
owner 10 or 20 years down the line and it'll probably be uneconomic to repair
if too many modules fail.
 
>This inforgraphic claims that the average car has 100 million lines of
>code which blows my mind:
> https://www.visualcapitalist.com/millions-lines-of-code/
 
Quite ridiculous really compared to some of the other systems especially given
most of it is in the bloated ICE which many people don't use anyway because
they just pair their phone and use that instead.
 
Why do car companies design the interface of cars for teenagers these days
when the people buying them new are are usually 20+ years older? One of lifes
mysteries.
David Brown <david.brown@hesbynett.no>: Dec 16 01:38PM +0100

> if the car "vision" is more falible than human vision in certain circumstances.
> Other car companies call it Lane Assist or similar which makes it pretty clear
> its not 100% autonomous.
 
Yes, I can see that as a problem - if the marketing or naming makes
people think it is significantly more automatic and reliable than it
actually is. I am not a Tesla driver, nor have I paid any attention to
their marketing, so I can't really comment here.
"Fred. Zwarts" <F.Zwarts@KVI.nl>: Dec 16 02:15PM +0100

Op 15.dec..2022 om 20:09 schreef David Brown:
 
> Driving aids are not perfect, and they get things wrong sometimes.  But
> maybe in the big picture (statistics, not individual cases) they are
> still a win.
 
I think it was a Google member who said about their self-driving car
project: "If we succeed to reduce the number of yearly deaths in car
accidents from 300 per year (number of The Netherlands) to 3 per year,
then we will not receive 297 grateful letters per year from happy people
that are still alive, but we will be sued for those remaining deaths.".
David Brown <david.brown@hesbynett.no>: Dec 16 02:20PM +0100

On 16/12/2022 14:15, Fred. Zwarts wrote:
> accidents from 300 per year (number of The Netherlands) to 3 per year,
> then we will not receive 297 grateful letters per year from happy people
> that are still alive, but we will be sued for those remaining deaths.".
 
Yes. No matter how hard you try to show statistics, or calculate
micromort reductions, people always take death personally!
scott@slp53.sl.home (Scott Lurndal): Dec 16 03:19PM


>Yet still does single digit mpg around town. If they really wanted to save fuel
>they'd build it out of aluminium and literally save a ton of weight but that
>wouldn't get the Kool Kids on board.
 
They've been building the F150 out of Aluminum/Aluminium since 2015.
Muttley@dastardlyhq.com: Dec 16 03:27PM

On Fri, 16 Dec 2022 15:19:04 GMT
>>they'd build it out of aluminium and literally save a ton of weight but that
>>wouldn't get the Kool Kids on board.
 
>They've been building the F150 out of Aluminum/Aluminium since 2015.
 
Thats only the body. Its still a prehistoric steel ladder chassis underneath.
Lynn McGuire <lynnmcguire5@gmail.com>: Dec 16 02:03PM -0600


> Yet still does single digit mpg around town. If they really wanted to save fuel
> they'd build it out of aluminium and literally save a ton of weight but that
> wouldn't get the Kool Kids on board.
...
 
Those single digit mpg days are way past for F-150s. My 2019 F-150 4x4
3.5L dual turbo V6 with the 4 inch lift kit gets 16 - 17 mpg around
town, 20 mpg at 70 mph, and 18 mpg at 80 mph (it is a brick after all).
I just replaced my AGM battery so my start-stop system started working
again so I am getting 17 mpg on this tank so far.
 
And my cab and bed are made out of aluminum. I know this for a fact
from throwing stuff in the bed and scratching the bed protector layer off.
 
Lynn
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 16 12:36PM -0800

On 12/16/2022 5:20 AM, David Brown wrote:
>> deaths.".
 
> Yes.  No matter how hard you try to show statistics, or calculate
> micromort reductions, people always take death personally!
 
For some damn reason this is reminding me of the lyrics of a song (still
alive) from Portal 2:
 
https://youtu.be/22vbhTi1ieI
 
Some people do not seem to care if some people die, as along as the
science gets done.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 16 05:26AM +0100

Now I found a really simple solution:
 
#include <iostream>
#include <concepts>
#include <type_traits>
 
using namespace std;
 
int main()
{
auto variadic = []<typename ... Args>( Args &&... args )
{
auto tupl = make_tuple( ref( args ) ... );
if constexpr( requires( decltype(tupl) tpl ) { { get<0>( tpl ) }; } )
{
auto &firstElem = get<0>( tupl );
if constexpr( is_same_v<remove_cvref_t<decltype(firstElem)>, string> )
cout << firstElem << endl;
}
};
variadic( string( "hello world"), 123 );
}
Bonita Montero <Bonita.Montero@gmail.com>: Dec 16 05:41AM +0100

Now it's so simple that anyone should understand this:
 
#include <iostream>
#include <concepts>
#include <type_traits>
 
using namespace std;
 
int main()
{
auto variadic = []<typename ... Args>( Args &&... args )
{
if constexpr( sizeof ...(Args) >= 1 )
{
auto tupl = make_tuple( ref( args ) ... );
auto &firstElem = get<0>( tupl );
if constexpr( is_same_v<remove_cvref_t<decltype(firstElem)>, string> )
cout << firstElem << endl;
}
};
variadic( string( "hello world"), 123 );
}
scott@slp53.sl.home (Scott Lurndal): Dec 16 03:17PM

> };
> variadic( string( "hello world"), 123 );
>}
 
int main()
{ printf("hello world\n");
}
 
Is far simpler. Complexity is evil.
 
 
"While complexity seeks order through addition, simplicity
seeks it through subtraction. Most people have a built-in bias
toward addition instead of subtraction. For some reason, the
concept of more comes naturally to us."
Bonita Montero <Bonita.Montero@gmail.com>: Dec 16 06:22PM +0100

Am 16.12.2022 um 16:17 schrieb Scott Lurndal:
> { printf("hello world\n");
> }
 
> Is far simpler. Complexity is evil.
 
It wasn't the job to print out hello world. This was just to show
that what I was actually trying to achieve is working. Show me a
simpler solution to check if the first variadic parameter exists
and it is a string-object.
scott@slp53.sl.home (Scott Lurndal): Dec 16 05:42PM

>that what I was actually trying to achieve is working. Show me a
>simpler solution to check if the first variadic parameter exists
>and it is a string-object.
 
Why? Of what usefulness would it be in real-world code? It
remains unnecessary complexity.
Bonita Montero <Bonita.Montero@gmail.com>: Dec 16 07:20PM +0100

Am 16.12.2022 um 18:42 schrieb Scott Lurndal:
 
> Why? Of what usefulness would it be in real-world code?
 
I didn't ask for that.
 
> It remains unnecessary complexity.
 
If you have this problem, then I think this is the simplest solution.
People on Stack Overflow don't have any issues with that, but here
the people act like rebels.
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 15 06:29PM -0800

On 12/15/2022 1:29 PM, Christian Gollwitzer wrote:
 
>> Oh shit! foobaz returns a pointer to missle_command, well, shit
>> happens. Time to go into the bunker...
 
> Why do you need auto here?
 
I would never use auto here. The overuse of auto is not good.
 
 
> foobaz(a, b) -> execute();
 
> You're basically saying that polymorphism is a bad thing.
 
Not at all. This is an example where I would not use auto.
 
 
missile_command* ret = foobaz(a, b);
if (ret)
{
ret->execute();
}
 
Is a lot more clear than:
 
auto ret = foobaz(a, b);
if (ret)
{
ret->execute();
}
 
 
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)