我正在尝试为多个嵌入式平台维护带有示例的代码库.我需要支持一些函数参数的“far”(非16位)指针的概念.
我认为我有一个很好的解决方案,在某些平台上将宏FAR定义为__far,在32位指针(嵌入式Linux,Win32等)的平台上没有任何内容.使用该宏,我可以轻松地将指针定义为somestruct_t FAR * foo.
但后来我开始使用飞思卡尔处理器,他们的编译器要求FAR介于星号和变量名之间. (somestruct_t * __far foo).
我想出来处理这种情况的最佳解决方案是将宏FARPTR定义为__far *,* __far或者只是*,具体取决于平台.这允许somestruct_t FARPTR foo.
那里有更清洁的解决方案吗？特别是,我不喜欢读取该代码的人看不到*.我还担心在涉及函数声明时会遇到问题.从Freescale编译器帮助中获取此语法的负载：
int __far *f(); // __far function returning a pointer to int int * __far f(); // Function returning a __far pointer to int int __near * __far f(); // __near function returning a __far pointer to int
最后一个杀了我 – 返回类型内的限定符表示近函数？！我最近了解到添加__near不足以实际将函数编译到近内存 – 我需要将它包装在pragma中.
那么,有没有人看到比我的FARPTR宏观想法更好的解决方案？
解决方法
freescale处理器的使用与标准类型限定符(例如const)更加一致,该放置使得它引用指针而不是指向的数据.也就是说,因为“远数据”而不是“远指针”将毫无意义,你会认为它无关紧要,但更大的一致性可能会使编译器解析器变得更简单.
你可以使用像kludgey这样的东西：
#if defined __SOME_ARCHITECTURE__
#define DECLARE_FARPTR( type,identifier ) type __far * identifier
#if defined __SOME_OTHER_ARRCHITECTURE__
#define DECLARE_FARPTR( type,identifier ) type * __far identifier
#else
#define DECLARE_FARPTR( type,identifier )
#endif
然后你的声明看起来像：
DECLARE_FARPTR( somestruct_t,foo ) ;
void fn( DECLARE_FARPTR( somestruct_t,foo ) ) ;
或者返回远指针的函数：
DECLARE_FARPTR( somestruct_t,fn( void ) ) ;
正如您所看到的那样,它很快就会变得难以阅读,并且声明性的函数式宏通常是最好避免的.
