Здравствуйте, Nikе, Вы писали:
BDA>>Я все могу простить. И то, что эстетически система наименований делалась людьми, которые, очевидно, мало книжек в детстве читали. И даже то, что operator wchar_t* («wchar_t»! буэ!) в строках нет (те, кто говорят, что он там небезопасен — вспомните, как писали на MFC, а ТАМ ОН БЫЛ. Хоть раз это привело к проблемам? Расскажите, не стесняйтесь). N>Он там не нужен. Есть специальная функция. А я вообще уже лет 8 не использую char* и wchar_t* для чего-либо, кроме связи с другими либами. Но все эти связи заврапленны и не видны.
Не всем так повезло. У некоторых на подобные wrapping'и приходится изрядная часть кода (например, в типичном WinAPI-приложении) и каждый раз при наличии строк в аргументах необходимость писать (или еще хуже — читать!) этот c_str()...
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Не всем так повезло. У некоторых на подобные wrapping'и приходится изрядная часть кода (например, в типичном WinAPI-приложении) и каждый раз при наличии строк в аргументах необходимость писать (или еще хуже — читать!) этот c_str()...
Здравствуйте, Nikе, Вы писали:
BDA>>Не всем так повезло. У некоторых на подобные wrapping'и приходится изрядная часть кода (например, в типичном WinAPI-приложении) и каждый раз при наличии строк в аргументах необходимость писать (или еще хуже — читать!) этот c_str()...
N>Под виндой есть замечательный ATL/WTL CString
Это тот же CString, что и в MFC, насколько я знаю. Про него я написал выше. Но тащить из-за одной строки ATL/WTL... Так и рождается... мнэ... неоднозначное отношение к языку, который в стандартной библиотеке ничего близко похожего не предлагает.
Здравствуйте, Cyberax, Вы писали:
C>Не надо бредить. В современном С++ нафиг никому не сдались те самые классы с виртуальным наследованием и прочим.
Виртуальное наследование — очень полезная фишка, потому что про него очень удобно спрашивать на собеседованиях, когда нужно завалить кандидата. Т.к. этой фичей реально никто не пользуется, то о ней никто путью и не знает
Здравствуйте, 0BD11A0D, Вы писали:
N>>Под виндой есть замечательный ATL/WTL CString
BDA>Это тот же CString, что и в MFC, насколько я знаю. Про него я написал выше. Но тащить из-за одной строки ATL/WTL... Так и рождается... мнэ... неоднозначное отношение к языку, который в стандартной библиотеке ничего близко похожего не предлагает.
Почему ради одной? Нормальный класс-строка. Мы сделали кросс-платформенный аналог + скрестили его с симбиановскими дескрипторами — и получилось то, с чем можно работать, без общущения, что тебя насилуют.
Я че еще на С++ то взъелся, прочитал тут про Erlang, там вообще не парятся со многими вещами. Даж по поводу рекурсии, типа там стека не хватит или еще че.
Синтаксис страшно непривычный но чего ... вообще его можно было использовать для всего, для чего мы использовали с++ с корбой. Я конечно там ничего не решал, но все равно.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Параллельно существовали мощные объектно-ориентированные языки, которые обладали очень слабой производительностью. Страуструп писал на одном таком серьезную систему, не смог добиться перфы
Это ты Simula 67 сейчас обозвал "мощным объектно-ориентированным"?
BDA>Во-первых, фокус с функционала переместился на «архитектуру».
Не столько на архитектуру, сколько на попытках запихнуть в стандартную С++ библиотеку функционал, который бы примерно одинаково работал на всех поддерживаемых платформах, т.е. и на PIC12, и на Itanium.
Поскольку этого практически невозможно достичь (слишком разные они все), имеем то шо имеем.
BDA>Извините меня, но std:(w)string это ХУДШАЯ РЕАЛИЗАЦИЯ строк, которую я когда либо видел. Она же не умеет просто ничего!
С этим согласен.
BDA>Во-вторых, шаблоны пошли вразрез с тем, что добавлял Страуструп.
А с этим нет.
Это не шаблоны виноваты в том, что афтары STL и Boost их так используют.
В качестве примеров хороших, годных шаблонов посмотри на ATL, там тоже есть и строки, и контейнеры, и смартпоинтеры, только сделано всё по-нормальному, и работает обычно сильно быстрее, а иногда так даже на порядки быстрее, чем то же самое в STL.
BDA>Единственное преимущество, которое у плюсов остается, это ВЕНДОРОНЕЗАВИСИМОСТЬ.
Не только.
Например производительность, возможность писать низкоуровневый код если нужно, относительная кросс-платфременность.
BDA>Резюме: стоит хорошему языку вырваться на волю, и конец этой груде мусора.
Хорошие языки давно есть, в том числе для той же ниши, где щас С++. Например знакомые D используют.
Однако я не буду сильно удивлён, если эта груда мусора ещё нас обоих переживёт.
Слишком уж много проектов на нём, и старых и новых, вот например весь рынок видеоигр плотненько сидит на плюсах.
Здравствуйте, кубик, Вы писали:
К>Всем привет, К>Я вощем то С++ программист, звезд с неба не хватаю, писал всяикий аккаунтинг в стиле С++ с классами. К>Сейчас открыл книгу Effective Modern C++ про С++14,С++11 и думаю, блин, для кого они все это придумывают?! Для самих себя?
Я люблю С++, в нем большой простор для творчества!
Чтобы написать приложение, нужно уметь писать костыли под разные компиляторы и платформы,
Люблю изучать информативные сообщения об ошибках (access violation at adresss 0xFFFFFFFF)
Люблю С++ за скорость компиляции (можно сходить куда-нибудь по делам)
Люблю препроцессор, особенно макросы, они делают код живым.
Никогда не знаешь, что сломает компиляцию на этот раз (С++ любит удивлять!)
Люблю заниматься перекомпилированием библиотек под разные компиляторы, дебаг/релиз, статик/шаред,64 бит/32 бит
Люблю получать странные ошибки линковки и медитировать над ними.
Люблю собирать опен-сурс проекты под виндой (интересно проходить этот квест)
Люблю многообразие систем сборки для С++.
Не то что эти всякие попсовые Сишарпы/жавы для слабаков. Написал код, а он просто работает. Скучно ведь!
Чувствуешь себя ненужным.
Здравствуйте, Zenden, Вы писали:
Z>Чтобы написать приложение, нужно уметь писать костыли под разные компиляторы и платформы,
Большинству реально пох, мало кому надо более двух платформ.
Z>Люблю изучать информативные сообщения об ошибках (access violation at adresss 0xFFFFFFFF)
При чём тут С++?
И кстати такая ошибка просто подарок — можно быстро локализовать. Логические ошибки в коде куда хуже.
Z>Люблю С++ за скорость компиляции (можно сходить куда-нибудь по делам)
Давно уже летает пулей в умелых руках.
Z>Люблю препроцессор, особенно макросы, они делают код живым.
Это вообще то С а не С++.
Z>Никогда не знаешь, что сломает компиляцию на этот раз (С++ любит удивлять!)
О чём ты?
Z>Люблю заниматься перекомпилированием библиотек под разные компиляторы, дебаг/релиз, статик/шаред,64 бит/32 бит
Это всё автоматизируется уже много лет как.
Z>Люблю получать странные ошибки линковки и медитировать над ними.
Например?
Z>Люблю собирать опен-сурс проекты под виндой (интересно проходить этот квест)
Обычно потому, что опенсурсники кроме как под свой линукс ни про что другое и не думали.
Z>Люблю многообразие систем сборки для С++.
Вижуалку и make никто не отменял.
Z>Не то что эти всякие попсовые Сишарпы/жавы для слабаков. Написал код, а он просто работает.
Если бы всё было так просто
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, smeeld, Вы писали:
C>>А вот деструкторы, шаблоны и умные указатели очень даже используются. S>Вы говорите как школяр.
/me смотрит на свои два проданных стартапа. Ну да, для восьмого класса школы вполне нормально.
S>Ни деструкторы, ни умные указатели (дибилизм сами по себе) не есть хоть S>немного значимая фишки C++, а шаблоны вообще ущербны, по сравнению с средствами, предназначенными S>для тех же целей, присутствующими в других ЯП. Сравните для начала С++ шаблоны с Лисповыми макросами.
Шаблоны решают ровно те задачи, которые чаще всего нужны — типизированные контейнеры. Как макросы для сложного метапрограммирования их используют не так часто.
Здравствуйте, Константин, Вы писали:
BDA>>Параллельно существовали мощные объектно-ориентированные языки, которые обладали очень слабой производительностью. Страуструп писал на одном таком серьезную систему, не смог добиться перфы К>Это ты Simula 67 сейчас обозвал "мощным объектно-ориентированным"?
Ничего про нее не знаю, кроме того, что вспомнил (возможно неправильно) из рассказа С. Сейчас посмотрел:
Simula 67 introduced objects,[1]:2, 5.3 classes,[1]:1.3.3, 2 inheritance and subclasses,[1]:2.2.1 virtual methods,[1]:2.2.3 coroutines,[1]:9.2 and discrete event simulation,[1]:14.2 and features garbage collection.[1]:9.1
Да, рядом с голым Си рискнул бы назвать "мощным объектно-ориентированным". Впрочем, если это вам принципиально, мне — абсолютно нет. Готов согласиться на немощность, т.к. не вижу, что это меняет.
BDA>>Во-первых, фокус с функционала переместился на «архитектуру». К>Не столько на архитектуру, сколько на попытках запихнуть в стандартную С++ библиотеку функционал, который бы примерно одинаково работал на всех поддерживаемых платформах, т.е. и на PIC12, и на Itanium. К>Поскольку этого практически невозможно достичь (слишком разные они все), имеем то шо имеем.
Подождите, но ведь C как-то умудряется примерно одинаково работать там и сям. Что мешало инкапсулировать printf? Допустим, то, что было в сях, обернули, чего не было — проигнорили. Разве это не будет достаточно логично? Но ведь так не сделали.
BDA>>Во-вторых, шаблоны пошли вразрез с тем, что добавлял Страуструп. К>А с этим нет. К>Это не шаблоны виноваты в том, что афтары STL и Boost их так используют. К>В качестве примеров хороших, годных шаблонов посмотри на ATL, там тоже есть и строки, и контейнеры, и смартпоинтеры, только сделано всё по-нормальному, и работает обычно сильно быстрее, а иногда так даже на порядки быстрее, чем то же самое в STL.
На самом деле вы согласны, просто еще этого не знаете. Имелись в виду не абстрактные шаблоны, а the шаблоны, то есть те, что Степанов с Ли сочинили. Разумеется, шаблонные классы от Майкрософт (хоть ATL, хоть — в другом языке — FCL) лишены указанной... особенности. Но! В стандарт они не вошли, а вошло сами знаете что.
BDA>>Единственное преимущество, которое у плюсов остается, это ВЕНДОРОНЕЗАВИСИМОСТЬ. К>Не только. К>Например производительность, возможность писать низкоуровневый код если нужно, относительная кросс-платфременность.
Первые два пункта: это до тех пор, пока вы остаетесь в рамках старой парадигмы «Си с классами». Я встречал то ли на кремниевой тайге, то ли на геймдеффе (падонкавском, а не который .ру) душещипательный рассказ о неудовлетворительном падении перфоманса после попыток использовать (правильным образом, конечно) STL. То есть, при попытке использовать удобства, которые есть в других языках, в тех приложениях, которым перфоманс жизненно важен (3D-движках, например) результат будет принципиально неудовлетворительным. Что остается? Скорость в два раза выше в тех приложениях, в которых это не принципиально? Кого это волнует, кроме «пофиксившихся» на идее.
Третий пункт: я не думаю, что кросс-платформенность важна настолько, насколько мы привыкли думать. Возьмите мой пример с Джавой. У хостеров нет проблем с тем, чтобы запустить ее на своих серверах. Желания только нет. Как, впрочем, и плюсовые кастомные CGI.
Здравствуйте, 0BD11A0D, Вы писали:
BDA>Первые два пункта: это до тех пор, пока вы остаетесь в рамках старой парадигмы «Си с классами». Я встречал то ли на кремниевой тайге, то ли на геймдеффе (падонкавском, а не который .ру) душещипательный рассказ о неудовлетворительном падении перфоманса после попыток использовать (правильным образом, конечно) STL. То есть, при попытке использовать удобства, которые есть в других языках, в тех приложениях, которым перфоманс жизненно важен (3D-движках, например) результат будет принципиально неудовлетворительным.
Ой, ну что за кретинический бред. В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов.
Из того, что я видел, чаще всего страдают из-за того, что в STL не так много всего. Т.е. если нужен контейнер указателей, то не думая берут vector<shared_ptr<...>>, а потому репу чешут и пишут на форумы о тормозах STL.
Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать. Это изменение ускорило некоторые приложения, но не кардинально.
Simula 67 introduced objects,[1]:2, 5.3 classes,[1]:1.3.3, 2 inheritance and subclasses,[1]:2.2.1 virtual methods,[1]:2.2.3 coroutines,[1]:9.2 and discrete event simulation,[1]:14.2 and features garbage collection.[1]:9.1
Лично ты бы взял первую в природе реализацию подобных фундаментальных концепций для чего угодно в production?
BDA>Подождите, но ведь C как-то умудряется примерно одинаково работать там и сям.
C++ тоже везде прекрасно работает, но мы же щас не про язык, а про библиотеки.
Стандартная библиотека C реализует только какие-то совсем базовые вещи. Например программируя под Win32/64, часто можно обойтись вовсе без CRT, ибо не нужна.
BDA>Что мешало инкапсулировать printf?
Переполнения буферов, производительность, неправильное дизайн-решение афтаров STL про типобезопасность.
BDA>Допустим, то, что было в сях, обернули, чего не было — проигнорили.
Ну скажем про строки и iostreams так и сделали. Cам же пишешь, что не особо полезные получились. В частности потому шо в CRT не хватает разных критически важных кусков.
Про строки не хватает например unicode, date+time и прочей глобализации, про IO не хватает асинхронности, обработки ошибок, и вообще всего, что нужно для написания чего-то сложнее, чем printf("Hello world").
BDA> В стандарт они не вошли, а вошло сами знаете что.
Стандарт сильно волнует только студентов, преподавателей, и ещё глупых разработчиков каких-то SDK. Всем остальным на него пофигу.
BDA>душещипательный рассказ о неудовлетворительном падении перфоманса после попыток использовать (правильным образом, конечно) STL.
STL в играх не нужен, про это в индустрии уже давно в курсе.
BDA>при попытке использовать удобства, которые есть в других языках, в тех приложениях, которым перфоманс жизненно важен (3D-движках, например) результат будет принципиально неудовлетворительным.
Зависит исключительно от кривизны рук пользующего. Из личного опыта — современный C++, со всеми его шаблонами и полиморфизмом, прекрасно работает например на Nintendo Wii (кстати о производительности и портируемости — там всего 700 MHz CPU с архитектурой Power).
Причём при правильном использовании он и эффективнее (потому что при правильном использовании шаблонов они много всего инлайнят а потом компилятор много всего оптимизирует), и безопаснее, чем C, неважно с классами или без.
Конечно для индустрии в целом это скорее проблема: из-за того что язык сложный, погроммистов с правильной кривизной рук мало, а те что есть, много хотят кушать.
Поэтому где становится можно, обычно двигают от плюсов в сторону чего-нибудь более дружественного разработчику. Скажем лет 10 назад с C++ валили разработчики опердней, переходя на Java и C#.
Для игр однако это не очень критично, по следующим причинам: (1) Программисты всё равно обходятся в разы дешевле, чем арт (2) Код игр уже давно разделили на ядро (обычно С++) и скрипты (часто LUA). (3) Развитый рынок middleware, заточенный в основном на C++ клиентов, усложняет миграцию.
BDA>я не думаю, что кросс-платформенность важна настолько, насколько мы привыкли думать.
От ниши зависит. Например игры должны быть портируемыми на разные X86-64, ARM и Power.
Здравствуйте, Cyberax, Вы писали:
C>Ой, ну что за кретинический бред.
Он абсолютно прав.
C>В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов.
На каждый чих кидают С++ исключения.
На каждый чих конструируют объекты new/delete: динамическая память в играх не нужна, чем статичнее, тем обычно всё лучше работает, тем более на консолях и мобильниках точно известно, сколько именно есть той памяти.
Для этих new/delete берут память из CRT heap, к которой тоже есть вопросы.
C>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов
Интересно, есть ли среди ваших target platforms консоли? Мобильники? Или только PC и x86 сервера?
Здравствуйте, Константин, Вы писали:
C>>В STL все контейнеры тупые и понятные, там просто нечему тормозить, особенно после добавления move-конструкторов. К>На каждый чих кидают С++ исключения.
Для большинства контейнеров — только bad_alloc, который можно игнорировать. Остальное — только в специальных методах, которые явно проверяют границы (.at).
К>На каждый чих конструируют объекты new/delete: динамическая память в играх не нужна, чем статичнее, тем обычно всё лучше работает, тем более на консолях и мобильниках точно известно, сколько именно есть той памяти.
Где именно "на каждый чих"? В спеке С++ чётко прописано, когда коллекции будут делать распределения памяти и ничего неожиданного там нет совершенно.
И про игры не надо — во многих играх сейчас вообще GC используется вовсю.
К>Для этих new/delete берут память из CRT heap, к которой тоже есть вопросы.
В STL можно использовать свои аллокаторы, которые в С++11 ещё и stateful. Так что никто не мешает использовать арены, пулы или разделяемую память.
C>>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов К>Интересно, есть ли среди ваших target platforms консоли? Мобильники? Или только PC и x86 сервера?
Есть, конечно же. А чем они нынче от обычных PC отличаются?
Здравствуйте, Cyberax, Вы писали:
C>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать. Это изменение ускорило некоторые приложения, но не кардинально.
А какую STL используете? В современных реализациях STL подобная оптимизация встроена.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
C>>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать. Это изменение ускорило некоторые приложения, но не кардинально. EP>А какую STL используете? В современных реализациях STL подобная оптимизация встроена.
На основе libc++, там такой оптимизации нет. Иногда компилятор сам догадывается, но явная оптимизация оказалась лучше.
Здравствуйте, Cyberax, Вы писали:
C>>>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов, которые можно сразу через memcpy копировать. Это изменение ускорило некоторые приложения, но не кардинально. EP>>А какую STL используете? В современных реализациях STL подобная оптимизация встроена. C>На основе libc++, там такой оптимизации нет.
Насколько я вижу, в libc++ для is_trivially_copy_assignable используется memmove (1, 2).
Здравствуйте, Константин, Вы писали:
К>Здравствуйте, Cyberax, Вы писали:
C>>Сейчас единственное улучшение в нашей внутренней STL — это специализация векторов для POD-объектов К>Интересно, есть ли среди ваших target platforms консоли? Мобильники? Или только PC и x86 сервера?
На мобильниках наиболее распространены: Objective C, Java и C#. Всё это ещё те тормоза и им до проблем высших порядков типа динамической-статической памяти как до Луны.
