Tomás wrote:
[snippers]
int main(int argc, char* argv[])
{
try
{
CmdLineInfo const &cmdline_inf o = GetCmdLineInfo( argc, argv);
ifstream& source = OpenSourceFile( argv[1] );
ofstream& target = OpenTargetFile( argv[2] );
//Now proceed to manipulate the files
}
catch(Excp_EndP rog e)
{
return e.code;
}
}
If either "OpenSourceFile " or "OpenTargetFile " fail to open the files
successfully, I'll make them throw an exception.
The problem with the code above is that, for the "OpenSourceFile " function
to be able to initialise the "ifstream" object, the "ifstream" object
_can't_ be a local variable of main (which is what I want).
Why can't it be local to main? Really delegate.
Here come some fragments.
class SourceData
{
public:
// yada yada ctor, dtor, copy ctor, op=, etc.
// the ctor includes closing the file in a tidy manner
int StartFile(std:: string name);
private:
ifstream& source;
};
Then add the stuff you need to do to this file. Keep in mind the
notion
that one day you may not be fetching a disc file, but from a URL, or
from some network virtual connection, or SQL calls from a database,
or any old thing you could think of.
Here comes some more fragments. I'm typing this in at the terminal,
so things may not be syntactically correct.
int main(int argc, char* argv[])
{
try
{
CmdLineInfo const cmdline_info(ar gc,argv);
// someplace here you need to define input and
// output mode information, maybe it's done in CmdLineInfo
// maybe that's the 8to32 things, and maybe inMode and outMode
// are really calls to cmndline_info
SourceData mySource(cmdlin e_info.GetSourc eName(), inMode);
DestData myDest(cmdline_ info.GetDestNam e(), outMode);
// the ctor is where you put all the work of getting the file ready
// to start reading/writing
// Notice I said source and dest, not file names
//Now proceed to manipulate the data
mySource.Prepar eToReadLines();
myDest.PrepareT oWriteLines();
while(mySource. Done() != TRUE)
{
myDest.WriteOne Line(mySource.R eadOneLine());
}
}
catch(Excp_EndP rog e)
{
return e.code;
}
}
Really delegate. Don't just use a class as a thing to hold stuff in.
Make it do the work.
Or maybe you need to read in the entire input file into some data
structure.
class Splorp8to32
{
// yada yada ctor dtor op= etc.
};
(Because you mentioned 8to32 and like in your post.)
Then you can do this in a few ways. But what you
want is for the internal data structure not to know about the
details of the file it was stored in. So you want to be able
to build up a Splorp from some kind of thing you can pull
from the file. Line by line, or groupings, or whatever.
So you put a "get one line" func in your input file class.
And you put an "accept one line to add to the Splorp"
func in your Splorp class.
Splorp32 mySplorp;
mySplorp.Prepar eToAcceptLines( );
while(mySource. Done() != TRUE)
{
mySplorp.Accept OneLine(mySourc e.ReadOneLine() );
}
And for writing it out, you just go in the other direction.
You put a "proffer up one line worth of the Splorp" in
your Splorp class, and a "write one line" func in
your output class.
Or you divide it into groups or icons or sprites or
whatever works for Splorps. And your input and output
file classes know how to get one of these chunks into
or out of the storage file. For example, it might be database
calls, and your input/output classes might have to do some
SQL calls to get/retrieve one chunk. But Splorp never gets
to see any of that.
And so on. Really delegate.
Then you can get as magnificently fancy, or as simple, as
your app requires. For example: You could buffer the read/write
ops, so the next, previous, and current line are available. Or
you could log all reads/writes and allow backup/restore.
Or you could add security to every step. Or CRC checks in
case the data line is suspect. And all that junk is going to
be hidden.
Socks
