Author Topic: Where do I start if I want to learn larger architecthre "C" uC programming?  (Read 13895 times)

0 Members and 1 Guest are viewing this topic.

Offline BloodyCactus

  • Frequent Contributor
  • **
  • Posts: 482
  • Country: us
    • Kråketær
I used to be very anti c++ on embedded, like whoa dude c++ on embedded no way man, step off the bus!! then I found this arduino thing and this 8bit chip had like 1 byte ram and 4 bytes stack and 16kb rom for code... and arduino does it all in c++.. whoa.

everyone started churning out huge shitty c++ sketches on massively constrained shitty 8bit ateml chips. it opened my eyes really. I'm a C guy at heart, and no interest in doing c++ on my stuff at all.  To me, it certainly was an eye opener, but not a road I'll be going down.

I went from non believer to, wow, people can really use c++ on tiny tiny devices.
-- Aussie living in the USA --
 

Offline baljemmett

  • Supporter
  • ****
  • Posts: 665
  • Country: gb
Interesting, I wonder when they fixed that. Last time I tried it was a couple of years ago.

No - if any of the various participants in this pointless willy-waving exercise had bothered reading the code and error message for comprehension, it would become apparent that you almost certainly simply forgot the () on the invocation of p.  It's failing to coerce a function pointer to int&, not demonstrating the problem you presumably had in mind given the context (that the returned pointer can be coerced into a reference even if it is NULL.)
 

Offline andyturk

  • Frequent Contributor
  • **
  • Posts: 895
  • Country: us
No - if any of the various participants in this pointless willy-waving exercise had bothered reading the code and error message for comprehension, it would become apparent that you almost certainly simply forgot the () on the invocation of p.  It's failing to coerce a function pointer to int&, not demonstrating the problem you presumably had in mind given the context (that the returned pointer can be coerced into a reference even if it is NULL.)
Ha! Good catch!

But I think mojo-chan won't ever find a C/C++ compiler that will flag an error for what he's trying to demonstrate. 0 is an acceptable value for any pointer type, so returning 0 from p() shouldn't ever generate an error at compile time. The bug here is the code in (the corrected) main(), which dereferences a pointer without knowing (or checking first) that it's not 0.

Code: [Select]
int main() {
   x(*p());
}
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf