Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается.
Так все же?
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>Так все же?
Шеридан, а ты какого размера проект на С++ делал?
А то какой-то разговор о вкусе устриц с тем кто их не пробовал получается.
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>Так все же?
Ужасная система #include и препоцессора, отсутствие нормальной модульной системы
Отсутствие вложенных блочных комментариев
Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые
Отсутствие замыканий, простого объявления функциональных типов (int=>int)
Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
Отсутствие опциональной возможности структуной типизации
Оператор :: вместо точки (некрасиво)
Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)
При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)
Отсутствие полноценной рефлексии и атрибутов (как в C#)
Отсутствие встроенной параллельности и каналов (как в Go)
Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Шеридан, а ты какого размера проект на С++ делал?
S>Больше размер проекта — сложнее ловить баги, согласен. И чем больше — тем сложнее. S>При чем тут ц++?
Действительно не при чем. Вопрос должен быть такой: какого размера проекты ты делал на С++ и не не-С++ чтобы сам мог понять разницу?
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>Так все же?
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>Так все же?
да
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>Так все же?
Рассуждения админа, который вручную делает new/delete, пишет только сам и помнит весь проект, о С++.
Взял попкорн.
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?
учи дальше плюсы. S>Указатели? Да фигня это, на пару граблей наступить и рефлекс появится.
Это к плюсам вообще не имеет отношения. S>Зато более шустрый софт получается.
По сравнению с чем?
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>Так все же?
Здравствуйте, x-code, Вы писали:
S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>>Так все же? XC>Ужасная система #include и препоцессора,
Для своих задач препроцессор вполне адекватен. С другой стороны, ничто не мешает при необходимости сделать над ним что-то своё. Например, на m4, не к ночи будь сказано (но всё равно для мелких задач начинают выбор с него) или на любом другом макропроцессоре, какой понравится.
Qt использует moc фактически как препроцессор. При наличии нормально управляемой автоматизированной системы сборки проекта (которую в общем случае сделать в Unix в разы легче, чем в конкурентах) это совершенно перестаёт быть проблемой.
XC> отсутствие нормальной модульной системы
Если речь про схему в стиле Вирта (тут interface, а тут implementation), то несложно заметить, что почему-то она не прижилась в промышленности и не была принята ни в одном языке, начатом "с нуля", заведомо позже массового распространения Паскаля. Например, она не была принята ни в Java ни в C#. Зато подход с заголовочными описаниями распространяется практически на все языки. Я думаю, у "нормальной модульной системы" всё-таки есть какой-то фатальный недостаток.
XC>Отсутствие вложенных блочных комментариев
Блочных — это потоковых или блоками целых строк? Первое — сомнительное удовольствие, потому что чревато ошибками при комментировании, а для второго #if 0 ... #endif работает достаточно неплохо.
Я бы ещё как-то понял вариант вложения с двумя разными ограничителями комментариев, один из которых рекомендуется для собственно многострочных комменатриев, а второй — для блочного выключения кода. Но если блочно выключается именно код, то тот же #if 0 достаточен (и сам он гарантированно вкладывается с достаточным для практически значимых случаев уровнем).
XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
Здесь в принципе согласен, но поскольку это наследие ранних форм языка C, то несогласным с этим лучше потребовать предупреждения компилятора о плохом стиле.
XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
sizeof() функции не должно быть, потому что эта операция в принципе некорректна. Функция может быть разорвана на несколько частей. Точка входа не обязательно находится в начале функции (типично в случае оптимизации при наличии цикла в самом начале). Функция может использовать дополнительные поля констант, которые размещаются на фиксированном смещении от её тела (этот стиль рекомендуется для нескольких архитектур, таких, как x86-64 (адресация от %rip), mips, arm, s390), и они фактически являются тоже элементами функции. Хвосты кода или поля констант нескольких функций могут быть объединены. Чего именно размер в этом случае будем брать?
XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
Константный массив лечит эту проблему.
XC>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
С этим я согласен — фишка была бы очень полезной.
XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
Что такое методы-расширения я не понял.
Вызов метода как статического — а зачем? Если он невиртуальный, то имя класса известно, а если виртуальный, то квалификатора const достаточно, чтобы не влиять на текущий объект. Конечно, в чём-то было бы удобнее показать, что метод в принципе не использует данных реального объекта, кроме VMT, но всё равно реальный объект нужен ради той же VMT со ссылкой на метод.
XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
Не вижу, почему это недостаток. Такие системы сообщений весьма специфичны для задачи и общая реализация на все случаи не имеет смысла, а для конкретной — есть библиотеки. Тот же Objective C неплох, но фиксация на одном стиле уже заведомо приводит к потере производительности.
XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
В принципе согласен. Более того, система namespace неудобна.
Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были),
Суровой необходимости не вижу, если не считать те же замыкания.
XC> а лямбды в C++11 на редкость кривые XC>Отсутствие замыканий,
Вот для замыканий неплохо бы было увидеть библиотеку в стиле boost, но для C.
Чтобы умела хотя бы для основных платформ генерировать замыкания.
Glib не предлагать — может, функционально и неплоха, но от её стиля меня тошнит, и задачу сделать замыкание, видимое просто как указатель на функцию, она всё равно не решает.
XC> простого объявления функциональных типов (int=>int)
Ну это уже Вы сурово разогнались.
XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
Да, было бы неплохо.
XC>Отсутствие опциональной возможности структуной типизации
?
XC>Оператор :: вместо точки (некрасиво)
Согласен, но непринципиально.
XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)
+100.
XC>При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше) XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)
Это очень дорого и смысл сомнителен.
XC>Отсутствие встроенной параллельности и каналов (как в Go)
Это возлагается на библиотеки.
XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
Да, было бы неплохо.
XC>Да еще много чего, сразу все и не вспомнить...
Здравствуйте, x-code, Вы писали:
S>>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++? Указатели? Да фигня это, на пару граблей наступить и рефлекс появится. Зато более шустрый софт получается. S>>Так все же?
XC>Ужасная система #include и препоцессора, отсутствие нормальной модульной системы
Абсолютно согласен! XC>Отсутствие вложенных блочных комментариев
Это мелочь XC>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так)
ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм. XC>Отсутствие низкоуровневых возможностей: sizeof( ) от функции и блока кода, goto на переменные метки (в gcc есть, но это нестандартно)
Зачем? XC>Невозможность передачи массивов в фигурных скобках "как есть" в функции Foo({1,2,3});
Если бы массивы были полноценные объекты — это было бы самое то! XC>Отсутствие именованных блоков кода, соответственно невозможность сделать break и continue на именованный блок/из блока
Это мелочь. Особенно ghyb наличии goto/ Если goto убрать, то да. XC>Отсутствие методов-расширений, отсутствие возможности обращаться к методу класса как к статическому с явной (ручной) передачей this
Сильно напрягает? XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
А где такое еще есть? XC>Невозможность создания namespace внутри класса (вспомните хотя-бы "главные оконные классы" разных библиотек — CWnd, QWidget... сотни методов, там разделение не помешало бы)
ИМХО сотни методов — это проблема реализации. И следствие отсутствия нормальной модульности.
Но вообще да, не помешало бы сделать пространство имен возможным на любом уровне, хоть в функциях. XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
А надо? XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
Напрямую — это как?
В новом стандарте разве нет таплов в STL? XC>Отсутствие опциональной возможности структуной типизации XC>Оператор :: вместо точки (некрасиво)
Точка — локально, 4 точки — глобально? XC>Ужасно громоздкая система шаблонов (каждый раз писать template), и тенденция использования шаблонов не по назеначению (метапрограммирование на них)
Это — да-да-да!!!! XC>При этом отсутсивие полноценной системы метапрограммирования (типа как в Nemerle, хотя я бы сделал еще лучше)
Полезная весчь — метапрограммирование. XC>Отсутствие полноценной рефлексии и атрибутов (как в C#)
Согласен. XC>Отсутствие встроенной параллельности и каналов (как в Go)
Удивляет, что до сих пор не реализовали. Хоря в стандарт новый включили. XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
Я как-то обхожусь. Но в некоторых реализациях С++ бывает XC>Да еще много чего, сразу все и не вспомнить...
Короче, хотелось бы всего...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Тут уже ответили в основном, так что фрагментарно:
XC>Отсутствие системы сообщений как в ObjectiveC, встроенной системы сигналов и слотов как в QT
Boost.Signal
XC>Отсутсвие вложенных функций (даже в турбо паскале вроде были), а лямбды в C++11 на редкость кривые
в чем кривость лямбд по сравнению с локальными функциями?
XC>Отсутствие замыканий, простого объявления функциональных типов (int=>int)
std::function<int(int)>
XC>Отсутствие кортежей, групповых операций над кортежами, невозможность вернуть из функции несколько значений напрямую
std::tuple, auto, decltype
XC>Отсутствие опциональной возможности структуной типизации
Boost.MPL
XC>Отсутствие полноценной рефлексии и атрибутов (как в C#) XC>Отсутствие встроенной параллельности и каналов (как в Go) XC>Отсутствие свойств (properties) как в C# (хотя и в C# можно еще кое-что улучшить)
XC>Да еще много чего, сразу все и не вспомнить...
Давай подскажу: отсутствие монад как в Хаскеле, отсутствие зависимых типов как в Агда-2, отсутствие eval как в Перле, отсутствие значимых отступов как в Питоне... ну и далее по списку
Здравствуйте, netch80, Вы писали:
N>В принципе согласен. Более того, система namespace неудобна. N>Постоянно хочется решений в стиле питоновского import X.Y.Z as W.
чем не устраивает
Здравствуйте, jazzer, Вы писали:
XC>>Да еще много чего, сразу все и не вспомнить... J>Давай подскажу: отсутствие монад как в Хаскеле, отсутствие зависимых типов как в Агда-2, отсутствие eval как в Перле, отсутствие значимых отступов как в Питоне... ну и далее по списку
Нет, значимые отступы как в Питоне я не хочу. Как не хочу и жесткий стиль расстановки фигурных скобок, как в Go и Rust (когда открывающая фигурная скобка обязана быть на той же строке что и оператор)
С зависимыми типами и монадами еще не разобрался, как разберусь — решу надо или нет Может подскажешь — что могут дать монады в императивном языке программирования типа С++ или C# ?
eval сделать на компилируемом языке невозможно, но надо подумать о максимально бесшовной интеграции языков типа javascript — в смысле, что для этого нужно ввести в компилируемый язык. Возможно, синтаксис языковых вставок с возможностью подключения верификаторов (ну типа "asm", но для любого скриптового языка, подключенного неким способом в проект).
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, netch80, Вы писали:
N>>В принципе согласен. Более того, система namespace неудобна. N>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W. J>чем не устраивает J>
J>namespace W = X::Y::Z;
J>
J>
Это давно появилось? Я такого ещё не видел. Оно действует на полные символы или только на пространства?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, jazzer, Вы писали:
J>>Здравствуйте, netch80, Вы писали:
N>>>В принципе согласен. Более того, система namespace неудобна. N>>>Постоянно хочется решений в стиле питоновского import X.Y.Z as W. J>>чем не устраивает J>>
J>>namespace W = X::Y::Z;
J>>
J>>
N>Это давно появилось? Я такого ещё не видел.
Всегда было, см. 7.3.2 [namespace.alias] в С++98.
N>Оно действует на полные символы или только на пространства?
Я не очень понял, в чем вопрос.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, x-code, Вы писали:
XC>>Имя массива является адресом первого элемента массива (нелогично! со структурами же не так) LVV>ИМХО для С это было самое то! Но для С++, который позиционируется как язык более высокого уровня, — это анахронизм.
Это хорошая демонстрация корявости синтаксиса.
Если ЦПП позиционируется как язык более высокого уровня, то в нём вообще не должно быть даже намёка на strlen/strcpy (а так же calloc/malloc/memcpy).
C отдельно, ЦПП отдельно (так же как асм отделили от ЯВУ).
По какой-то странной причине от специалиста по C не требуют знаний асма, а вот с ЦПП — наоборот.
Солидная часть вопросов на собеседованиях по ЦПП по сути являются вопросами по C, о чем это говорит?
ЗЫ: ЦПП — мутант переходного периода.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Sheridan, Вы писали:
S>Я вот читаю-читаю, но так и не могу понять — откуда у людей такая нелюбовь к ц++?
слабая маркетинговая составляющая
S>Зато более шустрый софт получается.
запасаемся попкорном или линейками...
