|
>> I don't think that this requires op codes if - and that is a very big "if" - Barbara and her team can add a requirement into the program creation process and program objects. In part this is what I meant by the comment about descriptor support. This is exactly the use to which it would be put. The descriptors are supposed to be the glue that allows complete inter language parameter passing flexibility but ..... trouble is Rochester still haven't seen fit to even giving us a halfway decent subset of the standard data types. I could live with a set that only supported limited numeric types for example, but there's still no sign of them doing anything. Even with full descriptor support, I might still want to see some op-code support. Look at the situation in printf. It is the _content_ of the format parameter that determines how many and what size, and shape the subsequent parameters are. The called routine doesn't know what it will receive and therefore the compiler can't anticipate it. The parms (in an RPG context) have to be unloaded into specific variables of the correct type/size. The compiler generated code could - using the descriptors if they existed - unload the parms into temp storage and pass a list of pointers together with size/type. In the end though, my code would have to dereference it anyway so an RPG "pop" op-code seemed to be a reasonable approach even if not strictly required. The compiler folks have given us some wonderful C interface capabilities with Options(*String) and %Str but I fear they can't do it all alone. Perhaps the decision not to enhance descriptor support was made by the same Rochester development manager who thinks we all code in C and C++ and therefore only need manual examples in those languages! +--- | 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.