Синтаксический сахар в C / C ++

То, как вы это сделали, мне кажется правильным, если вы вообще собираетесь это делать. Поскольку расширение макроса настолько похоже на то, что вы ожидаете [1], я считаю правильным сделать макрос похожим на syntax (), а не на обычно рекомендуемые SCARY_UPPERCASE_MACROS (), которые используется, чтобы показать, что этот код не следует обычному синтаксису, и вы должны использовать его только осторожно.

[1] Единственным недостатком является невозможность объявления переменных, что в любом случае маловероятно и может привести к ошибке в нужном месте при неправильном использовании, вместо того, чтобы делать что-то странное.

Кроме того, важно даже небольшое увеличение читабельности, поэтому возможность сказать until ( вместо while (! действительно облегчает чтение многих циклов. Если конечное условие легче рассматривать как исключительное условие (независимо от того, есть оно или нет), запись цикла таким образом облегчает чтение. Так что, хотя это всего лишь синтаксический сахар, я думаю, есть причина его рассмотреть.

Однако я не думаю, что оно того стоит. Преимущество невелико, так как большинство программистов привыкли читать if (!, а цена вполне реальна: любой, кто читает код, должен будет проверить, является ли это макросом или специальным компилятором, и делает ли он то, что они думают. И это может ввести вас в заблуждение, заставив вас думать, что вы можете делать такие вещи, как i=5 unless xxxx;. Такие небольшие улучшения, если они будут широко распространены, фрагментируют язык, поэтому часто лучше делать что-то стандартным способом и медленно внедрять улучшения.

Тем не менее, это можно сделать хорошо: все функции boost и tr1, особенно то, что сделано с шаблонами, чтобы они выглядели как расширения библиотеки, включают в себя расширение C ++ различными способами, многие из которых не приняты, поскольку они не казались стоящими это, но многие из которых получили незначительное или очень широкое распространение, потому что они внесли реальные улучшения.

Может ли кто-нибудь предложить лучшую альтернативу?

да. Не делай этого вообще. Просто используйте операторы while и if напрямую.

Когда вы программируете на C или C ++, программируйте на C или C ++. Хотя until и unless могут использоваться часто и идиоматично в некоторых языках, их нет в C или C ++.

Это напомнило мне кое-что, что я видел в чьем-то коде:

#define R return;

Кроме того, затрудняя понимание кода, вы увеличиваете расходы на обслуживание.

Я предлагаю, чтобы их лучше не использовать.

Вы не можете использовать их в стиле Ruby как

`printf("hello,world") unless(a>0);`

незаконно.

И программистам на C будет сложнее понять код. Между тем дополнительный макрос может быть проблемой.

Если вы собираетесь определять макросы, лучше всего сделать так, чтобы они выглядели действительно некрасиво. В частности, они должны быть написаны полностью заглавными буквами и иметь какой-то префикс. Это связано с тем, что здесь нет пространства имен и нет координации с системой типов или разрешением перегрузки C ++.

Так что, если бы ваш макрос назывался BIGYAN_UNNECESSARY_MACRO_UNTIL, то это было бы не совсем «за гранью».

Если вы хотите расширить C ++ новыми конструкциями циклов, рассмотрите возможность изучения лямбда-выражений в C ++ 0x, где вы могли бы разрешить:

until([&] { return finished; }, [&] 
{
    // do stuff
});

Не идеально, но лучше макросов.

Я не думаю, что ваши макросы плохи, особенно если они используются только в вашей собственной кодовой базе. Эта статья может быть вам интересна. При этом я вижу некоторые недостатки в ваших макросах, когда мы используем их в C ++.
Например, мы не можем писать как:

until (T* p = f(x)) ...
unless (T* p = f(x)) ...

с другой стороны, мы можем написать так:

while (T* p = f(x)) ...
if (T* p = f(x)) ...

Что касается unless, если мы определим его как:

#define unless(x) if (x) {} else

тогда мы можем написать unless (T* p = f(x)) .... Однако в этом случае мы не можем добавить после него предложение else.

Хороший пример синтаксического сахара (ИМХО):

struct Foo {
    void bar() {}
};
typedef std::vector<Foo*> FooVector;
typedef boost::ptr_vector<Foo> FooPtrVector;

FooVector v1;
for (FooVector::iterator it = v1.begin(); it != v1.end(); ++it)
    (*it)->bar(); // ugly

FooPtrVector v2;
for (FooPtrVector::iterator it = v2.begin(); it != v2.end(); ++it)
    it->bar(); // nice

Посмотрите, как делается boost foreach.

Заголовок определяет BOOST_FOREACH (уродливый макрос с префиксом). Ты сможешь

#define foreach BOOST_FOREACH

в ваших файлах .cpp, чтобы иметь более чистый код. Однако вам не следует делать это в ваших файлах .h и вместо этого использовать уродливый BOOST_FOREACH.

Теперь, вот набор макросов «в стиле функционального программирования» для «удобных» выражений IF THEN ELSE (потому что?: Некрасиво):

#define IF(x) (x) ?
#define ELSE :

в настоящее время

int x = IF(y==0) 1
        ELSE IF(y<0) 2*y
        ELSE 3*y;

обессахаривается в:

int x = (y==0) ? 1 : (y<0) ? 2*y : 3*y;

Как говорили люди, добавление этого слова на самом деле не дает полезного синтаксического сахара, потому что стоимость чтения (или if (!) Мала, к этому привыкли все разработчики C, и, используя такой макрос, вы напугаете большую часть Разработчики на C. Кроме того, делать язык похожим на другой - не лучшая идея.

НО, синтаксический сахар имеет значение. Как уже говорилось, в C ++ boost добавляет много синтаксического сахара с помощью шаблонов, а stl также предоставляет сахар Somme (например, std::make_pair(a, b) является синтаксическим сахаром для std::pair<decltype(a), decltype(b)>(a, b).

По мере улучшения языка добавляются как функциональные возможности, так и синтаксический сахар, чтобы улучшить читаемость, удобство записи и эффективность разработчиков. Например, в спецификации C ++ 11 было добавлено «for (elements in datastructure)» (см. Ниже), а также ключевое слово «auto», которое позволяет вывод типов в течение недели (я говорю «слабый», потому что вам нужно ввести много типов во многих местах, где тип на самом деле «очевиден» и избыточен).

Кроме того, в haskell использование монад без нотации do (синтаксический сахар) было бы настоящей проблемой, и никто бы не стал их использовать 1.

Пример без синтаксического сахара:

//C++ < 11
std::vector<int> v;
v.push_back(3);
v.push_back(7);
v.push_back(9);
v.push_back(12);
for (std::vector<int>::iterator it = v.begin();
     it != v.end();
     it++)
{
    std::cout << *it << std::endl;
}

И с синтаксическим сахаром:

//C++ >= 11
std::vector<int> v {3, 7, 9, 12};

for (auto elm : v)
{
    std::cout << elm << std::endl;
}

Немного читабельнее, не так ли?

Пример haskell для монады ввода-вывода (из HaskellWiki):

f :: IO String
f =
  ask "What's your name ?" >>= \name ->
  putStrLn "Write something." >>= \_ ->
  getLine >>= \string ->
  putStrLn ("Hello " ++ name ++ " you wrote " ++ string) >>= \_ ->
  return name

g :: IO String    
g = do
  name <- ask "What's your name ?"
  putStrLn "Write something."
  string <- getLine
  putStrLn ("Hello " ++ name ++ " you wrote " ++ string)
  return name

Вот ссылка на ideone: http://ideone.com/v9BqiZ

1: на самом деле язык более гибкий, чем C ++, и позволяет создавать операторы (например, & ^, +.,: + :, ...), так что мы могли представить, что кто-то снова быстро вводит синтаксический сахар :).

Что ж, вы могли бы это сделать, но убедитесь, что этого нет в исходном файле. Я рекомендую использовать подход CoffeeScript к JavaScript без генерации оптимизации.

В общем, вы должны писать на своем языке, но экспортировать, передавать и транслировать код, как если бы вы написали его на C с максимальной совместимостью.

Попробуйте заглянуть в awk и сделать так, чтобы он перекомпилировал все файлы с окончанием .cugar при сохранении или чем-то подобным. :)

Удачи.