yyrkoon

More C versus C++

54 posts in this topic

@NurseBob Thanks for you input. We should move the I2C talk to the other thread if more conversation presents it's self. So we can try to keep this post on topic. Just sayin' and not blaming anyone, which if anyone is to blame it's me who shifted the conversation towards I2C.

NurseBob likes this

Share this post


Link to post
Share on other sites
23 hours ago, NurseBob said:

Well, I don't find any real conflict between OO and event-driven systems; the events just need to be incorporated into the design.  I guess I think of hardware events as a variant of messaging. My '430 code tends to have a setup in main that ends in a "forever" while loop structured around an LPM3 statement. Hardware events set state flags and the loop figures out how to handle the event, then goes back to sleep. I know from a '430 standpoint that's pretty much a standard design, but the "fun" has been in figuring out how to code for the ISRs, which live in a C subroutine and then chain back to a C++ class handler. The main concern and complexity for my limited brain is the design of a "generic" I2C ISR to handle the I2C communication for each of my I2C device classes. In essence the design for each I2C device is class-based, but dependent on the one I2C ISR, which uses a state variable and switch/case construct contain the handling of each I2C device's needs.  I'll be soon finding out if the overall design is sound as I incorporate the remaining I2C sensors and devices.

I meant to respond to your post here in more detail concerning "Event driven". So, I'll usually mix up OO with event driven when talking about event driven. Which I do not think that event driven is necessarily a part of what makes a language Object Oriented. But I can not remember using an Object Oriented language that did not have some form of events. VB.NET, C#, and Javascript are all languages I've personally had hands on with using events. In the context of C++, using events is very similar to you'd do the same thing in C. Which is to say, for me, this does not feel very much like an event at all. Just a function that is occasionally called when some condition is met. With other languages higher level than C++, such as those I've already mentioned, The message pump loop is all abstracted away, and for me this totally feels like an event. Weird huh ? Using interrupts though, again feels very naturally event driven to me. But on some very low level, I'm sure there is something similar to a "hardware message pump", or at minimum some sort of conditional checks that fire the interrupts off. I won't pretend to know the hardware on that level however. Knowing just enough to know how to use an interrupt is good enough for me.

I also do not really know the low level gory details of how these events work, but I'm fairly confident that there is some form "wrapper" or interface code, that's really running a message pump loop. Similar to how you'd see in C, or C++. Now days with C++, there may even be something in the STL, but I do not know for sure. I try to keep myself busy programming, instead of spending all my days keeping up with the C++ STL. Which is one reason why I'll try to avoid C++ most of the time. I do not feel like I have enough time to keep up with the language 100%, and still do what I need to get done programmatically. The other part of that equation, is that unless I really know something in full detail, I'm not exactly happy about using that thing. This does not mean I think I know everything about C. This means, I think I'm proficient enough with C, that if I am unfamiliar with a concept, or language feature. It will not take me long to brush up on the subject - Usually.

So here is my take on the whole C++ class ISR thing. It's too complex. Complex code is more likely to be buggy, or have mistakes in it. If in contrast you feel more comfortable using C, for ISR handlers. Then by all means just write the code in C, and use C++ elsewhere where it makes more sense for you. Do keep in mind, I understand the *need* to do things differently in order to learn something, or possibly start thinking about that given thing differently. Complex code is also more likely to be slower. Unless your compiler is very good at optimizing things out. Which C++ compilers seem to be working "magic" in this area in the last several years. But this is yet more information you need to overfill that full glass of a brain we have already . . .

NurseBob likes this

Share this post


Link to post
Share on other sites

Events: Such a range of sources. Hardware (internal and external), timers, user-generated, etc.  As you alluded to, there's usually a heirarchy of priorities that impact how they are, or need to be, handled. I don't really have any internal association between event-driven and OO; one reflects how things happen, the other is merely one way to define a world view. The PC GUI world is certainly built around the event model and the understanding of the potentially random timing of events coupled with a management of event priority. My fading memory seems to recall that the original implementation of the Windows GUI several decades back was niether OO nor C++, but a loop which handled and/or generated messages.

As to my own project, the ISRs are C.  The name mangling of C++ led to problems. So, just as TI's C++ libraries do, I define the ISRs as extern C routines. I do spend some time looking at the order and frequency of the case statements in terms of execution, but my implementation spends very little time doing any communication with the sensors, and typically only in response to a sensor-generated interrupt (also rare events), otherwise the app is spending it's time sleeping.

I agree, complex code is likely slower to execute. And almost never should reside in an ISR; aside from my TX RX event handlers, my ISRs follow the "set a flag or generate a software  interrupt and return" rule. And as much as possible, even the TX RX handlers are setting flags for a main-based while loop to process then go back to sleep where communication timing is not an issue.

My knowledge of the C language is probably barely adequate to the task, as well as is my knowledge of C++. However, experimentation is a basis for how my brain works and remembers.  I've spent hours in the debugger stepping through both C and disassembled code; fixed problems, and sometimes have even remembered not to create the same problem again. Were it not for Google, code snippets, reference circuits, etc., my little project would have never gotten started, let alone to the point it's reached. Ok, now I'm rambling...

dubnet likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now