Author Topic: Crazyness: C and C++ mixing  (Read 3669 times)

0 Members and 1 Guest are viewing this topic.

Offline netmonk

  • Contributor
  • Posts: 24
  • Country: fr
Crazyness: C and C++ mixing
« on: June 09, 2021, 08:29:30 am »
Hello there.

I try to stick to esp-idf and play with lora rf module.
I know C.
But All the libraries i can find are made in C++.

Trying to mix C and C++ looks like a wild adventure and i dont want to spend time learning C++.

What are you doing in such situation ?
Im just an amateur hobbyist, im quite confused. Is it something usual in MCU world ?
 

Offline tszaboo

  • Super Contributor
  • ***
  • Posts: 5573
  • Country: nl
  • Current job: ATEX certified product design
Re: Crazyness: C and C++ mixing
« Reply #1 on: June 09, 2021, 08:33:51 am »
You can use all the features of C in C++.
You don't need to use the introduced features of C++.
Unless a library forces you to use them.
String manipulation is a lot easier in C++ so even if you just use those parts, you might be ahead.
Former username: NANDBlog
 

Online sleemanj

  • Super Contributor
  • ***
  • Posts: 2737
  • Country: nz
  • Professional tightwad.
    • The electronics hobby components I sell.
Re: Crazyness: C and C++ mixing
« Reply #2 on: June 09, 2021, 08:39:12 am »
Take your .c file, rename it to .cpp, the end (for the most part).
~~~
EEVBlog Members - get yourself 10% discount off all my electronic components for sale just use the Buy Direct links and use Coupon Code "eevblog" during checkout.  Shipping from New Zealand, international orders welcome :-)
 

Offline netmonk

  • Contributor
  • Posts: 24
  • Country: fr
Re: Crazyness: C and C++ mixing
« Reply #3 on: June 09, 2021, 09:14:30 am »
well is it very expensive to transform a c++ library into c ?
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1180
  • Country: se
Re: Crazyness: C and C++ mixing
« Reply #4 on: June 09, 2021, 10:02:09 am »
well is it very expensive to transform a c++ library into c ?
Short answer: it depends.

Slightly longer answer: it depends a lot on how the library is written.

Slightly long answer:
There are two aspects, in general, to a library: its interface and its implementation.
If the interface is class based, with ample use of inheritance, abstractions, or templates the task is very expensive.
A nice design in C++ (e.g. using a template to instantiate and use a specific GPIO port) would take a lot of effort to translate, and the result will probably look contrived and ugly.
The same can be said for the implementation, even though the low levels often tend to look more like C with classes, than real C++.

That said, many of the C++ library one finds on the net, especially Arduino crap, are C++INO (C++ in name only).

Take your .c file, rename it to .cpp, the end (for the most part).
But pay attention to all the 'minor' differences that will come back to bite your ass (e.g. const, enums etc...).
« Last Edit: June 09, 2021, 10:14:07 am by newbrain »
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline netmonk

  • Contributor
  • Posts: 24
  • Country: fr
Re: Crazyness: C and C++ mixing
« Reply #5 on: June 09, 2021, 10:46:46 am »
So what is the general strategy.
I had a little success to use a extern "C" adapting an exemple code provided with a library when i wanted to add usage (ssd1306) of another C library.
But so far, mixing those C and C++ is pretty new for me, and i spend too much time dealing with compilator issue.

Im more comfortable with Pure C. Therefor i should rewrite from scratch all i need i guess.
 

Offline newbrain

  • Super Contributor
  • ***
  • Posts: 1180
  • Country: se
Re: Crazyness: C and C++ mixing
« Reply #6 on: June 09, 2021, 12:22:25 pm »
...(ssd1306)...
Given how simple that device is, this is one case where I would write the library from scratch.
Mine (C for an OKDO E1 board using NXP SDK, written for FreeRTOS and using DMA) is 503 lines, including the usual 30% of blank lines and comments.
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: fi
    • My home page and email address
Re: Crazyness: C and C++ mixing
« Reply #7 on: June 09, 2021, 02:42:20 pm »
But All the libraries i can find are made in C++.
On the embedded device, they're actually freestanding C++, which – because of how much of it is actually implementation-defined and not defined by the C++ standard – can look much more like C than C++ (because freestanding C is well defined by the C standards).

While some core C++ features like classes and templates are available in freestanding C, many things are not.  The standard C++ library is not available, and neither are exceptions.  Operator overloading is rarely used (except for oddball numeric formats and mathematical vectors), and instead C-like explicit method calls are common.

I could make some suggestions on how to augment your C knowledge to exploit this environment to your fullest ability, but because it involves disregarding many things C++ enthusiasts insist are core C++ features that everybody should know, and I'm not interested in language lawyerism or advocacy, only getting shit done as efficiently and as robustly as possible in practice with long-term reliability and maintainability in mind, I shall stop here.
 

Online DiTBho

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: gb
Re: Crazyness: C and C++ mixing
« Reply #8 on: June 09, 2021, 03:02:02 pm »
Perhaps, a practical example is offered by Arduino with their use of a smart subset of the C++ for embedded stuff.
 

Online DiTBho

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: gb
Re: Crazyness: C and C++ mixing
« Reply #9 on: June 09, 2021, 03:09:25 pm »
Operator overloading is rarely used

Yes, over the years ... the only occasion I remember is when I used the {+, -, *, /} operators  to write a fixed-point library.

Why? fixed-point is not already supported in Gcc ... yes, nowadays it is, but I used a very old version of Gcc where fixed-point was not implemented.

So, I think my future needs for operator overload is even more rare nowadays  ;D
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: fi
    • My home page and email address
Re: Crazyness: C and C++ mixing
« Reply #10 on: June 09, 2021, 05:39:57 pm »
Yep – although not all Arduino library code can be called "smart".

If one wants to see exactly how proven successful C++ freestanding code looks like, I suggest Paul Stoffregen's github repositories of Teensyduino cores and Arduino libraries as a starting point.

As an example, his MahonyAHRS implements a Mahony filter for IMUs.  The quaternion operations, quaternion to Euler angles, and even an inverse square root, are all written as C-like functions, while the library itself is pretty well written C++ otherwise: the implementation provides a nicely encapsulated state tracking object a developer-user can instantiate for each IMU they have, in case they have several IMU modules.

Because exceptions are not available (in any freestanding C++ environment I've used), you'll typically see errors reported in C fashion (error return values or error state tracking variables).  Unfortunately, a lot of Arduino code doesn't really check for errors, or even provide error codes...

One example of overloading in use I can think of is how the Teensyduino environment treats the built-in USB Serial object (all Teensies having native USB): the object itself evaluates to True if the USB Serial port is open in an application (on Linux, Mac, BSDs at least), and to False otherwise.  This way, it is trivial for an Arduino sketch running on a Teensy to know whether it is connected to an userspace program (or to a Serial Monitor) or not.
« Last Edit: June 09, 2021, 05:45:54 pm by Nominal Animal »
 
The following users thanked this post: DiTBho

Offline netmonk

  • Contributor
  • Posts: 24
  • Country: fr
Re: Crazyness: C and C++ mixing
« Reply #11 on: June 09, 2021, 09:35:30 pm »
...(ssd1306)...
Given how simple that device is, this is one case where I would write the library from scratch.
Mine (C for an OKDO E1 board using NXP SDK, written for FreeRTOS and using DMA) is 503 lines, including the usual 30% of blank lines and comments.

Well there is a misunderstanding, it's the lorawan in C++ and ssd library in C. As far as i used an example from the lorawan library, in which i wanted to add oled printing, i had to include the C library into C++ code.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: fi
    • My home page and email address
Re: Crazyness: C and C++ mixing
« Reply #12 on: June 10, 2021, 12:12:21 am »
(I am hesitant to post this, because I fear that this will lead to the perennial useless opinion-slinging about C and C++.
  That is not my intention; my intention is just to help extend knowledge about the embedded freestanding C++ environments currently available.  Those exclude most of the C++ standard, as freestanding C++ leaves almost everything up to the implementation; so, my suggestions should not be interpreted in any way as "how a C programmer should learn C++".  This is strictly about existing embedded C++ freestanding environments, and not about full C++ at all; about practical development in embedded environments, not about theory or standards.  If you were to ask me about how someone who already knows C should approach C++, my answer would necessarily be completely different.  My answer would also be very different if someone proficient in C++ were to ask me help with embedded development, although many core points would stay the same – the approach would differ.)

To start with, most existing libraries written for freestanding C++ like Arduino and similar frameworks rely on GNU toolchain compatibility.  That is, they expect that whatever the compiler used is, it should provide a similar freestanding C++ environment as GCC does.  Because of how the freestanding C++ is defined in the standard, the most common set of expectations and rules is the "GNU Freestanding C++ environment".  Now, others do exist, but that one is the "de facto standard" among the freely available libraries and code you'll find on the net.

First, you should read the publicly available final drafts of the C99 (n1256.pdf) (and preferably also C11 (n1570.pdf) and C17 (n2176.pdf)) standards to see how they define freestanding environments.  To simplify, the only standard includes available are <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h>.

Then, assuming you accept GCC being the "de facto" standard here, you should look at what it provides for freestanding C.  In particular, many of the GCC C extensions are available; including integer overflow built-ins and a large number of other built-ins.  Essentially, the code for these is generated by the GCC compiler itself, using the features of the current hardware architecture, according to the compiler flags used.

At this point, you should realize we're very, very far from typical C programming environment.

For C++, the difference between a hosted environment (what most think of when they think or say C++) and a freestanding environment is even starker.
GCC, for example, requires linking against a special support library (libsupc++) to provide the kind of freestanding environment the C++ standard specifies.

This means that most C++ embedded libraries you see on the net are expected to work in an environment that is NOT a freestanding C++ environment as specified by the C++ standard; and probably best described as a C freestanding environment but compiled with a C++ compiler.

In fact, it is easier to describe what is "imported" from C++ into this environment:
  • Templates.
    These provide a way for the compiler to generate different implementations of the same code for different types used.  In C, the best analog is polymorphic include files, like I've shown an example of here.
    The "downside" of templates is that when used with lots of different data types, the code size (Flash or ROM used in embedded environments) can grow much more rapidly than one would otherwise expect.  In general, an extremely useful and powerful tool.
  • Namespaces.
    When using multiple libraries, or otherwise combining code, function and variable names often clash.  Namespaces are a simple but effective tool to manage this, and does not really affect generated code size at all.
    For a namespace tutorial, see here.  Simple to use, no real downsides.
  • Classes and interfaces.
    In embedded environments, classes are used to encapsulate functionality into easily instantated objects.  The class concept itself is the biggest difference to C, and requires a separate post to explore; or you could just learn for yourself for example starting at the cplusplus tutorial.  Interfaces are abstract classes, a description of what a class implementing the interface will provide; these are used so that different implementations can be interchanged without changing any of the code using them.
    In the Arduino world, a Print class implements data formatting, and all the various serial classes use it so they get print formatting for "free".  These are a powerful mechanism, and will make your life easier in this environment.
    You will need to learn how to use and create classes and interfaces; the biggest hurdle here is to understand the concepts correctly.
  • Operator overloading.
    C++ allows classes to define functions that handle operations, when objects of specific classes are used with that operator.
    These are most commonly used in embedded environments with oddball numeric types (say, a Q7.15 24-bit fixed point type), vectors (in the mathematical or geometric sense) and matrices.  Class objects are often overloaded for the bool() operator, so that if (instance) can be used to check if the particular instance is ready/available/okay or not.
    The kind of syntactic/abstract operator overloading that is common in C++, like cout << "stuff", is not used.
  • new and delete, if supported, are just syntactic sugar on top of malloc() and free().
  • References.
    See e.g. here and especially here.  Essentially, declaring a function parameter as type &name means that the user of the function can specify a variable of type type as that parameter, but the function receives a pointer to it.  Very commonly used, and therefore important to understand correctly.
(If I've missed something others expect to be available, please do point it out! I've almost certainly forgotten stuff from the above list.
This list is the "hot potato" I fear may start a flame war, because it may be seen as an assertion that "C++ is just C with classes", which is NOT true.  It's just that in this weird inbetween environment we're dealing with, they are the key concept imported from C++.)

The most notable common C++ features that are NOT used in embedded C++ environments:
  • Anything from the standard C++ libraries.  This includes everything from I/O to strings.  And this means most C++ tutorials really don't work for you, because you don't need to learn how "normal" C++ code does things; you need to understand the logical concepts underlying C++ and leverage them in this weird not-exactly-specific environment.
  • Standard Template Library, STL.  May become more widely supported when memory sizes increase.
  • Exceptions.  Implementing exceptions requires stack unwinding, which is really not feasible in memory-constrained devices.  Instead, errors are passed like in C, either as specific return values, or via error state variables (like errno in C).
    In the Arduino environment, unfortunately a lot of code assumes errors do not occur, so be careful.

I do claim that anyone familiar with or capable of writing freestanding C can learn the core parts of C++ to fully exploit the capabilities of this bastardized environment rather quickly.  The core point is recognizing that the end result is no longer C, and not really C++ either; but a completely new language that shares a lot with those, but still, uses its own way of looking at things and solving problems.  Understanding the concepts correctly, and internalizing how to best exploit them in different situations, is the key: you cannot "translate" code from one language to another – that's just the original language written using the new language; the point is to learn how to solve problems in this new/bastard/whatever language and environment we have here, abiding by its rather inane rules.  Which are not really standard, just.. sorta agglomerated together, like a snowball.

I would recommend reading some C++ tutorials, especially the cplusplus ones, so you understand the concepts listed above; and then just dive head first into the Arduino or other embedded libraries written in sorta-C++ for these embedded environments.  For example, the MCCI Arduino LoRaWAN library.  It looks like a BIG library with so many files, but most of those files contain just a couple of lines of code, so if you download or clone the repository, and start exploring the code in an IDE you find comfortable and can track functions over multiple files, you'll find there isn't that much "stuff" there at all (currently 7665 lines, of which about 2600 are whitespace and comments, and most of the rest are various structure and class definitions; with not much "functional code" at all – so just dive in!), and it is rather easy to understand –– after you grok how the original developers decided to look at things, that is.

I claim that anyone capable of writing the same library in freestanding C will learn (and internalize, so they can properly use) the abovementioned C++ concepts and then fully understand and even enhance the LoRaWAN library faster than they would write or rewrite the library in C.

The opposite direction, getting competent dedicated C++ programmers to become proficient in this oddball environment, is in my experience much harder, for the same reason single-OS power-users find it harder to switch tools than newbie users do: it is harder to "forget" and let go of tools and abstractions you rely on, than acquire completely new ones.  This obviously does not apply to C++ programmers who are also competent in other programming languages (with non-OO paradigms), because if they are, they've already learned how to switch "toolsets", and won't find it hard at all.  Individual exceptions do abound, obviously, because where there is will, there is a way, and when you're having fun, you're having fun.  So this should NOT be taken as a dig at C++ programmers; it is just an observation that C++ provides more tools and abstractions than C does, and in this particular case that can be a hindrance.  I've seen this in other situations wrt. other languages and OSes time and again, and think it is just an understandable quirk in humans, just something to know and work with when needed.  I do believe David2 was a bit bitten by this (based on the one or two videos he did make for EEVBlog2 channel), and I do believe he's definitely a competent C++ programmer.
 
The following users thanked this post: emece67, netmonk, Tagli, DiTBho

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2320
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Crazyness: C and C++ mixing
« Reply #13 on: June 10, 2021, 01:58:02 am »
(To simplify, the only standard includes available are <float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>, <stddef.h>, <stdint.h>, and <stdnoreturn.h>.

That is all that is guaranteed, but other libraries are permitted.

It would be a rare system that did not provide some variety of <stdlib.h> and <string.h>. Or replacements for them, such as Arduino does.

Of course it's quite trivial to code up any functions you need from those yourself, and then you are free to make any size / performance trade-offs you deem desirable in your environment e.g. slow but small byte-by-byte memcpy() might be fine instead of a half KB speed optimised version.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: fi
    • My home page and email address
Re: Crazyness: C and C++ mixing
« Reply #14 on: June 10, 2021, 03:57:33 am »
It would be a rare system that did not provide some variety of <stdlib.h>
Well, no.

<stdlib.h> provides atof(), atoi(), atol(), atoll(), strtod(), strof(), strtolf() functions for converting strings to floating point formats; strtol(), strtoll(), strtoul(), strtoull() functions for converting strings to integer formats; rand() and srand() functions implementing (often poor) PRNG; calloc(), malloc(), realloc(), aligned_alloc() functions for dynamically allocating memory; free() for freeing dynamically allocated memory; abort(), exit(), _Exit(), quick_exit() for program termination; atexit(), at_quick_exit() for registering functions to be executed at program termination; getenv(), setenv(), putenv() for environment management; system() for executing commands using an external command processor; bsearch() and qsort() searching and sorting functions; abs(), labs(), llabs(), div(), ldiv(), lldiv() integer arithmetic functions; mblen(), mbtowc(), wctomb(), mbstowcs(), wcstombs() multibyte/wide character functions.

If you had said a subset of, then I'd happily fully agree, definitely: all reasonable ones provide malloc(), realloc(), free(), strtol(), strtoul(), atoi(), atol(), and GNU-compatible compilers provide abs(), labs(), llabs() via built-ins.

Some, but not all, provide div() and ldiv(). (These return both the quotient and the remainder.  They're rarely used, though.)

Implementations that have sizeof (long long) > sizeof (long), additionally tend to provide strtoll(), strtoull(), llabs(); and if they provide ldiv(), lldiv() too.

Implementations that have either hardware floating point or software-emulated floating point additionally provide atof(), strtof(), strtod(), and if sizeof (long double) > sizeof (double), strtold().

Some provide rand() and srand(), but poor versions.  Use a Xorshift* variant instead: they're almost always faster (no division, just XORs and bit shifts) and more random with longer periods than the linear-congruential PRNGs rand() and srand() traditionally implement.

None provide abort(), exit(), _Exit(), quick_exit(), atexit(), at_quick_exit(), getenv(), putenv(), setenv(), system(), because they just aren't applicable in embedded environments without an operating system.

I don't recall seeing any embedded environment using any of the multibyte/wide character functions, typically because of memory constraints, but Arduino's avr-libc and several arm cores do seem to have at least some sort of support.  (The Unicode library defines some 143,859 characters, so it's better to leave multibyte/wide character support to those who really need to implement it.)

I haven't checked on bsearch() and qsort(), but Arduino does provide both via avr-libc; and the arm cores I have installed in Arduino all use newlib for the arm equivalent of avr-libc, providing the same.

See?  Yes, parts of <stdlib.h> need to be available for example for memory allocation to be possible, but I've never seen a complete implementation in an embedded environment (as the ten functions related to process termination and environment variables just make no sense in a bare metal environment without an operating system).

I know perfectly well that brucehoult knows the above; I am not questioning his knowledge at all, he knows this stuff in-and-out.  I may look like I'm nitpicking, but I really just want to be very careful here, so that new programmers understand that whatever they read about C and C++ usually refers to the standard (hosted) environment, but this here, a mix of freestanding C and C++ but not really either (as the standards define them), is very far from that.

and <string.h>. Or replacements for them, such as Arduino does.
Most of <string.h>, yes.  AFAIK, Arduino relies on avr-libc to provide these.

GCC also provides most of them (strcat, strchr, strcmp, strcpy, strcspn, strlen, strncat, strncmp, strncpy, strpbrk, strrchr, strspn, strstr) via built-ins, like explained in the GCC built-in link I provided above.

While avr-libc (for AVRs) and newlib (for ARMs) do provide a more or less complete <string.h>, strcoll(), strxfrm(), strerror() are rarely used and may not be available.  (The others are so often used they get implemented sooner or later – although some may implement the BSD versions (see strlcpy()) or strncpy() with strlcpy() semantics.)

I believe it is better to start with the minimum set, so that one gets used to the idea of "standard" functionality not being available, and that when available, the implementation may be suspect.  (The avr-libc and newlib floating-point implementation being geared for correctness and being pretty darned slow is kinda-sorta important, when developing for non-hardfloat hardware.  It does not indicate things cannot be done with such hardware, and it does not indicate that software FP is always slow; it's just that these are geared for correctness and not for efficiency.  Sometimes, one needs either faster software FP emulation, possibly with tradeoffs (infinity/NaN and rounding mode details being perfect candidates) or a custom fixed-point math implementation, to do the job at hand.)

It is much easier and fun to discover the good (and familiar) parts in existing environments, and be suspicious enough of things like pre-packaged HALs to examine things, so that one can make an informed decision on what they'll trust and work with, and what needs to be (re-)implemented from scratch.  This is why I believe it is better to start with the assumption that things may not be available, and then discover that hey, in this particular one they are.  If you consider my rationale for this in my previous post, you see why I think this approach works better than the others.

Now, if brucehoult or others have found that other approaches (than the "minimal first" I'm pushing here) work better or have had good experiences with those, please do let me – us! – know.  I am often wrong, and even though this approach has shown the most promise and least nasty surprises when I've helped others learn, my experience is still limited, and I for one would be very interested to hear how others have helped navigate this.
 
The following users thanked this post: Ed.Kloonk, netmonk, DiTBho

Offline Feynman

  • Regular Contributor
  • *
  • Posts: 115
  • Country: ch
Re: Crazyness: C and C++ mixing
« Reply #15 on: June 13, 2021, 09:20:14 am »
You can use all the features of C in C++.
You don't need to use the introduced features of C++.
Unless a library forces you to use them.
String manipulation is a lot easier in C++ so even if you just use those parts, you might be ahead.
That's exactly the way I see it, too.

Since C is a subset of C++, you still can program C-style even if your compiler is set to C++. Yeah, yeah, ... I know that in some details C isn't a 100% subset of C++. But for the most part you can code the same way as you used to in C with cherry-picking some handy features like the mentioned string manipulation.
« Last Edit: June 13, 2021, 09:22:43 am by Feynman »
 

Offline AntiProtonBoy

  • Frequent Contributor
  • **
  • Posts: 929
  • Country: au
  • Trust me, I passed the Voight-Kampff test.
Re: Crazyness: C and C++ mixing
« Reply #16 on: June 14, 2021, 05:05:09 am »
IF you are programming in a C++ environment, then I fail to see why you wouldn't want to write C++ idiomatic code. Time and time again I see rookies making the same mistake of treating C++ like C.

Use strings, take advantage of RAII principles, encapsulate memory management with smart pointers, and so forth.
 
The following users thanked this post: nctnico

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: fi
    • My home page and email address
Re: Crazyness: C and C++ mixing
« Reply #17 on: June 14, 2021, 05:32:34 am »
Which part of my lengthy "THIS IS NOT A TYPICAL C++ ENVIRONMENT" you missed, AntiProtonBoy?

:horse:

In particular, you'll be hard pressed to find C++ <string> – those string functions touted several times in this thread by members including yourself – in freestanding C++ environments.  A good example is Arduino, which implements its own bastardized String class.

:rant:
 

Offline AntiProtonBoy

  • Frequent Contributor
  • **
  • Posts: 929
  • Country: au
  • Trust me, I passed the Voight-Kampff test.
Re: Crazyness: C and C++ mixing
« Reply #18 on: June 14, 2021, 06:34:52 am »
To be honest, I skimmed over your posts, because it reads like a novel. That being said, strings aside, none of the above should preclude you from using built in C++ language features that takes advantage of RAII principles.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 2825
  • Country: fi
    • My home page and email address
Re: Crazyness: C and C++ mixing
« Reply #19 on: June 14, 2021, 07:03:22 am »
That being said, strings aside, none of the above should preclude you from using built in C++ language features that takes advantage of RAII principles.
Except strings.  And exceptions.  And STL.  And the standard library.

Which you'd know if you had read the "novel".  But you, like so many others, choose to just throw advice you believe is correct and helpful, because actually considering and thinking about it and looking at what others have written would be too much effort.  The result is that anyone reading this thread will have hard time deciding who to believe; and because humans are gravitated towards easy answers, yours (and certain others) sound the easiest and therefore the ones others will believe.

Until, of course, they find out the hard way that that was bad advice.  Then, instead of remembering yours was just one of the opinions, they'll decide that everything else in this forum must be garbage, too; that because they listened to you and that backfired, everything else here is just as useless or even harmful.  And everybody loses.

Thank you for confirming I really should not have posted in this thread.  My mistake; I will learn from it.
 
The following users thanked this post: Siwastaja

Offline Unixon

  • Frequent Contributor
  • **
  • Posts: 351
Re: Crazyness: C and C++ mixing
« Reply #20 on: June 14, 2021, 07:13:05 am »
Trying to mix C and C++ looks like a wild adventure and i dont want to spend time learning C++.
It's not a wild adventure, it's completely normal.
You're putting yourself at a huge disadvantage by not learning C++, it makes life a lot easier [if not overused].
You don't have to learn C++ all at once, just pick features you need one by one.

What are you doing in such situation ?
Writing in C++ by default but using only as much language features as necessary so often it's just like C with a nicer syntax.
 

Offline AntiProtonBoy

  • Frequent Contributor
  • **
  • Posts: 929
  • Country: au
  • Trust me, I passed the Voight-Kampff test.
Re: Crazyness: C and C++ mixing
« Reply #21 on: June 14, 2021, 07:54:06 am »
Except strings.  And exceptions.  And STL.  And the standard library.

For starters, STL and built-in core language features are completely distinct concepts! STL is just a bunch of standardised libraries part of the C++ ISO standard. The language itself has a separate core specification. In other words, you can still write idiomatic C++ code without using STL. Professional game developers routinely drop STL in favour for custom libraries, and they also compile without exceptions and RTTI. Arduino is no different in that respect.

The point I'm trying to make here is this: rookies should not fall into the trap of treating C++ language as if it were "C with classes", and then create an absolute dog's breakfast in their project. This is in direct response to OP's dilemma about mixing C and C++ code. For more information, see Kate Gregory's excellent presentation on the subject.

Quote
Which you'd know if you had read the "novel".  But you, like so many others, choose to just throw advice you believe is correct and helpful, because actually considering and thinking about it and looking at what others have written would be too much effort.  The result is that anyone reading this thread will have hard time deciding who to believe; and because humans are gravitated towards easy answers, yours (and certain others) sound the easiest and therefore the ones others will believe.

Thank you for confirming I really should not have posted in this thread.  My mistake; I will learn from it.

Resentment will get you nowhere. Look, I don't mean to come across as unappreciative of your contribution. However, good communication is an important skill. When you express your thoughts in a very verbose manner, the actual message can be lost in a sea of redundant information. Trying to tease out the critical points in long text requires a lot of cognitive load - so of course humans will gravitate towards responses that are more succinct. People are constantly bombarded with excess amount of information every bloody day. Meanwhile, you are competing for their time and attention. In short: less is more; get to the point. If you can't do that... well, that's kinda on you?




 

Online Siwastaja

  • Super Contributor
  • ***
  • Posts: 4208
  • Country: fi
Re: Crazyness: C and C++ mixing
« Reply #22 on: June 14, 2021, 08:51:44 am »
Resentment will get you nowhere. Look, I don't mean to come across as unappreciative of your contribution. However, good communication is an important skill. When you express your thoughts in a very verbose manner, the actual message can be lost in a sea of redundant information.

Except there was no redundant information and the actual message is not lost anywhere. IMHO, Nominal's posts tend to be almost miraculously good communication and always to the point, avoiding unimportant details and going logically deep into the important details that matter. It can be seen they are written by a person who not only has a logically working and quite intellectually honest brain, but puts a lot of effort to get the message through to the reader. But ultimately, the reader still has some responsibility. Again IMHO, if they fail to see the point, I don't think Nominal Animal could have done any better.

Also in my opinion, scientists and engineers should be able to cope with "walls of texts", many books on engineering subjects are over 1000 pages long and for good reasons. Sometimes you just can't distil it to a few lines, or maybe you can, but then you need to be trusted blindly, which seldom is a good idea.
 

Offline dunkemhigh

  • Super Contributor
  • ***
  • Posts: 3099
Re: Crazyness: C and C++ mixing
« Reply #23 on: June 14, 2021, 02:09:08 pm »
Quote
Except there was no redundant information and the actual message is not lost anywhere.

Indeed. If there's a lot of info to impart, it's going to be a long post, and there was little fat with plenty of meat. And I would suggest that absolute length isn't important - people will miss the second sentence of a two-sentence post if they think they have a quibble with the first one (mea culpa).
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 2320
  • Country: nz
  • Formerly SiFive, Samsung R&D
Re: Crazyness: C and C++ mixing
« Reply #24 on: June 14, 2021, 03:11:14 pm »
Resentment will get you nowhere. Look, I don't mean to come across as unappreciative of your contribution. However, good communication is an important skill. When you express your thoughts in a very verbose manner, the actual message can be lost in a sea of redundant information.

Except there was no redundant information and the actual message is not lost anywhere. IMHO, Nominal's posts tend to be almost miraculously good communication and always to the point, avoiding unimportant details and going logically deep into the important details that matter. It can be seen they are written by a person who not only has a logically working and quite intellectually honest brain, but puts a lot of effort to get the message through to the reader. But ultimately, the reader still has some responsibility. Again IMHO, if they fail to see the point, I don't think Nominal Animal could have done any better.

I completely agree. Mr N Animal's posts are always informative and full of rigour, unlike mine. Always worth reading in full, and I do.
 
The following users thanked this post: Ed.Kloonk, newbrain


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf