Здравствуйте, CreatorCray, Вы писали:
Ytz>>3. template <double> — не работает, ровно как и например template <std::string> CC>Можно пример, а то я что то не совсем понял что тут имеется в виду.
Здравствуйте, Ytz, Вы писали:
CC>>А чего именно ты этим хочешь добиться? CC>>Чтоб вызов foo<0.5>() обламывался при компиляции?
Ytz>Почему он должен обламываться?
Ну я так понял выделенное
Ytz>
Ytz>template <int Value>
Ytz>void foo()
Ytz>{
Ytz> ... // Ok
Здравствуйте, dimgel, Вы писали: D>1. Многабукаф. Нупростодоужасамногабукаф.
Как же тогда люди на коболе писали? По сравнению с коболом в яве почти нет букав.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, okman, Вы писали:
O>>В общем-то, я соглашусь почти со всем, что Вы написали, но ведь O>>проблемы от этого не исчезнут.
J>Если вы согласны почти со всем, то это значит, что вы согласны, что почти все претензии не относятся к собственно языку. J>...
Ну если так формально подходить к вопросу — тогда да, к синтаксису языка мои претензии не имеют никакого отношения.
Здравствуйте, CreatorCray, Вы писали:
O>>Куда эта дорога ведет? CC>К сохранению принципа "платишь только за то, что реально используешь". И это для С++ краеугольный камень
Не вижу связи.
В стандартную библиотеку можно впихнуть хоть тысячу контейнеров и алгоритмов, все равно в
исполняемый модуль будут включены только те, которые используются в коде программы.
O>>Не правда ли, все это гораздо приятнее читалось бы так: CC>Не, ужасно читалось бы. CC>Куда приятнее будет:
CC>
CC> CC>Вот и какой стиль надо принимать за "единственно правильный" (тм)?
Так тоже симпатично.
O>>>>Очень много платформенных "заточек" вроде #pragma, __declspec и #ifdef _X64. J>>>Вообще-то возможность заточки под платформу — это фича языка O>>Если заточек становится слишком много, значит язык не справляется со своей задачей. CC>Ну как бы нельзя внести в системный язык фичи всех потенциально поддерживаемых платформ. Они ж зачастую друг другу ортогональны.
По крайней мере, если бы эти "заточки" описывались декларативно, в каких-нибудь .platform-файлах,
которые бы потом линковались вместе с объектными файлами, синтаксис от этого только выиграл бы.
Повторю себя насчёт того, что сейчас актуально:
Хедеры и единицы трансляции вместо нормальной модульности. Часто долгая пересборка при небольших изменениях.
Совместимость целочисленных, логических и символьных типов, а в случае нулевой константы — ещё и указателей:
int main()
{
int * p1 = false, * p2 = '\0';
int i1 = true, i2 = 'X';
unsigned u = -1;
char c = 22;
}
Здравствуйте, okman, Вы писали:
O>>>Куда эта дорога ведет? CC>>К сохранению принципа "платишь только за то, что реально используешь". И это для С++ краеугольный камень O>Не вижу связи. O>В стандартную библиотеку можно впихнуть хоть тысячу контейнеров и алгоритмов, все равно в O>исполняемый модуль будут включены только те, которые используются в коде программы.
Нее. Не так.
Как уже верно заметил jazzer
с ним вместе должны идти XSLT, XPath, схемы и прочая
Это уже неслабо утяжеляет реализацию XML. Как в плане разработки стандартной библиотеки, которую пишет производитель компилятора (и к тому же тестирует под все платформы, которые поддерживает компилятор) так и в плане того, что вся эта бодяга имеет шансы влинковаться в бинарь.
O>Так тоже симпатично.
Повторюсь
Вот и какой стиль надо принимать за "единственно правильный" (тм)?
CC>>Ну как бы нельзя внести в системный язык фичи всех потенциально поддерживаемых платформ. Они ж зачастую друг другу ортогональны. O>По крайней мере, если бы эти "заточки" описывались декларативно, в каких-нибудь .platform-файлах, O>которые бы потом линковались вместе с объектными файлами, синтаксис от этого только выиграл бы.
Я не представляю себе как это сделать так, чтоб не получить путаницы больше чем уже есть.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, alpha21264, Вы писали:
A>>Здравствуйте, Слава, Вы писали:
С>>>Здравствуйте, alpha21264, Вы писали:
A>>>>А еще: A>>>>0) нельзя использовать русские буквы в именах переменных и функций
С>>>А это зачем? сделать 1С из С++ ?
A>>Ложная связка. Java по твоему 1С?
С>Разве кто-то этим пользуется?
Я не знаю, может и пользуются.
Ну так ответь на вопрос — если пользуются, значит Ява стала 1С?
Здравствуйте, CreatorCray, Вы писали:
O>>В стандартную библиотеку можно впихнуть хоть тысячу контейнеров и алгоритмов, все равно в O>>исполняемый модуль будут включены только те, которые используются в коде программы.
CC>Нее. Не так. CC>Как уже верно заметил jazzer CC>
CC>с ним вместе должны идти XSLT, XPath, схемы и прочая
CC>Это уже неслабо утяжеляет реализацию XML. Как в плане разработки стандартной библиотеки, которую пишет производитель компилятора (и к тому же тестирует под все платформы, которые поддерживает компилятор) так и в плане того, что вся эта бодяга имеет шансы влинковаться в бинарь.
Я вижу только одну причину — разработка качественной библиотеки для работы с XML сама по себе является
очень нехилой задачей, а реализация на уровне стандарта С++ и универсализации для разных компиляторов
запредельно сложнее.
По поводу того, что лишний код попадет в исполняемый модуль — сильно сомневаюсь.
Даже если "вхолостую" линковаться с .lib-файлом, ничего от него в exe или dll не остается.
O>>Так тоже симпатично. CC>Повторюсь CC>
CC>Вот и какой стиль надо принимать за "единственно правильный" (тм)?
Пусть будет один из вариантов, приведенных выше.
Я говорил вообще не о каком-то конкретном стиле, а о том, что в С++ почему-то принято в
каждой конторе заводить свой фирменный coding style, который затрагивает все и вся — от скобок до
пробела между for и скобкой. Тогда как в более "скромных" языках вроде Javascript эти
вопросы давно решили и большинство следует центральной конвенции, которая вроде бы всех устраивает.
CC>>>Ну как бы нельзя внести в системный язык фичи всех потенциально поддерживаемых платформ. Они ж зачастую друг другу ортогональны. O>>По крайней мере, если бы эти "заточки" описывались декларативно, в каких-нибудь .platform-файлах, O>>которые бы потом линковались вместе с объектными файлами, синтаксис от этого только выиграл бы.
CC>Я не представляю себе как это сделать так, чтоб не получить путаницы больше чем уже есть.
D>1. Многабукаф. Нупростодоужасамногабукаф.
Никто не заставляет, можно писать коротко
D>2. Не люблю, когда злоупотребляют аннотациями: они хуже проверяются типизатором. В жаве почти все фреймворки работают на аннотациях. Это вот отчаянное желание превратить всё на свете в POJO с аннотациями бесит. Взять тот же Spring MVC.
Никто не заставляет, вполне можно писать и без аннотаций. В простых случаях они действительно удобнее, в сложных берете какой-нибудь AbstractFormController и вперёд. D>нетривиальную валидацию параметров, как и нетривиальную обработку ошибок, хрен прикрутишь;
Да ладно.
D>отладить эту AOP-хрень практически невозможно;
Да легко.
D>IDE никаких подсказок не возможностям не даёт (базового класса нет, виртуальные методы подсмотреть негде, а аннотации я хз какие в каком случае применимы)
В STS есть поддержка аннотаций для WebMVC
D>Аналогичные претензии к Tapestry, а вот Wicket рулит.
Это в общем не к языку претензии
D>3. После знакомства с ФП стало резко не хватать методов map(), filter() и т.п. на коллекциях. http://jfunctions.sourceforge.net
Сыровато, документация только в javadoc, пока отсутствует в публичных репозиториях, но пользоваться вполне можно.
Re[27]: C#: const для переменных, pattern-matching, ...
Здравствуйте, VladD2, Вы писали:
L>>К чему все это? Я тебе специально вопрос выделил жирным. Выбор var/декларация типа — исключительно иллюстрация того, что изменение синтаксиса — не такая тривиальная задача. Дабы тема опять не съехала в сторону, повторюсь, что речь не о технической стороне дела, а о концептуальной.
VD>Да нет в этом выборе ничего особенного. Здесь опять же речь идет о клинически пугливых теоретиках и практиках.
А по-моему речь идет о истерических якобы-практиках (главный из которых работает даже не в софтвеной конторе, а в изательстве), которых приводит в бешенство просьба уточнить, какую именно практику они имеют в виду.
Будем продолжать в том же духе, или все-таки перейдем к нормальной беседе? Предлагаю второе, если не возражаешь.
VD>Потом тебе уже раз сто сказали, что в случае макросов это выбор конкретной группы людей работающих над конкретным проектом. Как из этого вытекают те ужасы на которые ты намекаешь я не понимаю.
Да я и не оспариваю это, конечно выбор и ответственность лежит исключительно на "конкретной группе людей". Так и есть.
Я ставлю под сомнние то, что человек, не занимающейся проектированием языков, в состоянии адекватно внести изменения в синтаксис существующего языка. Под "адекватностью" я тут имею в виду что внесенное изменение не будет "конфликтовать" с другими концепциями языка и не будет с течением времени выглядеть как нелогичная нелепица. Основанием для этих сомнений служит а) личный опыт написания (и развития) программ, генерирующих код, и б) многочисленные неадекватности и нелогичности, найденые тем же nikov-ом в шарпе и многими другими — в C++.
L>>Я вижу проблему в приведенном примере, я вижу на примерах nikov-а, что и в шарпе полно нелогичностей и неоднозначностей. Какие еще мне могуть понадобиться подтверждения того, что проблема реальна?
VD>Ладно. Я наблюдаю очередной приступ клинического фанатазирования с твоей стороны. Мне это уже право надоело.
Если бы такую фразу написал тебе я, то ты несмомненно посчитал бы это сливом.
Но поскольку я — не ты, то решение продолжать или нет — это твое личное решение и ты имеешь полное право прекратить ее в любой момент и это не будет расценено, ни как опровержение твоей точки зрения, ни как подтверждение моей.
Имхо, такие затяжные баталии являются свидетельством того, что спорящие стороны имеют просто разные ценности. В данном случае предмет разногласия — мощность языка vs предсказуемость оного.
VD>В примерах, Никова, кстати, очень редко появляются примеры именно синтаксических аномалий. Все они связаны с кривым дизайном C# авторы которого предпочли совместимость с С-ишными принципами прямому дизайну.
С С-шными принципы? Это с какими?
VD>Учитывая, что все эти ошибки сделаны еще в самых первых версиях я вообще не понимаю причем тут расширяемость.
Собственно мы и пришли к той точке, о которой я писал много-много постов назад. Точка называется "авторы шарпа — эээ ... допускают ошибки", а мы — нет. Эх, nikov-а на вас нет.
VD>Основная же часть этюдов Никова — это семантические этюды. С синтаксическими расширен они никак не связаны.
VD>В общем, в очередной раз жалею бессмысленно потраченное время. В прочем, возможно, что хоть не ты так может кто-то другой попытается понять вполне простые и очевидные доводы и не будет повторять за тобой бредову мантру о вреде макросов.
"Бредовая мантра о вреде макросов" существует только в твоей голове. Я уже уточнил, что именно я имел в виду, когда писал, что метапрограммирование — не нужно. Да, я изначально выбрал неудачную формулировку, признаю свою ошибку.
Здравствуйте, CreatorCray, Вы писали:
CC>>>А чего именно ты этим хочешь добиться? CC>>>Чтоб вызов foo<0.5>() обламывался при компиляции?
Ytz>>Почему он должен обламываться? CC>Ну я так понял выделенное
На всякий случай — это и так не скомпилируется. Дело в том, что int может быть константным параметром шаблона, а вот например double — нет, что на мой взгляд не логично
Здравствуйте, Ytz, Вы писали:
Ytz>На всякий случай — это и так не скомпилируется. Дело в том, что int может быть константным параметром шаблона, а вот например double — нет, что на мой взгляд не логично
А, тьфу
Я просто твою начальную фразу
3. template <double> — не работает, ровно как и например template <std::string>
воспринял как инстанциацию template <class TYPE> ...
А пример ещё больше запутал
Здравствуйте, okman, Вы писали:
O>По поводу того, что лишний код попадет в исполняемый модуль — сильно сомневаюсь. O>Даже если "вхолостую" линковаться с .lib-файлом, ничего от него в exe или dll не остается.
Ну скажем если мне не надо например валидация но где то в парсере есть вызов в каком то if который в моём случае никогда не срабатывает то весь код будет подсосан в объектник.
А делать реализацию XML например параметризуемой темплейтами во время компиляции это будет тот ещё ахтунг.
O>Я говорил вообще не о каком-то конкретном стиле, а о том, что в С++ почему-то принято в O>каждой конторе заводить свой фирменный coding style, который затрагивает все и вся — от скобок до O>пробела между for и скобкой.
По историческим причинам.
CC>>Я не представляю себе как это сделать так, чтоб не получить путаницы больше чем уже есть. O>А def-файлы ? Там, по сути, то же самое.
Def файлы вообще никак к языку не относятся. Это специфика для linker.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, alpha21264, Вы писали:
A>>А еще: A>>0) нельзя использовать русские буквы в именах переменных и функций J>Можно любые, вот цитата из стандарта (старого): J>
J>identifier:
J> nondigit
J> identifier nondigit
J> identifier digit
J>nondigit: one of
J> universal-character-name
J> _ a b c d e f g h i j k l m
J> n o p q r s t u v w x y z
J> A B C D E F G H I J K L M
J> N O P Q R S T U V W X Y Z
J>hex-quad:
J> hexadecimal-digit hexadecimal-digit hexadecimal-digit hexadecimal-digit
J>universal-character-name:
J> \u hex-quad
J> \U hex-quad hex-quad
J>
J>так что все вопросы к конкретному редактору — по старому стандарту он обязан просто превращать юникодные символы в \uXXXX в момент сохранения файла на диск (и обратно при загрузке). J>Кстати, если вызов компилятора завернуть в элементарный скрипт, который любые уникодные символы будет превращать в universal-character-name и потом звать компилятор — вообще никаких усилий от редактора не потребуется.
С ужасом представил, как это будет выглядеть при отладке.
Нельзя так пугать. Лучше бы ты транслит посоветовал.
Или английский учить, как тут многие "выучившие" советуют.
J>В новом стандарте еще проще: J>
J>identifier-nondigit:
J> nondigit
J> universal-character-name
J> other implementation-defined characters
J>
J>но universal-character-name никуда не делся, так что скрипт будет работать и с кодом, соответствующим новому стандарту.
Ну вот выйдет новый стандарт, напишут компилятор, потом подтянутся остальные тулзы. Может быть ближе к пенсии и получится.
A>>1) нельзя сделать operator[](int index1, int index2) J>это да, арность, приоритеты и прочая менять нельзя. Это, кстати, дает стабильность синтаксиса, в отличие от языков, в которых это можно. Потому что сейчас a[1,2] эквивалентно a[2], потому что оператор запятая. И это не зависит от типа а. А если разрешить такое, как у тебя, то в зависимости от типа а может быть как оператор запятая + вызов унарной версии, так и вызов бинарной версии.
Экая однако ересь.
Вы что-же батенька, хотите все функции с двумя аргументами запретить? Там же тоже в середине есть запятая.
Например strcmp( s1,s2 );
A>>2) и вообще переопределенных операторов как-то мало J>В сымсле — мало? 46 операторов (все, кроме четырёх ". .* :: ?:") — это мало? Или ты к тому, что нельзя новых наопределять? Так это палка о двух концах, так как, определяя новый оператор, его нужно каким-то образом включить в систему существующих операторов в смысле приоритета и ассоциативности — немаленькая нагрузка на компилятор, не говоря уже о возникающих неоднозначностях: a**b — это новый оператор ** или a*(*b), как сейчас? Но лучше, конечно, 5 звёздочек
Ну вот простейшая же вещь. Строки можно сравнить и по длинне и по алфавиту.
И то и другое — оператор "больше". Как предлагаете выйти из ситуации?
A>>3) нельзя return x,y ; J>
J>return boost::make_tuple(x,y);
J>
Ты бы мне еще посоветовал структуру завести. Или вернуть через выходные параметры.
Ты не видишь, насколько эта запись длиннее необходимой?
A>>4) нет безымянных функций и нельзя сделать вот так "функция( { тут какое-нибудь выражение } )" J>можно в C++0x (VC и GCC уже поддерживают)
Это как бы несколько другой язык.
A>>5) нельзя поймать исключение SegFault и продолжить работу J>оно за пределами языка, так что надо пользоваться внеязыковыми средствами, доступными в библиотеках.
Ну а почему оно "за пределами языка"? Должно быть "в пределах". (топаю ножкой)
A>>6) В STL нет контейнера "граф" J>А так же Map/Reduce, youtube video search, переводчика с японского на корейский и еще миллиона структур и алгоритмов. Библиотеки на что? Boost.Graph, например.
