[размышления]Так ли убог C++ как его малюют?

Мда, значит .NET пропагандируем, но основные продукты без всякого .NET. Я разочарован в MS.

Они хоть и делают абсолютнейшее дерьмо, но не дураки, чтобы втыкать себе палки в колеса...

> GCC такое скомпилирует, в некоторых версиях даже warning не выведя, но на вызове упадёт. Пара седых волос гарантирована.

Гонишь - обязательно ругнётся на отсутствие return в non-void function

> 1. Сложная отладка.

GDB, ведение лога. Различные IDE (я подозреваю, что если релизную версию .NET приложения запустить и она скрэшится, то информации тоже будет не густо).

2. Много шансов напортачить по глупости, и да, сидеть в дебаггере. Пример:

Когда на каждый такой пример пишется 2-3 теста, то все это мгновенно обнаруживается, безо всяких усилий.

3. Убогая стандартная библиотека... сотен мегабайт сторонних библиотек

Шутить изволите? Вся собранная Qt занимает порядка 20и мегабайт (без вебкита). А стандартная библиотека python-а, если сравнивать с Qt, - так вообще проигрывает.

4. Очень плохая стандартизация. Дважды переносил код под оффтопиком: MinGW -> VS, Borland C++ -> VS. Оба раза чуть не поседел.

Тесты, тесты, тесты... сразу видно что проект был без тестов ;)

Питон тоже не панацея. С ходу две критичные претензии: - переход к 3000: половина сторонних либ просто перестала работать; - GIL и все вытекающее.

> Мда, значит .NET пропагандируем, но основные продукты без всякого

.NET. Я разочарован в MS.

Мало того, они для офиса ещё очень давно собственную оконную систему написали и стандартные виндовый оконный API практически не используют. Я когда ещё коду в 2002 в него Spy++ потыкал так просто культурный шок испытал. У MS так давно: продают и рекламируют одно, а сами для реальной разработки используют другое...

> Мой выбор - Python, но, увы, не всегда переход возможен(

Да, а еще его GC не умеет циклические ссылки разруливать. Несерьезно в общем

> Несерьезно в общем

Так и приличного софта на нём нет. На жабе Vuze хотя бы, а на этом уг...

>если в шарпе и яве меньше возможностей отстрелить себе ногу

Типичное заблуждение.

1. Сложная отладка.

Использование valgrind-а решает почти на 100% все проблемы с памятью. Если нет возможности его применять, есть разные библиотеки, которые тоже помогают, не так хорошо, конечно.

GCC такое скомпилирует, в некоторых версиях даже warning не выведя, но на вызове упадёт. Пара седых волос гарантирована.

Код должен компилироваться без warning-ов, это почти не обсуждается. Очень редко warning-и бывают не в тему.

4. Очень плохая стандартизация

Скорее это особеннось. Правильно написанный код без UB скорее всего без проблем скомпилируется и будет работать на любой платформе. Правда такой код писать не очень просто. Но хорошие компиляторы помогают.

Как в джаве отстрелить себе ногу? Пример.

Использование valgrind-а решает почти на 100% все проблемы с памятью.

Только недавно писало про проблему, которую Valgrind не смог отловить. Банальный index out of bounds.

Код должен компилироваться без warning-ов

Так он и компилировался.

Правильно написанный код без UB скорее всего без проблем скомпилируется и будет работать на любой платформе.

Это такая утопия?

ведение лога

Не помогает

GDB

не помогает

А стандартная библиотека python-а, если сравнивать с Qt, - так вообще проигрывает.

Разве что в отсутствии GUI. Работа с сетью в Qt архиубога.

Тесты, тесты, тесты... сразу видно что проект был без тестов ;)

Предсказатель из тебя никакой. Были тесты. А толку?

>Только недавно писало про проблему, которую Valgrind не смог отловить. Банальный index out of bounds.

Отлично, но при чем здесь С++?

Гонишь - обязательно ругнётся на отсутствие return в non-void function

С -Wall - да. Без - не факт. Ну не думал я, что без -Wall такие серьёзные вещи могут не вывестись.

При том, что отладка очень сложна. Читать надо, на что отвечаешь.

> Разве что в отсутствии GUI. Работа с сетью в Qt архиубога.

И в чем же заключается убогость работы сетью в Qt, просветите пожалуйста?

Предсказатель из тебя никакой. Были тесты. А толку?

А в чем были проблемы? не тролинга ради

Только недавно писало про проблему, которую Valgrind не смог отловить. Банальный index out of bounds.

Ссылку можно? Не видел.

Это такая утопия?

Почему утопия?

-Wall (+ -Wextra) должно быть, это тоже само собой разумеется!

> В моем понимании «качественный софт» - это по сути хорошо документированный код с тестами.

Это хороший код, а не софт.

А хороший софт, это тот который решает задачи человека.

Опять же: все зависит от подхода к разработке и ожидаемому качеству. Неужели XP+TDD+DDD на C++ намного сложнее чем на Java/.NET?

Ощутимо сложней. Это то и ощутила вся отрасль. И выбор этой отрасли потому таков каков есть.

Отрасль коммерческая, то есть существующая с целью получения прибыли. А уж почему С++ оказывается прибыльным все в меньших областях программирования - вопрос второй.

То есть адепты С++ пытаются рассуждать не от факта, а от какой-то надуманной идеи.

А факт таков: область применения С++ точно НЕ расширяется, и даже не смог вытеснить plain С. Не стал и массовым языком прикладного и заказного программирования (не говоря о веб, а Java и туда кроме php влезла). Что говорит о том что есть в нем, ЯП какие то свойства, препятствующие «победе».

Вот и нужно искать их, эти свойства. От фактов нужно исходить, от фактов, а не придумок.

Но понятно и другое. Большинство так называемых «программистов на С++» студенческая молодежь, ищущая место в жизни. И как у всякого молодого человека, который пока никто и звать его никак - способ №1 - выпендрится.

Я на plain C писал в начале 90ых. Потом на С++, потому что тогда не было ничего другого. Последние 5 лет... зачем, если за то же время я более функциональное ПО напишу на Java? Я не пишу ни игр, ни серверов БД, ни драйверов. И крупносерийных продуктов не пишу.

Что пишут на С++ великие программисты с форумов? Или, может они уже руководители проектов, а потому весомо их мнение «все дело в подходе»? Они так наладили свои проекты что стоимость конечного ПО уже сравнялась с ПО на Java/.NET той же функциональности?

Вот, LORd, ответьте себе (на публике понятно понты не позволят) - сколько лет вы профессионально программируете? Что написали, и какая у вас должность в реале?

ВЫ - наладили тот подход о котором говорите? Сколько человек у вас в команде, компании? И т.д.

http://www.linux.org.ru/forum/development/5398080

Утопия, потому что стандарт никем фактически не поддерживается.

-Wall (+ -Wextra) должно быть, это тоже само собой разумеется!

Тогда они должны быть по-умолчанию. Однако, это не так в GCC (студия такой код вообще не съест, кстати).

Влезу в ваш разговор, но вы за все отрасли не говорите. Кроме Ытерпрайза с их гибернейтами есть ещё мноооого чего... И много где Java не очень-то уместна.

> Тогда они должны быть по-умолчанию.

С чего бы? Вы man-ов не читаете, а потом жалуетесь. На себя же.

И в чем же заключается убогость работы сетью в Qt, просветите пожалуйста?

Например, FTP только асинхронный, работает через раз, при этом поддерживается только «старым» классом QFtp, новые его вовсе не поддерживают (про режим «только чтение» я тихо молчу).

А в чем были проблемы? не тролинга ради

А как тесты помогают переносить код? Студия меня заставила, например, дописать у некоторых классов операторы (operator= или ==, не помню), которые я лично не использую. Что-то там внутри Qt потребовало.

С чего мне на себя жаловаться? Может GCC ещё по-умолчанию об ошибках сообщать не должен?

Вы сами писали:

-Wall (+ -Wextra) должно быть, это тоже само собой разумеется!

То, что «само собой разумеется», должно быть по-умолчанию. Это простая логика, никакой магии.

Как вы достали уже со своим C++. Давайте лучше Сашеньку Грей обсудим.

Банальный index out of bounds.

Ссылку можно?

Ссылку я тоже не знаю, но разве valgrind уже умеет ловить такие ошибки для массивов, размещенных на стеке:

#include <iostream>

int main()
{
  int a[2];
  int b = 0;
  a[2] = 1;
  std::cout << "b = " << b;
  return 0;
}

?

> Может GCC ещё по-умолчанию об ошибках сообщать не должен?

Почему вообще инструмент должен делать хоть что-то по умолчанию кроме основной функции (компиляции)?

Главное (ИМХО) - не надо полагаться на умолчания - читайте инструкцию.

> Тесты, тесты, тесты... сразу видно что проект был без тестов

И не надо молится на тесты. Каждые 3-5 лет появляется новомодная штучка. А TDD - уже не новомодная, вы отстали. Критики на веру в TDD уже немало есть. TDD, как уже выяснилось после нескольких лет повсеместного применения не спасает от очень многого.

Ни от кривой архитектуры, ни от проблем в многопотоковых программах, и даже от утечек памяти и наведенных ошибок - вечного бича С/С++ не спасает.

И вот от такого - http://eao197.blogspot.com/2010/10/progflame_25.html - тоже не спасает.

Почему вообще инструмент должен делать хоть что-то по умолчанию кроме основной функции (компиляции)?

То есть создавать _рабочие_ программы - уже не его основная функция

Главное (ИМХО) - не надо полагаться на умолчания - читайте инструкцию.

Не unix-style, ибо нарушает принцип наименьшей неожиданности.

Должен, но идеальных инструментов нет, вот и Valgrind тоже пропускает кое-какие вещи.

QTreeView падает на мой модели в drawRow()

valgrind обычно фильтрует свой вывод внутри библиотек, потому что они глючные или собраны с оптимизацией. Тут ничего не поделаешь.

Утопия, потому что стандарт никем фактически не поддерживается.

gcc и msvc достаточно хорошо поддерживают, обычно этого вполне хватает.

> И вот от такого - http://eao197.blogspot.com/2010/10/progflame_25.html - тоже не спасает.

«Несколько раз за мою бытность C++ником происходили случаи, когда мои C++ные программы падали, а я не мог объяснить причины этого. Причем всегда это было связано с Visual C++ компиляторами.» - как хорошо, что я пользуюсь gcc only ;-)

valgrind обычно фильтрует свой вывод внутри библиотек, потому что они глючные или собраны с оптимизацией. Тут ничего не поделаешь.

Ну, вот и всё.

gcc и msvc достаточно хорошо поддерживают, обычно этого вполне хватает.

Вот только не очень-то они совместимы, как я уже писал

Да, прошивки станков с ЧПУ - на плайн Си. Сервера БД - на С с классами. Ядра ОСей, и сами виртуальные машины - тоже на С и/или С++

И так будет, долго. В последние года выявилось ограничение - энергопотребление чипов. И поэтому не будет, как мечтали эрлангисты - сотен ядер на камне (в обозримом будущем)

А вот Android - будет. Симбу уже уел, остался MeeGo не взлетевший.

Но я и не переживаю что Java, php, 1C, ..., - не везде уместны. А вот почему переживают С++нисники, лисперы с хаскелистами, да, интересно.

> В последние года выявилось ограничение - энергопотребление чипов.

Популярность plain C растёт!
Радуюсь!

Вроде умеет. Попробовать лучше, я сейчас не в линуксе, проверить не смогу.

> Вот, LORd, ответьте себе (на публике понятно понты не позволят) - сколько лет вы профессионально программируете? Что написали, и какая у вас должность в реале?

ВЫ - наладили тот подход о котором говорите? Сколько человек у вас в команде, компании? И т.д.

Скажем так: я являюсь свидетелем того, как мои коллеги наладили этот процесс, и как это все замечательно работает. Коллектив порядка 10-и человек, уже года полтора идет. С++ и Qt.

А c java-ой близко мне не приходилось сталкиваться, напротив: единственный джавовский продукт в нашей конторе считается самым ущербным и проблемным. Потому я и удивляюсь, и вопросы такие задаю

> Каждые 3-5 лет появляется новомодная штучка

И как мне мешает для каждой штучки написать по тесту?

А TDD - уже не новомодная, вы отстали

Я за модой не гонюсь.

Ни от кривой архитектуры, ни от проблем в многопотоковых программах, и даже от утечек памяти и наведенных ошибок

А если бы это была Java? Кривая архитектура - пожалуйста. Проблемы в многопотоковых - не знаю как там с синхронизацией, но в .NET-е точно нужно синхронизировать - такие же проблемы; наведенные ошибки -... это все упущения менеджеров, которые допустили до тела быдлокодера. Тут уж язык не спасет: каким бы язык не был замечательным - через год работы быдлокодера ЭТО поддерживать уже будет невозможно.

Можешь запустить Office 365, посмотреть на это чудо правда платно http://www.betanews.com/article/1287505470

Понятно. Ну хотя бы программа не упадет без стектрейса через 2 секунды :)

> Коллектив порядка 10-и человек, уже года полтора идет. С++ и Qt.

И что пишите? Мне вот как раз интересно что же пишут на С++ + Qt, потому что я этого софта не вижу нигде. Не то что написано другими, а вот что пишут эти 10 человек?

А если бы это была Java? Кривая архитектура - пожалуйста. Проблемы в многопотоковых - не знаю как там с синхронизацией, но в .NET-е точно нужно синхронизировать - такие же проблемы;

Не такие же. Утверждать что такие же, это как говорить что везде убивают, и потому нет разницы между войной и мирным временем: «вона, соседа вчера у подъезда зарезали насмерть!». Или в С++ нет проблем с синхронизацией в многопотоковых приложениях? Или в С++ не бывает кривой архитектуры? А вот что кроме этого бывает - известно - постоянная маета с ручным выделением памяти и далее по списку.

Так я не понимаю вашей аргументации: С++ крут, потому что в нем бывают все проблемы Java/.NET да плюс-плюс своих кучи?

Давайте по другому: Вы пробовали писать на Java? Не хелло ворлд, а как положено программисту - каждые 2-3 года выучить новый ЯП.

И как мне мешает для каждой штучки написать по тесту?

А кому - мешает? Я же сказал что TDD от очень многих вещей - не спасает, чтобы так веровать в нее.

Тут уж язык не спасет: каким бы язык не был замечательным - через год работы быдлокодера ЭТО поддерживать уже будет невозможно.

А кто вам сказал что вы - не быдлокодер? Вы сами так решили потому что что-то пишите на С++? :D

Ваш код, уже сколько лет сопровождают другие, что вы так уверены?

И сработает ли мой аргумент - «а если наладить разработку так что быдлокодеров в ней не будет»? ;)

У меня и т.н. «офис 2007» на запустится (разве что если в виртуалбоксе поставить для начала пиратский мастдай) :)

> Популярность plain C растёт! Радуюсь!

Я по диплому схемотехник. Скукота прошивки для ЧПУ писать как по мне... Но, дело вкуса, вам нравится - пишите. Миру нужны и такие устройства. У меня сослуживец, в конце 90ых в Германию уехал, так до сих пор на plain C и пишет. Его контора как раз субподрядчиком производителей пром оборудования и выступает.

Я бы не смог, поэтому давно ушел в «склады с оперденями»

>То есть создавать _рабочие_ программы - уже не его основная функция

Функция компилятора - компилировать. Создавать программы дело программиста, а от него уже, в большей мере, и зависит будут ли они рабочие. Язык - только лишь средство.

cat stack_alloc_array.cpp 

#include <iostream>

int main()
{
  int a[2];
  int b = 0;
  a[2] = 1;
  std::cout << "b = " << b;
  return 0;
}

cppcheck stack_alloc_array.cpp

Checking stack_alloc_array.cpp...
[stack_alloc_array.cpp:7]: (error) Array 'a[2]' index 2 out of bounds

Гораздо понятнее, ИМХО ;-)

Тогда предлагаю убрать проверку на ошибки, компилировать, как придётся.

Можете привести несколько примеров неплохого софта на жабе, расчитанного на пользователя

http://download.cnet.com/Thinkfree-Office/3000-18483_4-10790.html?tag=mncol;4 Thinkfree Office

http://www.sweethome3d.com/download.jsp

> Гораздо понятнее, ИМХО ;-)

Это ж просто чтобы показать, что valgrind не всесилен. В реальности индекс будет вычисляться в runtime и никакой cppcheck такое не отловит.