Здравствуйте, x-code, Вы писали:
XC>Ужасная система #include и препоцессора, отсутствие нормальной модульной системы
А яблоня лучше электрического фонаря, потому что дает яблоки.
XC>Отсутствие вложенных блочных комментариев
Яблоня растет сама, а фонарь нужно сделать, вкопать, подвести провода и электрический ток.
XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
Яблоня не ломается.
XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
Яблоня каждую осень сбрасывает листья, а весной цветет. Красиво !
XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
На фонарь нельзя залезть — нет веток и может убить током.
XC>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
Фонарь не укроет в дождливый день...
XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
...и не защитит от солнца.
XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
Никто не лазает в чужой огород тырить яблоки с фонарей. А с яблонь — да.
XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
Яблони бывают разных видов — антоновка, например. А фонари почти везде одинаковые.
XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые
У яблонь не перегорает и не разбивается лампочка.
XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
Яблони не ставят на тротуарах, поэтому в них почти никогда не врезаются автомобили.
XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
В темное время суток под яблоней можно справить нужду, а под фонарем — нет, потому что заметно.
XC>Отсутствие опциональной возможности структуной типизации
Если яблоня мешает или перестала давать яблоки, ее можно спилить, и тогда на ее месте
будет удобный пенек, на котором можно сидеть. Фонарь спилить вообще нельзя, за попытки что-то с ним
сделать могут влепить крупный штраф.
XC>Оператор :: вместо точки (некрасиво)
Яблоня более красива, чем фонарь.
XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)
Когда нечем топить печь, яблоню можно спилить и нарубить дров.
У фонаря такой фичи нет.
XC>При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)
Многие фонари светят почему-то не белым, а каким-то желтым или фиолетовым светом. Я бы сделал лучше.
XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)
С яблони можно сорвать ветку и отбиться ею от напавшей собаки или хулиганов.
Проектировщики фонаря такой возможности в нем не предусмотрели.
XC>Отсутствие встроенной параллельности и каналов (как в Go)
Если поставить рядом две яблони, яблок будет больше.
А если два фонаря — света останется столько же.
XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
Если выброситься из окна и упасть в листву яблони, можно отделаться легким испугом.
Про фонарь такого не скажешь.
XC>Да еще много чего, сразу все и не вспомнить...
У фонаря еще много-много недостатков, на самом-то деле...
Здравствуйте, Философ, Вы писали:
XC>>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так) LVV>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм. Ф>Это хорошая демонстрация корявости синтаксиса. Ф>Если ЦПП позиционируется как язык более высокого уровня, то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy).
C++ позиционируется — в нормальном варианте — не как язык высокого уровня, а как многоуровневый язык. А что такое Ваше "язык более высокого уровня", известно только Вам. Насколько более высокого? На миллиметр, километр, 3 слоя или ровно на одну морковку?
Ф>По какой-то странной причине от специалиста по C не требуют знаний асма, а вот с ЦПП — наоборот.
Это где такие странные требователи? Сколько я видел, требовался или одинаковый уровень знаний "асма" от специалистов по C и C++, или для C требовался более высокий уровень (а в C++ выносились уже более высокоуровневые аспекты реализации).
Ф>Солидная часть вопросов на собеседованиях по ЦПП по сути являются вопросами по C, о чем это говорит?
Вполне возможно. Но я пока что вижу несколько обратную тенденцию: проекты, которые требуют низкоуровневость в отдельных деталях реализации, но высокоуровневость в концепциях, всё больше пишутся на C++, хотя раньше их насильно загоняли в рамки C. Текущий процесс (последние лет 10) можно охарактеризовать тем, что чисто прикладной софт мигрирует с C++ на языки управляемых сред (Java, C#, Python, ещё пару десятков кандидатов), а системный заметно расширяется в сторону C++.
Те же атомарные операции в C++ — хороший пример такого расползания C++ "вниз".
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.
И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.
*Ушел за колой и попкорном в ожидании ответа хотя бы на это
А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.
Здравствуйте, netch80, Вы писали: N>Здравствуйте, Философ, Вы писали: Ф>Здравствуйте, LaptevVV, Вы писали:
LVV>>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня
N>А что такое Ваше "язык более высокого уровня", известно только Вам. Насколько более высокого? На миллиметр, километр, 3 слоя или ровно на одну морковку?
адресатом ошибся
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, jazzer, Вы писали:
N>>>>В принципе согласен. Более того, система namespace неудобна. N>>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W. J>>>чем не устраивает J>>>
J>>>namespace W = X::Y::Z;
J>>>
J>>> N>>Это давно появилось? Я такого ещё не видел. J>Всегда было, см. 7.3.2 [namespace.alias] в С++98.
Что "всегда", не согласен, в первых версиях не было, а потом я с C++ настолько плотно не общался. Но идея ясна. И это не совсем то, что надо, хотя тоже помогает.
N>>Оно действует на полные символы или только на пространства? J>Я не очень понял, в чем вопрос.
Это алиасы только для пространств. А я хотел для одного имени.
Чтобы, например, я мог функцию X::Y::Z::W назвать как ZW и вызывать её по этому имени.
Это крайне полезно для ситуаций, когда удобно принять 2 разных пространства имён в основне пространство, чтобы не требовалось их уточнять на каждом шагу, но при этом одно из имён там конфликтует (есть в обоих). Тогда только оно алиасится, а остальные применяются напрямую.
Через алиас для пространства это немного удобнее, но не до конца.
Или есть случаи, когда имя в пространстве само по себе безумно длинное, а удобно назвать его короче, или просто переименовать в пределах данного модуля в соответствии с более подходящим смыслом. Такое данным методом вообще не решается.
Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, netch80, Вы писали: N>>Здравствуйте, Философ, Вы писали: Ф>>Здравствуйте, LaptevVV, Вы писали:
LVV>>>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня
N>>А что такое Ваше "язык более высокого уровня", известно только Вам. Насколько более высокого? На миллиметр, километр, 3 слоя или ровно на одну морковку?
Ф>адресатом ошибся
Нет, не ошибся. Фраза "Если ЦПП позиционируется как язык более высокого уровня, то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy)." — Ваша, а не Лаптева.
Лаптева я спрошу отдельно.
Здравствуйте, LaptevVV, Вы писали:
XC>>Отсутствие вложенных блочных комментариев LVV>Это мелочь
Из мелочей состоит все. И красота языка программирования именно в мелочах. Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).
XC>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так) LVV>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм. XC>>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно) LVV>Зачем?
Для различных хакерских целей возможно и понадобится. Или для целей защиты программ от взлома.
XC>>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3}); LVV>Если бы массивы были полноценные объекты — это было бы самое то!
Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.
XC>>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока LVV>Это мелочь. Особенно ghyb наличии goto/ Если goto убрать, то да.
goto тоже нужно оставить, это уникальный оператор безусловного перехода, и в некоторых особых случаях заменой ему могут быть только ассемблерные вставки. Уберем — и получим очередную джаву, на которой ничего кроме бизнес-бухгалтерии и не напишешь.
XC>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this LVV>Сильно напрягает?
Если возможность может быть, она ДОЛЖНА быть.
XC>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT LVV>А где такое еще есть?
Ну вот в ObjC и QT есть.
XC>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы) LVV>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
XC>>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые LVV> XC>>Отсутствие замыканий, простого объявления функциональных типов (int=>int) LVV>А надо?
Код должен быть простым. Если я хочу объявить аргумент "функцию, принимающую на вход int и возвращающую int", я хочу сделать это максимально простым и естественным способом: "int=>inf f" и передавать туда что угодно — метод класса, глобальную функцию, лямбду, функтор с перегруженным operator() и т.д. Это должно работать без шаблонов, если я хочу без шаблонов.
XC>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую LVV>Напрямую — это как?
После многих вариантов я остановился на таком варианте синтаксиса функций, ИМХО самый оптимальный из всех возможных:
def Func(int a, b, c) int x, y
{
x = a*b + c;
y = a/b - c;
}
// ну и вызов, какие-то две переменные объявленные где-то, объединяем их в кортеж и принимаем результат функции
(i, j) = Func(100,200,300);
Здравствуйте, Mamut, Вы писали:
S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.
M>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну.
Гм, напомни ка...
M>А так: C++ можно не любить хотя бы за отсутсвие вменяемых строк. Хотя твой мозг отказывается понимать, что строки — это не последовательность char'ов, это так.
std::string чем невменяемо?
Здравствуйте, Andrey.V.Lobanov, Вы писали:
S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? AVL>слабая маркетинговая составляющая
Каким боком маркетинг относится к языку программирования?
Здравствуйте, denisko, Вы писали:
D>Здравствуйте, Sheridan, Вы писали:
S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? D>учи дальше плюсы.
Чем дальше вникаю тем больше нравится.
S>>Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. D>Это к плюсам вообще не имеет отношения.
Абсолютно верно, это имеет отношение ко всему вообще. И к ц++ в частности.
S>>Зато более шустрый софт получается. D>По сравнению с чем?
Ну например по сравнению с земноводными.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, jazzer, Вы писали:
N>>>>>В принципе согласен. Более того, система namespace неудобна. N>>>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W. J>>>>чем не устраивает J>>>>
J>>>>namespace W = X::Y::Z;
J>>>>
J>>>> N>>>Это давно появилось? Я такого ещё не видел. J>>Всегда было, см. 7.3.2 [namespace.alias] в С++98.
N>Что "всегда", не согласен, в первых версиях не было, а потом я с C++ настолько плотно не общался. Но идея ясна. И это не совсем то, что надо, хотя тоже помогает.
В каких таких "первых" версиях? Cfront?
В стандарте 98-го года это было, а в достандартном ARM пространств имен не было вообще
N>>>Оно действует на полные символы или только на пространства? J>>Я не очень понял, в чем вопрос.
N>Это алиасы только для пространств. А я хотел для одного имени. N>Чтобы, например, я мог функцию X::Y::Z::W назвать как ZW и вызывать её по этому имени. N>Это крайне полезно для ситуаций, когда удобно принять 2 разных пространства имён в основне пространство, чтобы не требовалось их уточнять на каждом шагу, но при этом одно из имён там конфликтует (есть в обоих). Тогда только оно алиасится, а остальные применяются напрямую. N>Через алиас для пространства это немного удобнее, но не до конца. N>Или есть случаи, когда имя в пространстве само по себе безумно длинное, а удобно назвать его короче, или просто переименовать в пределах данного модуля в соответствии с более подходящим смыслом. Такое данным методом вообще не решается.
Ну так это ты плачешь об общей проблеме переименования (или даже о еще более общей проблеме выделения имени в первоклассную сущность), пространства имен тут ни при чем, эта же проблема у тебя будет и без них.
Действительно, общего решения этой проблемы нет.
Для частных случаев есть частные решения:
— Пространства имен: приведенный выше [namespace.alias]
— Типы: typedef
— Переменные: ссылки
— Шаблоны: алиасы шаблонов [temp.alias] (C++11)
— Функции: общего решения нет из-за наличия перегрузки, надо либо через указатели на функции, либо через библиотечные решения типа std::function/std::bind (C++11/ищщые)
Здравствуйте, Sheridan, Вы писали:
S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? AVL>>слабая маркетинговая составляющая S>Каким боком маркетинг относится к языку программирования?
да напрямую. ц++ старый, следовательно немодный/беспонтовый/ненужный и т.д.
массовым погромистам гораздо проще развешивать лапшу прикрываясь всякими С# 100500 / мета- / фукнциональное программирование / лямбды / монады / linq / макросы / прочая фигня. а да, виртуальные машины забыл, тоже модная тема.
Здравствуйте, x-code, Вы писали:
XC>Здравствуйте, LaptevVV, Вы писали:
XC>>>Отсутствие вложенных блочных комментариев LVV>>Это мелочь XC>Из мелочей состоит все. И красота языка программирования именно в мелочах. Я кстати придумал третий совершенно новый и очень удобный вид комментариев (кроме блочных и однострочных).
Покажь! Мы в свой язык и среду добавим — со ссылкой на автора.
XC>>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так) LVV>>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм. XC>>>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно) LVV>>Зачем? XC>Для различных хакерских целей возможно и понадобится. Или для целей защиты программ от взлома.
Ассемблерные вставки спасут отца русской демократии XC>>>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3}); LVV>>Если бы массивы были полноценные объекты — это было бы самое то! XC>Все должно быть полноценными объектами, и числа, и строки. То есть должны быть вызовы вида 10.ToStr(), "Hello".ToUpper(), но при этом эти "объекты" должны оставаться простыми сущностями.
Я так понимаю, что настал момент разработки волны языков следующего уровня (после паскаля и С) XC>>>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока LVV>>Это мелочь. Особенно при наличии goto. Если goto убрать, то да. XC>goto тоже нужно оставить, это уникальный оператор безусловного перехода, и в некоторых особых случаях заменой ему могут быть только ассемблерные вставки. Уберем — и получим очередную джаву, на которой ничего кроме бизнес-бухгалтерии и не напишешь.
В нашем языке вообще нет меток — никаких. И никаких операторов перехода. Только структурные. XC>>>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this LVV>>Сильно напрягает? XC>Если возможность может быть, она ДОЛЖНА быть.
Не согласен. Тут чувство меры разработчика большую рояль играет.
Иначе вместо языка получим большую кучу сами знаете чего.
Страуструп, кстати, в С++ играет роль цензора... XC>>>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT LVV>>А где такое еще есть? XC>Ну вот в ObjC и QT есть.
Сигналы со слотами мне нравятся — это как-то сильно понятно... Даже новичкам в программировании... XC>>>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы) LVV>>ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности. XC>Да пусть у меня всего 4 метода в классе, но я хочу разделить их в две группы, что не имею права?
А два класса написать с общим абстрактным предком — не? XC>>>Отсутствие замыканий, простого объявления функциональных типов (int=>int) LVV>>А надо? XC>Код должен быть простым. Если я хочу объявить аргумент "функцию, принимающую на вход int и возвращающую int", я хочу сделать это максимально простым и естественным способом: "int=>inf f" и передавать туда что угодно — метод класса, глобальную функцию, лямбду, функтор с перегруженным operator() и т.д. Это должно работать без шаблонов, если я хочу без шаблонов.
Вот насчет "передавать что угодно" я сильно против. Зачем тогда тип указывать? Пусть принимает any и возвращает any... XC>>>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую LVV>>Напрямую — это как? XC>После многих вариантов я остановился на таком варианте синтаксиса функций, ИМХО самый оптимальный из всех возможных: XC>
def Func(int a, b, c) int x, y
XC>{
XC> x = a*b + c;
XC> y = a/b - c;
XC>}
XC>// ну и вызов, какие-то две переменные объявленные где-то, объединяем их в кортеж и принимаем результат функции
XC>(i, j) = Func(100,200,300);
Это — хорошо...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.
M>>И при этом ты поносишь браузеры и IDE, которые на этом самом С++ написаны. Нуну. S>Гм, напомни ка...
S>>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? AVL>>>слабая маркетинговая составляющая S>>Каким боком маркетинг относится к языку программирования? AVL>да напрямую. ц++ старый, следовательно немодный/беспонтовый/ненужный и т.д. AVL>массовым погромистам гораздо проще развешивать лапшу прикрываясь всякими С# 100500 / мета- / фукнциональное программирование / лямбды / монады / linq / макросы / прочая фигня. а да, виртуальные машины забыл, тоже модная тема.
Выделенное — не лапша, а очень удобные инструменты. Которые — ВНЕЗАПНО — тоже появляются в С++
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Andrey.V.Lobanov, Вы писали:
S>>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? AVL>>слабая маркетинговая составляющая S>Каким боком маркетинг относится к языку программирования?
Гы. Ты считаешь, у жабы и шарпа был бы хоть один процент их нынешнего успеха, если бы за ними не стояли сан и мелкософт?
Вон Немерле — хороший язык, и где он? А если мелкософт его попиарит в стиле "больше шарпа не будет, следующий шарп — это Немерле" — угадай, насколько вырастет его доля через год-два, и на какой строчке он будет в каком-нть ТИОБЕ.
