So I was writing a business layer from scratch for Palm OS 5 (only). It made sense to me to use modern programming techniques and make my objects C++ classes.
I’m now regretting it and rewriting using more basic C. I’ll still use C++, since there’s a lot more to C++ than just classes, but I’m done with classes for data. It really boils down to one reason:
C++ objects are created in the heap. To keep my application’s data around between swaps, the data has to be in storage.
I’ve looked at this from various angles and don’t see any reasonable alternative. I could copy my data from permanent storage (SD, and eventually HTTP) to main storage (data) to C++ objects (heap), but this just adds an extra layer of complexity and a heck of a lot more work to do on suspend/resume.
Instead, I plan to create a “record viewer” class. This class will manipulate the bytes in a data record behind the scenes so the upper application layer doesn’t have to. I can actually keep this fairly efficient, I think, by coding the lower layer carefully.
One thing I’m not sure of is how to handle strings. They’re in UTF8 storage, which I don’t really know much about. I expect I’m going to end up using word length Pascal strings padded to even lengths, which will be faster to step through than C-style strings (I’m also a bit worried about UTF8 possibly having NULL characters, but I could clear up that worry with a quick web search if that was the only reason).
Sometimes the old ways are the best ways.
July 28th, 2005 at 1:36 am
Not sure exactly why you think that. Just to clarify from your post, in C++, classes only use heap storage if you make them that way. Here’s an example:
class Foo
{
public:
Foo() : member(new Bar(initData))
{
}
Bar* member;
};
class Foo
{
public:
Foo() : member(initData)
{
}
Bar member;
};
In the first example, if you create a Foo object on the stack, then yes, you are correct, the member variable will be created on the heap. However, if you use the second definition of Foo, everything will be pushed onto the stack.
Now, I’m rereading your post, and this still doesn’t address your issue. If I understand what you’re saying, you want to have a class and be able to store its state externally. Basically, you need to serialize your classes. This is a fairly well explored topic, and what most people use to address this is the >> and
July 28th, 2005 at 3:58 am
Hi Jonathan,
Yes, what I’m talking about is heap (and stack, to be fair) vs. storage. Serializing is a fix for the problem, and it’s something I considered for a while, but by serializing the objects we introduce the cost I mentioned in switching applications: Namely, objects need to be saved when the application is switched out, and restored when switched back. I’m not talking about a dozen objects here, but thousands. That is, of course, if I intend to treat all of my data as C++ objects instead of datatable record IDs.
C++ objects could be a way to handle this. Some way to create C++ objects in storage and reference C++ objects by record ID woud solve these problems, but there seems to be some compiler work needed there. Codewarrior is closed source and dead, and PRC is nowhere near usable as yet (and may never be, since everyone seems to be distracted by the pretty lights of Copland… err, I mean, Cobalt).
Thanks for the comment, though. Sorry something cut it off.
July 28th, 2005 at 4:03 am
To clarify, this is what I had (forgive any imperfections, this is pseudo-code, and I’m not a great C++ programmer yet):
class CSpreadsheet{
CList m_Tasks;
};
This is what I expect to have now:
class CSpreadsheetViewer{
void FindByRecID( RecID recID );
UInt16 GetColumnCount();
RecID GetColumnN( UInt16 n );
};
class CTaskViewer
{
void FindByRecID( RecID recID );
};
Obviously, the first is more pure C++. But the second is probably going to be more useful on the Palm.
August 5th, 2005 at 1:14 am
You could also overload new/delete, in addition to a builder/factory layer to allow you to control where objects are stored. This would likely require proxies (like an auto_ptr) for general access though, which gets ugly (and complicated) quickly, though may be worth the effort for the platform.
But, I’m not sure C++ is worth it on that platform.
August 5th, 2005 at 1:36 am
How do you manage multiple new/deletes? I’m going to have to allocate some interface objects in the heap regardless.
August 8th, 2005 at 12:51 am
Yes, auto_ptr-style classes themselves are heap (or stack) allocated, but their data can be anywhere. Multiple new or deletes can be proxied, by either fronting with builder/factories or similar.