OberonCore

Не прельщает даже с перегруженными операторами. Форматная строка со списком аргументов в большинстве случаев намного удобнее.

Тоже не хотим. Статическая типизация рулит.

Гм... а не поскажете, в каких языках компилятор проверяет соответствие между типами, указанными в форматных полях и типами значений, которые переданы для подстановки вместо этих полей?
Например, в Си вообще не существует понятия о типизации для параметров процедур - передавай что хочешь. В С++ типизация для параметров присутствует, однако не в случае printf и ее параметров передаваемых в списке "..."

На самом деле проверять соответствие аргументов форматам *printf современные сишные компиляторы умеют Во всяком случае такие популярные как gcc/VC. Хотя это исключительно инициатива конкретных компиляторов (разве что в каком-нибудь C99 такое поведение явно описали).



На C++ можно замутить что угодно Например, boost::format. На этапе компиляции соответствие проверять не умеет, но полностью type-safe, совместим с форматными строками *printf, позволяет использовать пользовательские типы и написан в рамках стандарта C++.

Что касается более других языков, то по моим представлениям Nemerle с его мощными compile-time механизмами вполне способен решить эту задачу.

подскажу: gcc, ключ -wformat2

2 Vlad

Ээээ, батенька, ды вы - не романтик-с !

gcc вообще интересная штука. Угадайте что он сгенерирует для

Я не знаком с gcc, поэтому попробую угадать: он сгенерирует код для вывода на стандартное устройство вывода (stdout) строки "hello world!" (без кавычек) и перевода строки, но без возврата каретки.
Угадал?

Нет, это было б нарушение семантки, то есть баг, и его бы поправили.
Просто он интересно оптимизирует:

нечто подобное было использовано в Sql (тока для экспортированных данных)

Эх, когда gcc начнет оптимизировать такую программу:
чтобы получалось решение нужной мне задачи, я снова вернусь на С или С++. А пока это все интересно, но всего лишь всякие фичи компилятора, которые сути дела не меняют.
Также, как и
- case '0'...'9',
- динамическое создание локальных массивов int n=?; int a[n],
- вложенные функции (только для C) ("будьте осторожны, когда используете goto за пределы вложенной функции" ) и т. д.
А потом, когда каждый компилятор предоставляет кучу фичей, народ говорит о переносимости C кода. И сразу вопрос: если переносимость, то зачем фичи? Если фичи, то...

А еще мне нравится замечание Страустрапа по поводу многомерных массивом: "используйте работу с многомерными массивами только в низкоуровневом коде".
Возможность, которая как воздух нужна прикладникам, математикам, численникам у нас уходит только на низкий уровень... Ну, естественно, все логично: массивов-то многомерных полноценных нет, есть костыль-култяпка...

Выдрать из контекста и истолковать как хочется - это неспортивно.

Не надо, не выдирал я из контекста
Недавно пришлось заниматься со студентами на эту тему, для освежения памяти, отвыкшей от ++, перечитывал весь соотв. раздел Страустрапа... Многомерные массивы освещены только в приложении, как "средство, использования которого без необходимости следует избегать"...

Ну, если глянуть еще пристальнее то в Си массивов вообще нет есть указатели на ячейку памяти некоторого типа и неизвестного при работе размера.

А я, вот, насыщаюсь Вандервудом и Джосаттисом (Шаблоны Си++) - выходные коту под хвост !
Похоже это чисто Си++-ная болезнь по следующей схеме: "Ура!!! Круто! Ну? ваще-то - смотреть здесь и здесь на будущие возможные неожиданности! Ещё - смотреть сноску! Но, вообще-то, - соторожнее!"
Я вот смотрю опять на главу по типам классов и умным указателям и вижу, что процесс пощёл своей дорогой! - Уже чистое искусство ради самого искусства: по идее средство прикладников не касалось, а - только писателей библиотек, но каждый раз выясняется, что для осмысленного использования прикладником предоставляемых средств в библиотеках (а не как макака!), ему столько нужно материала перерыть и ВЪЕХАТЬ в него, - что - нуегонафик!

Я вот только вчера объяснял очередному "среднестатистическому прикладнику" (без пяти минут доктору, кстати) по его коду (тоже захотел крутостью блеснуть - начал реализовывать свои теор наработки на Си++! ), почему в выражениях

cout << a << b * c << d << endl;
и
while( ! cin >> x )

у него ошибки... :о) Как гворится "эта музыка будет вечно..."

Нахрена "среднестатистическому прикладнику" (причем с ученой степенью, как я понимаю, совсем не по IT) C++? Tы бы лучше объяснил ему, что C++ ему не нужен. А если у него такая специфика, что без C++ вообще никак, то пусть ищет нормального программиста, а сам крутит свои микроскопы и не страдает фигней.



Потому что не умеет правильно переопредлять операторы? Ну так пусть оставит это дело тем, кто умеет, и не тратит свое ученое время и время других.

2 Vlad

А вот не всегда нужно, что бы программист под рукой был.
Случай языка-калькулятора, но не примитив.
Я и пытался объяснить, что для "похватных" и "пилотных" вещеё Си++ - ну никак ему не подходит. Даи Визуал Бэйсик - уже нечто "не то". Тем более, что и пример с 2+2=5 возымел эхвект! :о)
Человек в раздумьи. Его смущает неизвестность среды и языка + он мне не верит, что архитектурно (фреймвок, принципы и подходы) это уже десять лет гарантированно не менялось и в ближайщие столько же не изменится... :о)

Возможно Струструп не хотел растекаться по дереву и объяснять, что это средство, в силу всех его недостатков и ограничений востребовано на практике только в низкоуровневом коде. Впрочем если речь идет о прикладном высокоуровневом коде - то и обычные сишные массивы малоюзабельны (исключая строковые константы Для студентов же можно было дать ссылку на std::vector как пример "массива для прикладной жизни".

И вы думаете, они этим успокоятся? Как бы не так! То ли в силу природного интереса, то ли, потому, что вынуждены будут "копать" дальше (по требованиям задачи), они обязательно вынуждены будут рассматривать вопросы реализации... Со всеми вытекающими! (особенно для прикладников....... :о) )
То есть , я имею в виду, что пока будет примитив, "простое знание" о векторе удовлетворит, но! там где структуры стандартной библиотеки - низбежно "полезут" и её алгоритмы, и вот тогда - "и пошли они (прикладники) солнцем палимые"... :о)