#define with space

Можно ли написать определение с такими пробелами, как:

#define replace to replacement here

Я хочу заменить « заменить на » на « замена здесь ".

РЕДАКТИРОВАТЬ:

Я хочу протестировать закрытые члены:

Я написал

#define private public

, но это не сработало для частных слотов в Qt

, поэтому мои намерения В любом случае я использовал что-то вроде

#define private slots: public slots:

. Я нашел другой способ тестирования слотов и, кстати, я знаю, что это уродливый взлом. Считайте следующие вопросы чисто академическими. Я думал об эффективности доступа ...

Прежде чем я задам свой вопрос, могу я , пожалуйста, попросить не слушать лекцию об оптимизации без причины. Рассмотрим следующие вопросы чисто академические.

Я думал об эффективности доступа между корневыми (т.е. часто используемыми и часто обращающимися друг к другу) классами в Java, но это относится к большинству объектно-ориентированных языков / компиляторов. Самый быстрый способ (я предполагаю) получить доступ к чему-либо на Java - это статическая последняя ссылка. Теоретически, поскольку эта ссылка доступна во время загрузки, хороший JIT-компилятор избавит от необходимости выполнять любой поиск по ссылкам для доступа к переменной и укажет любой доступ к этой переменной прямо на постоянный адрес. Возможно, из соображений безопасности это все равно так не работает, но потерпите меня ...

Скажем, я решил, что есть некоторые проблемы с порядком операций или какие-то аргументы, которые нужно передать при запуске, что означает, что я не могу статическая окончательная ссылка, даже если бы мне пришлось столкнуться с проблемой создания каждого класса другого, как это рекомендуется, чтобы классы Java имели статические окончательные ссылки друг на друга. Другая причина, по которой я мог бы не захотеть этого делать, была бы ... ну, скажем, просто, например, что я предоставлял реализации некоторых из этих классов для конкретных платформ. ; -)

Теперь у меня остается два очевидных выбора. Я могу сообщить своим классам друг о друге с помощью статической ссылки (в некотором классе системного концентратора), которая устанавливается после построения всех классов (во время которой я требую, чтобы они еще не могли получить доступ друг к другу, таким образом устраняя проблемы с порядком операций в минимум во время строительства). С другой стороны, классы могут иметь экземпляр окончательных ссылок друг на друга, Должен ли я теперь решить, что сортировка порядка операций важна или может быть возложена на человека, передающего аргументы - или, точнее говоря, предоставление конкретных реализаций этих классов для платформы, которые мы хотим ссылаться друг на друга.

Статическая переменная означает, что вам не нужно искать местоположение переменной относительно класса, к которому она принадлежит, что позволяет сэкономить одну операцию. Последняя переменная означает, что вам вообще не нужно искать значение, но оно должно принадлежать вашему классу, поэтому вы сохраняете «одну операцию». Хорошо, я знаю, что сейчас я действительно машу рукой!

Затем мне пришло в голову кое-что еще: я мог бы иметь статические конечные классы-заглушки, что-то вроде дурацкого интерфейса, в котором каждый вызов был отнесен к 'impl' который может просто удлинить заглушку. Тогда удар по производительности будет заключаться в двойном вызове функции, необходимом для запуска функций, и, возможно, я думаю, вы больше не можете объявлять свои методы окончательными. Я предположил, что, возможно, они могут быть встроены, если они были должным образом объявлены, затем сдался, поскольку я понял, что тогда мне придется подумать о том, могут ли ссылки на 'impl быть статичными, или окончательными, или ...

Итак, какой из трех окажется самым быстрым? : -)

Есть ли другие мысли по снижению накладных расходов на частый доступ или даже другие способы намекнуть на производительность JIT-компилятору?

ОБНОВЛЕНИЕ: после нескольких часов тестирования различных вещей и чтения http: // www.ibm.com/developerworks/java/library/j-jtp02225.html Я обнаружил, что большинство вещей, на которые вы обычно смотрите при настройке, например C ++ полностью выкинет окно с JIT-компилятором. Я видел, как он выполнял 30 секунд вычислений один, два раза, и при третьем (и последующих) запусках решал: «Эй, вы не читаете результат этого расчета, поэтому я не запускаю его!»

FWIW, вы можете тестировать структуры данных, и я смог разработать реализацию arrayylist, которая была более производительной для моих нужд, используя микротест. Шаблоны доступа должны были быть достаточно случайными, чтобы компилятор мог догадываться, но он все же работал над тем, как лучше реализовать обобщенный растущий массив с моим более простым и более настроенным кодом.

Что касается теста здесь, я просто не мог получить результат теста! Мой простой тест вызова функции и чтения переменной из конечной и не конечной ссылки на объект показал больше о JIT, чем о JVM ' шаблоны доступа. Невероятно, но вызов той же функции для того же объекта в разных местах метода изменяет затраченное время в ЧЕТЫРЕ раз!

Как парень в статье IBM говорится, что единственный способ проверить оптимизацию - на месте.

Спасибо всем, кто указывал мне на пути.