Каково худшее реальное злоупотребление macros/pre-processor, с которым Вы когда-либо сталкивались?
Поскольку я не знаю, какова цель вашего заявления, не могу сказать много.
Но если вы хотите сделать SSR с React , я рекомендую вам взглянуть на эту структуру https://github.com/zeit/next.js [110 ], используйте его в качестве внешнего интерфейса и паруса в качестве API.
nextjs имеет богатые документы и множество примеров, вы можете использовать его, не касаясь сервера, или с вашим собственным сервером, таким как Express, Hapi, Koa.
65 ответов
Я использовал файлы заголовков в качестве больших макросов:
// compile-time-caller.h
#define param1 ...
#define param2 ...
#include "killer-header.h"
// killer-header.h
// uses param1 and param2
Я также создал рекурсивных файлов заголовков.
// compile-time-caller.h
#define param1 ...
#define param2 ...
#include "killer-header.h"
// killer-header.h"
#if ... // conditional taking param1 and param2 as parameters
#define temp1 param1
#define temp2 param2
#define param1 ... // expression taking temp1 and temp2 as parameters
#define param2 ... // expression taking temp1 and temp2 as parameters
#include "killer-header.h"
// some actual code
#else
// more actual code
#endif
Я не люблю препроцессор Boost. Однажды я попытался выяснить, как его использовать (в любом случае у нас был Boost в проекте ...), но, насколько я мог судить, его использование сделало бы мои сообщения об ошибках настолько нечитаемыми, что это не было '
#undef near
#undef far
Когда я был новичком в программировании игр, я писал усеченную пирамиду для класса камеры - это игра, которую я написал, у меня были действительно странные ошибки в моем коде.
Оказывается, Microsoft были некоторые #defines для near и far в windows.h, из-за чего мои переменные _near и _far приводили к ошибке в строках, которые их содержали. Было очень сложно отследить проблему, потому что (в то время я был новичком), они существовали только на четырех строках во всем проекте, поэтому я не сразу понял.
I found it in libtidy,:
/* Internal symbols are prefixed to avoid clashes with other libraries */
#define TYDYAPPEND(str1,str2) str1##str2
#define TY_(str) TYDYAPPEND(prvTidy,str)
TY_(DocParseStream)(bar,foo);
The problem is that visual studio 2005 and maybe other ide go to definition and go to declaration features only find the #define TY_(...) and not the desired DocParseStream declaration.
Maybe it is safer this way.
I think they should put a prefix for each function and not call a macro to do the job.. it's cluttering the code.. but maybe I am wrong about that. What do you think..?
Ps: It seems that almost all the internal function const and others are prefixed using this.. My colleague just told me that it is usual.. wtf? Maybe I missed something.
Однажды я видел пакет макросов, в котором каждое ключевое слово языка Си было псевдонимом, что позволяло вам эффективно программировать на клингонском языке. Именно так, клингонский. (Не)к счастью, проект был заброшен и удален несколько лет назад.