[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reading the PakCompiler source.



As a "side note" - Edheldil is now doing some work on PenguinFile - welcome
to the now "real" member ;)

Another thing - the entire PakCompiler thingy will be almost completely
re(written/organized/sorted) soon. The actual PakFile writing code will be
moved into the library (the code at /src/PenguinFile/) as part of a
ppfCreatePakFileFromFileList () function and I plan to make the option
parsing stuff a semi-seperate part in the lib too (general cmdline and
rcfile parsing).

Well, expect to see some greater changes to PenguinFile soon. I'm
discussing some design issues with Edheldil currently (+ some coding, yes
;) and in 1-2 weeks when exams are over I'll jump right in again.


Adrian Ratnapala wrote:

>---------------------------------------------------------------
>1) (trivial) PakCompiler.cc
>>	if (!PcOptions.StringValue ("--vendorid").empty ())
>>			VendorID = PcOptions.StringValue ("--vendorid");
>
>Dunno about you but I'd do something like:
>
>  if ( !(str_val = PcOptions.StringValue("--vendorid")).empty() )
>        VendorID = str_val;
>
>Or for the purists
>
>  str_val = PcOptions.StringValue("--vendorid");
>  if(! str_val.empty() ) VendorID = str_val;

Ooops. Seems as is I had power shortages in my brain back then. 
<looking> But it doesn't matter *that* much - that's all STL string copying
anyway ;+)
Q: If we make that option parsing stuff generic - should we keep that fancy
STL use or switch to a faster/smaller pointer passing?


>----------------------------------------------------------------
>2)(trivial) OutPakFile.cc
>	// Stub functions needed for correct template instantiation
>	ppOutPakFile &_writeintint8 (int Val, streamsize num=1)
>	{ return WriteInt8 (Val, num);}

>The thing is, I can't for the life of me figure out what these
>members are actually for.  Template instantiation you say?
>How exactly.  I'm srue there is a reason, its just beyond me,
>this is the problem with C++.

Well, there *is* a reason, though this is for sure the ugliest hack I ever
used ;)
Usually (i.e. according to the C++ standard) templates have to be made
publicly available with the "export" statement - but egcs doesn't support
that one yet. That means templates have to be used in the source file where
they are defined - or they won't be instantiated at all :-((

Anyway - these templates have to go. They're only a sort of write
convenience thing like your HAND/DNAH macros.

>----------------------------------------------------------------
>3)
>
>
>>	// "allocate" enough space for the entire dir structure
>>	Target.WriteInt8 (0, StructSize ());
>>	Target.seekp (position);
>
>???  A bit dodgy isn't it?  from reading that, it seems
>it would be OK to just write straight out to Target.
>If not, Target, should export and allocate() method.
>Either way this doesn't seem necassary.

That's because (1) the current archive file format needs to have all
entries of a given directory at one piece and (2) PakCompiler writes stuff
recursively.
Expect a complete rewrite of this.

>>	// Directory Entries -- 1st step: entries representing files
>>	for (FI = files.begin () ; FI != files.end () ; FI++)
>>		(*FI)->WriteDirEntry (Target);
>>
>>	// Directory Entries -- 2nd step: entries representing subdirs
>>	for (DI = directories.begin () ; DI != directories.end () ; DI++)
>>		(*DI)->WriteDirEntry (Target);
>
>Why are files and subdirs different?  Is there some PakFile format
>thing saying that directories must come after files?  Otherwise
>the whole point of polymorphism is that you shouldn't be doing
>this sort of thing.

Hmmm, I *think* I just wanted to have some sorting... and perhaps directory
reading was easier this way (??)

>----------------------------------------------------------------
>4) GetDirInfo.c
>
>First, why did you write it in C?  (Other than "because
>I can").

IIRC because I got weird compiler errors when I tried to use stat() and/or
readdir () in C++ source (Hmm, have to reexamine that).


>Next, that GetEntryXXXX interface is worryingly stateful.

Hmmm, right. I'll habe to do some greater thinking about all that after the
exams....

Cu
	Christian
--

CPU not found. retry, abort, ignore?