Сегодня на Тимусе стало доступно сразу несколько новых компиляторов:
- Go 1.0.3
- VB.NET 2010
- Python 2.7
- Python 3.3
- Ruby 1.9.3
- Haskell 7.6.1
Справка по ним еще не дописана. Для справки нам нужны самые простые решения задач 1000. A+B Problem и 1001. Обратный корень и самые эффективные решения задачи 1001. Обратный корень. Если вы пишете на этих языках и хотите помочь Тимусу, то оставляйте свои варианты решений в комментариях к этому посту.
UPD. По многочисленным просьбам добавил еще и MinGW gcc 4.7.2. Опции компилятора такие же как на Codeforces.
UPD 2. Какие вы знаете отличия MinGW g++ от Visual C++? Было бы неплохо дополнить нашу справку.
Планируется ли появление GNU C++? Не совместимости с Visual Studio раздражают сильно. Я верю что его поддержать не сильно сложнее, чем все выше перечисленное.
А какую его реализацию под Windows вы бы предпочли?
Ну я пользуюсь MinGW. Других у людей не встречал, хотя наверное они существуют. Тут в частности тоже он используется.
Добавил MinGW gcc 4.7.2
А можно ли тогда заодно добавить и GCC в режиме C++11? Ничего делать не надо, просто скопировать строку запуска для g++ и добавить к ней
-std=c++11
или-std=gnu++11
.Добавил для gcc
-std=c11
и для g++-std=c++11
.c++11 и просто c++ надо делать разными языками, т.к. они не совместимы друг с другом.
Например, вывод double в c++ — printf("%lf", x), а в c++11 — printf("%f", x).
Возможно, есть ещё существенные отличия, но по-моему этого уже достаточно, чтобы сделать возможность выбрать, на каком языке написана программа.
UPD: хотя, под убунтой вроде работает и "%f" и "%lf". Видимо, это специфика MinGW под Windows.
Нет, это неверно. Во всех версиях как C, так и C++ вывод
double
вprintf()
осуществляется через%f
. Да, это не совпадает со спецификатором дляdouble
вscanf()
.Да, действительно надо выводить double через "%f".
Но почему-то до c++0x везде "%lf" тоже работал.
Спасибо за информацию. Буду настраивать два отдельных языка.
Кто нибудь покажите пожалуйста как осуществить ввод данных на Python 3.3 в задаче 1001
как-то так:
inp = reversed(sys.stdin.read().split())
Круто! А на поддержку scala можно надеяться?
Да, можно
Думаю стоит добавить это в справку о C++.
Про отличия MinGW от Visual.
Самое бесящее меня отличие, это то что MinGW не понимает подряд идущие угловые скобки, типа как:
постоянно надо пробелы вставлять. В студии с этим все ок.
И между прочим, в отличии от студии он делает это в соответствии со стандартом. Если
-std=c++0x
, то опять таки, в соответствии со стандартом не ругается.Запустил на Тимусе
Выход:
Видимо начиная с какой-то версии g++ тоже научился обрабатывать оба варианта. Правда на %lld все равно кидает warning, что "А я не знаю что это такое".
Кстати, На КФе такой же вывод, несмотря на предупреждение
Не уверен что на всех серверах так, но тем не менее спасибо за коммент.
А вот, если на разных серверах одинаковый код выполняется по-разному, эт очень плохо
i+= ++i + ++i;
убедил, бывает UB.
Однако, судя по всему, в c++ 11,
lld
уже должен быть по стандарту.draft 3242: Table 86, § 22.4.2.1.2
Обратный корень, простое решение, Haskell:
Обратный корень, эффективное решение, Haskell: http://hpaste.org/82623 (по неизвестным причинам парсер CF слетает на этом коде).
Надеюсь, вы не против того, что я взял ваш код для раздела справки.
Я написал дополненную версию раздела справки:
http://pastehtml.com/view/ctltfs3nv.mrk (html)
http://pastebin.com/Jjw0NhvN (markdown)
Код упростил и ускорил в два раза.
A+B Problem, Haskell:
В MinGW и Visual C++ некоторые вещи реализованы по-разному. Был случай: я решал задачу С отсюда. Послал по привычке в G++ -> получил ТЛ. Долго сидел и не мог понять почему (решение вроде бы очевидное). Потом (не помню почему) послал этот код под вижаком и получил АС. Через 10 минут я написал в блог вопрос, почему, вроде бы тормозной Visual C++, сработал быстрее чем G++? Но, увы, меня потролили, заминусовали, а ответ так и не дали.
Почему-то не нашел такого комментария:
Спасибо!
GCC теперь представлен в четырех вариантах:
Изменилось поведение тестовой программы:
Выход на GCC:
Выход на GCC C++11: