Team 67 C++ Code

[GabeRC1717]

It took me the longest time to understand what the difference was between a pointer to an object and using the new keyword without a pointer. But it is fairly simple. In windows there is the stack and the heap. Pointers go on the heap and variables (objects that are not pointers included here) go on the stack. Stack variables expire after the function they are in returns, and that memory is not guaranteed to not be reused. Heap objects last forever, until they are deleted. For example:

void myFunction() {
     MyClass instanceOnStack = MyClass();
     MyClass *instanceOnHeap = new MyClass();
     return;
}
// instanceOnStack expires after the function returns
// instanceOnHeap lasts forever and that memory will remain untouched until the object is deleted

Hope this helps, and thanks team 67 for posting some C++!

[Bomberofdoom]

Originally Posted by GabeRC1717

It took me the longest time to understand what the difference was between a pointer to an object and using the new keyword without a pointer. But it is fairly simple. In windows there is the stack and the heap. Pointers go on the heap and variables (objects that are not pointers included here) go on the stack. Stack variables expire after the function they are in returns, and that memory is not guaranteed to not be reused. Heap objects last forever, until they are deleted. For example:

void myFunction() {
     MyClass instanceOnStack = MyClass();
     MyClass *instanceOnHeap = new MyClass();
     return;
}
// instanceOnStack expires after the function returns
// instanceOnHeap lasts forever and that memory will remain untouched until the object is deleted

Hope this helps, and thanks team 67 for posting some C++!

That made much more sense to why to use the pointer for objects. Thank you.

Just for an example, in order to use the Get functions, say PWM.Get() [returns the latest PWM value], you need to keep that info from the last call of teleop or auto function. Using the stack, will expire when the teleop/auto functions ends (when you reach the function's "}"). using the heap, they will stay untill the robot is shutdown (when I think about it, maybe there's also the use of an EEPROM to store info....Nope...If you think about it, for 2009 they add "Intiailize", "execute/default" and "close" functions for all robot modes (disabled, teleop, auto), therefore when you create your objects, when you close the robot's power, they will be deleted from the heap and created from scratch the next time the robot is powered and the CRio's proccessor goes through the initialize function of whatever robot mode).

Starting to get the hang of it.... I might consider rewriting some of the previous year's code to C++ soon (just writing a template not including the WPI libraries, but can be copied into the offical code when it comes out, and it should work.)


P.S
One more thing:

What about:
code:

MyClass instanceOnwhat = MyClass();

[GabeRC1717]

Originally Posted by Bomberofdoom

That made much more sense to why to use the pointer for objects. Thank you.

Just for an example, in order to use the Get functions, say PWM.Get() [returns the latest PWM value], you need to keep that info from the last call of teleop or auto function. Using the stack, will expire when the teleop/auto functions ends (when you reach the function's "}"). using the heap, they will stay untill the robot is shutdown (when I think about it, maybe there's also the use of an EEPROM to store info....Nope...If you think about it, for 2009 they add "Intiailize", "execute/default" and "close" functions for all robot modes (disabled, teleop, auto), therefore when you create your objects, when you close the robot's power, they will be deleted from the heap and created from scratch the next time the robot is powered and the CRio's proccessor goes through the initialize function of whatever robot mode).

Basically yes. RAM is volatile memory so those objects will be deleted when the robot shuts down. In windows however, it is very important to delete pointers like so:

MyClass *instance = new Myclass;

//Do some stuff, program is about to exit

delete instance;

If you don't that object will remain in memory until the computer reboots, this isn't an issue on robots, but it is generally considered to be good form when writing C++. Glad I could help clarify.

[Bomberofdoom]

Originally Posted by GabeRC1717

Basically yes. RAM is volatile memory so those objects will be deleted when the robot shuts down. In windows however, it is very important to delete pointers like so:

MyClass *instance = new Myclass;

//Do some stuff, program is about to exit

delete instance;

If you don't that object will remain in memory until the computer reboots, this isn't an issue on robots, but it is generally considered to be good form when writing C++. Glad I could help clarify.

Yeah....the diffrence between a computer and a robot....
This really brings me back to the days when I started my first year of FIRST, trying to understand writing C for a ROBOT. Took me about 2-3 weeks to understand it all. And that was on the Build Season's time. Good thing we're gathering info before the kickoff.

P.S

I wasn't thinking about the fact the the RAM in a robot is volatile, I was thinking more of because of the Close functions assigned for each robot mode, the objects get deleted. Or atleast you could use it to do the delets there and be more....safe? :S

[GabeRC1717]

Also I have noticed that the body of all of the functions are defined right in the class definition. Instead of having the class definition in a header file and the function bodies in a cpp file. Is there are particular rhyme or reason for this?

Originally Posted by GabeRC1717

Also I have noticed that the body of all of the functions are defined right in the class definition. Instead of having the class definition in a header file and the function bodies in a cpp file. Is there are particular rhyme or reason for this?

The sample code was provided that way. It was simple to just expand on the samples. I agree, it's a little unconventional.

[Dave Doerr]

Originally Posted by Hjelstrom

How is the debugger support? Can you step through code running on the cRio? Can you inspect the values of variables? Print to a debug window on the driver station?

Greg,

Wind River does have debugger support, and we've tried using it, but we haven't made much progress learning how. However, note that I have almost zero experience using a debugger. I recommend downloading the WR evaluation and spending time with it.

You can step through running code and inspect the values of variables. You can't yet display user information on the driver station or dashboard (using C++), but both of those have been promised at a later date (actual date TBD).

So far, the method we rely on for debugging is the old standard, "printf" to the console. There are several methods to view console output. You can view output on two different WR consoles over your laptop ethernet connection -- wired or wireless. Also, the cRIO has a serial port to which you can attach a terminal (your laptop or another laptop).

The method I like best is the bluetooth serial adapter that we've just begun using. It plugs into the cRIO serial port and can link to your bluetooth laptop. We have a "Firefly" from Spark Fun Electronics. It's a class 1 device - if you have class 1 on your laptop that will give you a 300 meter-long serial "cable".

Dave D

[lilstogi11]

We're def using C++ this year. Thanks for posting your code.

Has anyone written anything in Python yet?? I really need to know how it works out. We've been dieing to use Python.

[GabeRC1717]

Originally Posted by Bomberofdoom

MyClass instanceOnwhat = MyClass();

This would be on the stack. The new keyword is what causes a pointer to be returned instead of a variable. In fact, with stack variables, the constructor can be called implicitly:

MyClass instanceOnStack;

instanceOnStack is now a fully initialized MyClass on the stack, the constructor is called automatically.

[Bomberofdoom]

Originally Posted by GabeRC1717

This would be on the stack. The new keyword is what causes a pointer to be returned instead of a variable. In fact, with stack variables, the constructor can be called implicitly:

MyClass instanceOnStack;

instanceOnStack is now a fully initialized MyClass on the stack, the constructor is called automatically.

I'm sorry, it's been a while since I posted that post....
Don't really remember why I wrote that, and I don't see the logic in why I did that since you've allready wrote the same type of code and you said the the instance goes to the stack in that way.

So, I belive I made a mistake and wanted to ask what happens when I write:

MyClass InstanceonWHO = new MyClass();