TIP: Click on subject to list as thread! ANSI
echo: locsysop
to: Paul Markham
from: Roy McNeill
date: 1994-04-24 20:44:42
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™.