[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sv: Sv: Sv: PenguinFile
>(btw - can you please tell your Outlook to use "normal" quoting, i.e. a
>single ">" at the beginning of each line?)
>
Ahh, ok, it's just that that's a bit complicated, as it apparently won't do
that with any Email that has "Sv:" or "Re:" in it's subject field.
>Hmm, I think I'll use memory mapping for this (as well as Pak directory
>reading) - that amounts about to the same (and, as it is directly supported
>by the OS it's faster). Can you check if Win32 also supports memory mapping
>(IIRC I sent you the description of mmap() with the POSIX stuff)?
>
Win32 does not support this. Not to my knowledge. However, if you implement
it something like this: (the name and return type of course doesn't matter;
just the way of specifying which files gets mmap).
ppfBool CacheFile(const char* pUrl)
and if you like:
ppfBool CachePak(const char* pUrl)
or, if you prefer:
ppfBool mmap(const char* pUrl)
ppfBool mmapPak(const char* pUrl)
It should be possible to implement it in Win32. This might get pretty messy
if not well thougth out, though. We'd have to talk a bit about this, then.
Every filehandling function in PenguinFile would have to have special
support for this. On the positive side is that this might be an extra
inticement for Win32 developers to use PenguinFile.
I'll ask around if Win32 REALLY doesn't support file caching. I want to be
VERY sure of this before implementing it... :)
At this point, the version of mmap() I've implemented always fails, and the
version of unmmap() I've implemented always succeds. It's a bad hack, but it
should work for most porpuses (even for those who don't check their return
values).
>>const does not mean "please don't modify that thing", it means "DON'T
>>MODIFY THAT THING!", and a const pointer means "DON'T MODIFY WHATEVER THAT
>>THING IS POINTING TO!". If I pass something to a function and the pointer
>>parameter is declared as const, I expect that it hasn't changed when the
>>function returns. This is exactly what the compiler is expecting too. When
>>you do something like this:
>
>Yes, but I only delete[] a const pointer that I myself declared some lines
>above - not a pointer that was passed to me.
>
Doesn't matter: it's still not proper C++, and it makes it harder to find
out what intend for that pointer, thereby making your code less readily
understandable.
>>const char* pString;
>>strcpy(pString, pWhatever);
>>DoWhatever(pString)
>>delete pString
>>
>>A compiler shouldn't compile the delete line here: it's not proper C++.
>>This would be valid:
>
>I'm still not convinced - but looking at the code I think that this
>situation usually doesn't usually come up. IIRC the use of const there was
>just a bad hack to avoid a warning. It'll change anyway.
>
I don't remember how many times it came up, so don't hang me up on this, but
I seem to remember my compiler reporting this error, and me correcting it,
6-7 times. Don't hang me up on this, though. It was definately more than
2-3, though. Perhaps in the 4-5 range, but I don't think so. Might be more
than 7, but I don't think so either.
If you really want to know, I can set it up again, and I can then tell you
exactly where this happends.
btw, several of the errors was because members of classes that was const was
being deleted, so you'll want to be aware of that too.
>>I have an example from your code where you do this const deletion:
>> [SNIP]
>That's from ppf_Open.cc, right?
>
>>I'm somewhat surprised you don't know this. Actually, I'm EXTREMELY
>>surprised. That along with the fact that your compiler obviously doesn't
>>consider this an error indicates to me that there's something weird going
>>on here I don't know about...
>
>Perhaps it is intelligent enough to see that it doesn't matter
>*in this case*...
>
It should ATLEAST give a warning, then. I don't see why a compiler should
assist someone in writing incorrect code, even if it comes out the same.
char* pThisIsAString = "whatever";
WriteToDisk(pThisIsAString);
WriteToDisk(pThisIsaString);
Should this compile? I would consider it a bug if it did...
Reminds me of when Microsoft first said that each program would be given
it's own memory, and other programs couldn't read or write to this memory in
MS's new OS. But later, people found out something that was quite clearly a
bug that allowed both reading and writing to other processes' memory. Do you
know what Microsoft called it? a "feature" :)
Sorry! I know I'm not being very polite towards you here, but I just
couldn't help myself... :)
>>btw, what is endianess? It isn't even a word in my neither my normal nor
>>computer-specific dictionary (ok, perhaps the computer-specific one isn't
>>really a dictionary, but anyhow).
>
>Byte order. if you have some integer, say 123456789 (hex 75BCD15),
>little-endian machines (like the x86) store it as 15CD5B07 (i.e. least
>significant byte first) while big-endian machines (e.g. PPC) store it as
>075BCD15 (most significant byte first). That sometimes makes reading binary
>data portably a real hassle.
>
Sometimes you REALLY wonder why people couldn't just have agreed on this
from the start, don't you? I mean, something as stupid as this DOESN'T
MATTER, and still, they have to go and make it different. Man, some
people... :( (this goes out to every designer of any OS that took the
decision and that is in the minority on this)
>>Believe me, you use the documentation much more if it's so easily
>accessable.
>
>I believe you - I use JBuilder at work which also has that feature. I
>noticed that this often makes me simply look at the help *before* I really
>think about my problem, slowing me down ;)
>
I did that at first too, but now I don't do it any more. Very nice when
you'r unsure how a specific part of the standard library works, or (in the
case VC++) the MFC library, or any part of DirextX, or any part of Win32, or
...
>>btw, setting breakpoints is as simple as putting the cursor on a line
>>and pressing F9. It works that way too even when debugging is going on.
>
>Well, FTE doesn't provide an interface to the debugger - that's what DDD is
>for.
>
I don't know what FTE or DDD is or how they work, but right off, that would
seem to be quite inconvinient.
>>had to delete the linux partitions and install linux again. It's working
>>now, but it still can't mount the swapdrive... btw, how do you get to the
>
>Did you set up one?
>
Sure did, all 400 megs of it - I know that's way to large, but diskdruid
went funny on me and would only let me add that disk space to that
partition. I know I did because I set the type of one of my partitions as
"linux swapdrive". It was called hd6, and that is esactly the drive linux
cannot mount as the swapdrive, so I'm fairly certain... :)
>Press ctrl-alt-F1 (or -F2 or ... or -F6) and press ctrl-F7 to switch
>back. You can also open a console window anytime (called "terminal" or so).
>
Thanks :)
There's one thing I'm still wondering about, though; what about that using
new and delete in C? Isn't that only C++? Shouldn't C files use malloc() and
free() ?
Also, in PenguinEvent, they are using classes all over in the function
declaration lists and implementations. Here's an example:
// this would be a member of ppeBindingMap if we could have a C++ inteface
ppBool ppeOpenBindingMap(ppeEventType type)
{
ppeBindingMap *map = ppeBindingMap::binding_maps[type];
if(! map ) switch (type) {
case ppeUserEventType: map= new ppeUserBindingMap; break;
default : return true; /*Unknown type, spit the dummy*/
}
ppeBindingMap::binding_maps[type] = map;
map->refcount++;
return false;
}
and yes, I checked: ppeBindingMap is a class, not a structure (besides, I
don't think "::" is C anyway).
When you say everything low-level must be implemented in C, do you mean some
kind of hybrid or something? It would seem to me that having the caller pass
a parameter of a type that is a class certainly does not even make for a C
interface...