|
> Ahhh... so what you're suggesting (if I follow you) is that every > global/static variable be kept in a seperate, dynamically allocated, > memory location for each instance of each object... calling a > "create_new_instance" (or similar) procedure to allocate new ones > as needed, and assign them some sort of ID or handle so each call to > the service program could know which "object" you're referring to? Exactly, one could pass the pointer of the "object" back and forth or a handle... Personal preference. The list of objects could be contained in a linked list or a btree or whatever makes sense. I like having the service program do all the memory management though :-) And you could allocate the memory in blocks and then do things in a way so that you would not have to worry so much about a fragmented heap. > In that way, you could keep the memory separate for each "instance" > of the object that you need to deal with. > > Yes. That could get very ugly. But it'd probably work, which is > pretty neat. Now, can you make it become threadsafe? :) Yes I think so with the use of Semaphores and such. The burden of thread safety of course depends on the creator of the service program. But seeing as each call has one entry point into the service program that could make it a lot easier. A very inefficient way to do it is to try to allocate the semaphore as the first step and that way no two threads could be changing info at the same time. A better solution would be to have a locking scheme per each attribute of each object. Somewhere in the middle of those two extremes would be the most common route I would think. > A compiler? An intriguing idea! What would it compile the source > into? MI? Could you actually make an executable *PGM object, without > calling an IBM-supplied compiler, somewhere? (In which case, is your > program really a compiler, or just a language converter?) I really think that all compilers are language converters of some sort, and yes I would probably target MI if I were such a masochist. Then I could use the QPRCRTPG API to make the program object... Unfortunately it would be limited to OPM > An interpreter you could certainly do... You could make your own > "Eric-BASIC" which would be interpreted by your RPG program, and > other people could write programs in it... :) Simply evil :-) If I ever have that much time on my hands then I may just do it :-) If I were to do the language thing I think I would port the Free Pascal to the AS/400 as I really like Delphi and I would love to have a tool like it for the AS/400 :-) ______________________________________________ Eric N. Wilson President Doulos Software & Computer Services 2913 N Alder St. Tacoma WA 98407 +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.