| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | sortpkt |
Hi Paul PM> You don't need to do anything quite so drastic! I've released the PM> program as public domain, and it includes all the source code. You can PM> use any or all of it in what ever way you like. Got it, ta. Compiles as is without error under BC4 (doesn't run properly, of course). Got 94 "declared but not used" warnings, though, good thing they can be turned off . Nice little bunch of classes, btw, just right for "why doesn't this sodding thing work this time?" problems. And I *love* the RE: remover.... PM> The code is C and C++. It was written with the OS/2 version of BC++. PM> I've compiled it under the MS-DOS version, but it has a hard time PM> running due to the limitation of only being able to allocate 64K of PM> memory at a time. I've noticed that. Probably the line that asks for a chunk of memory equal in size to the combined size of all the packets is the main killer.... Is "int" a 32 bit thing under BCOS/2, btw? The program certainly seems to expect it. I can see how to alter the mem requirements to suit dos, mainly by storing only IDinfo and subject for the sort, not sorting on date, and sorting on only the first 25 odd subject chars (the chance of the subject lines differing after 25 is low, and I think I can tolerate the oddities). Without using kludges, I'll still be restricted to being able to sort 1500 odd msgs, though. I think I can also reduce the code size with some pretty inhumane butchering of your neat source, too. Setting up classes seems to generate amazing amounts of code, so if I use the old trick of putting a bunch of static data and functions into one module to provide encapsulation, it should still remain readable, at least.... If I get really short of mem, I can start using overlays for the code, too (thinks: 50k core code, two or three 20k overlays, would have to be pretty desperate) PM> You'll also need to increase the stack size, as it PM> allocates some large structures as local variables. Haven't struck that problem yet. Is it likely to be something that the compiler will spot? PM> Good luck! psychic, he's gotta be psychic Cheers, and ta again --- PPoint 1.80* Origin: Silicon Heaven (3:711/934.16) SEEN-BY: 711/934 @PATH: 711/934 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.