Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 359315 - Preprocessor support for overloaded functions
Summary: Preprocessor support for overloaded functions
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: EDT (show other bugs)
Version: unspecified   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-28 18:31 EDT by Scott Greer CLA
Modified: 2017-02-23 14:18 EST (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Greer CLA 2011-09-28 18:31:51 EDT
Assuming we add a preprocessor that can be called by the generators on a given part and can do wholesale analysis and re-organization of the code, one of its logical responsibilities would be to support overloaded functions.

This would scan the part to detect overloaded functions, functions with the same name but different signatures in terms of arguments and their types.  For each variant, the preprocessor would use some mechanism for allowing the generator to derive the "mangled" function name according to the syntax rules of its target language.  This mangling would need access to the MOF Function object, so that it might take into account the function name, number of arguments, and argument types.

Another aspect of this would be support for creating a "dispatcher" for overloaded functions.  In this sense, the dispatcher is a function that accepts variable args, inspects them, and determines the appropriate function to which it can forward the invocation.   Since the function variants are written in terms of EGL types, it makes sense for this dispatcher to always be invoked with boxed args, providing it with the type information it needs.   Whether a dispatcher should be generated, and when it should be invoked, will probably need to be left up to the generators to consider, however, it's worth noting that where the generated code must be accessible outside of EGL, the dispatcher will probably be required.   However, even if the dispatcher is available, direct invocation of a particular variant will always be more efficient, especially since we usually have enough info. at compile-time to know which variant to invoke.
Comment 1 Matt Heitz CLA 2013-01-03 14:43:38 EST
Setting the target milestone to Future for bugs that won't be addressed in 0.8.2.