Don't ad-block us - support your favorite websites. We have safe, unobstrusive, robotics related ads that you actually want to see - see here for more.
0 Members and 1 Guest are viewing this topic.
If anything, won't C++ free up program space compared to C?
2) 99% of the AVR code out there is only C
6) I'd have to learn all the intricacies/syntax of a new language (not everyone is a skilled programmer)
3. Regarding KurtEcks points on virtual functions and abstract/derived classes then one of the first things I would do would be to evaluate any 'bloat'. From past experience there should be very little. The only difference with virtual functions should be the vtables associated with each class for the virtual methods. These just provide the implementation address of the function for each derived class. Rather than calling a method directly the compiler should just add one or two lines of assembler to access the pointer from the vtable and then call that address. I already do this in WebbotLib ie 'distanceRead' works for any distance sensor because the sensor type has a pointer to its own 'read' function.
Quote from: Webbot on October 13, 2010, 10:40:08 AM3. Regarding KurtEcks points on virtual functions and abstract/derived classes then one of the first things I would do would be to evaluate any 'bloat'. From past experience there should be very little. The only difference with virtual functions should be the vtables associated with each class for the virtual methods. These just provide the implementation address of the function for each derived class. Rather than calling a method directly the compiler should just add one or two lines of assembler to access the pointer from the vtable and then call that address. I already do this in WebbotLib ie 'distanceRead' works for any distance sensor because the sensor type has a pointer to its own 'read' function.Sounds great. VTables work great as long as you keep things simple. That is for example you don't have classes that are derived from multiple base classes and you find some way to turn off dynamic type casting. My earlier library code the compiler was generating run time type information and all of the support code that went along with this, including I believe Try/Catch. ...Kurt
class Timer{public: Timer(tcnt register){ m_tcnt = tcnt; } uint16_t read(){ return read(m_tcnt); }private: m_tcnt;}Timer timer0(TCNT0);Timer timer1(TCNT1);
class Timer{public: virtual uint16_t read(void) = 0; // derived classes must implement the read};
class Timer0{public: uint16_t read(void){ return TCNT0; };}class Timer1{public: uint16_t read(void){ return TCNT1; };}Timer0 timer0();Timer1 timer1();
Does ANYONE use any of the low level stuff in WebbotLib? eg do you manipulate individual timers rather than use the scheduler? Do you use any of the timer compare/channels for timing purposes rather than using the inherent clock?
Timer *ptTimer1 *pt1pt1 = (Timer1*)pt
what is the differences in the code sizes when you use the different methods.
if the timer is not already in use then just set it upelse look at the current timer mode (WGM) and pre-scaler etc to see whether it can still be usedelse give an errorendif