LINUX.ORG.RU
Форум — Talks  

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

 


0

4

Стандартный набор аргументов хаяльщиков C++ следующий:

небезопасный, нет сборщика мусора; можно попортить память и сидеть много лет под дебаггером.

В любых более-менее серьезном проекте, не важно какой язык Java/C++/Lisp/whatever, пишут документацию и тесты (лисперы ведь пишут тесты, правда?). Так что у ошибок вида delete NULL и пр. нет шансов. А если какой-то тест падает - то тем проще найти и исправить: какая-нибудь JAVA просто многозначительно промолчит и в релиз войдет бага.

шаблоны == синтаксический сахар, ООП сложен и для гиков.

При адекватном тимлидере/ревьюере, который будет по рукам бить за кулхацкеровские извращения, это сводится на нет. А при неадекватном руководстве быдлокод пишется на чем угодно

Мое ИМХО: ругают C++ исключительно ниасиляторы, продвигая вперед тем самым маркетинговые машины всяких Java c .NET-ами. А создание действительно качественного софта, будь то C++/Java/.NET, соизмеримы как по деньгам, так и по срокам. Другое дело что ынтерпрайз порой клал на качество... среднее и низкое качество на Java/.NET наверное выходит дешевле.

Ы?


← [вещества]
Помогите с оплатой через PayPal →
  1 2 3 4 5
Ответ на: комментарий от mono

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Divius

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

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

Ilshat
()
Ответ на: комментарий от Divius

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

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

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

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

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

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

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

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

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

LORd
() автор топика
Ответ на: комментарий от mono

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

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


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

archimag ★★★
()
Ответ на: комментарий от Divius

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

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

LORd
() автор топика
Ответ на: комментарий от LORd

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

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

Ilshat
()
Ответ на: комментарий от Divius

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

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

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

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

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

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

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

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

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

Divius ★★
()
Ответ на: комментарий от LORd

ведение лога

Не помогает

GDB

не помогает

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

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

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

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

Divius ★★
()
Ответ на: комментарий от Divius

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

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

creepnee
()
Ответ на: комментарий от Ilshat

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

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

Divius ★★
()
Ответ на: комментарий от creepnee

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

Divius ★★
()
Ответ на: комментарий от Divius

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

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

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

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

LORd
() автор топика
Ответ на: комментарий от Divius

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от LORd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Skynin
()
Ответ на: комментарий от Ilshat

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

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

Divius ★★
()
Ответ на: комментарий от Skynin

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

Divius ★★
()
Ответ на: комментарий от LORd

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

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

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

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

Divius ★★
()
Ответ на: комментарий от Ilshat

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

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

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

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

Divius ★★
()

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

undertaker ★★
()
Ответ на: комментарий от Legioner

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

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

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

#include <iostream>

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

?

kamre ★★★
()
Ответ на: комментарий от Divius

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

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

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

Ilshat
()
Ответ на: комментарий от LORd

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

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

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

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

Skynin
()
Ответ на: комментарий от Ilshat

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

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

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

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

Divius ★★
()
Ответ на: комментарий от kamre

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

Divius ★★
()
Ответ на: комментарий от Divius

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

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

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

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

Legioner ★★★★★
()
Ответ на: комментарий от Skynin

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

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

Ilshat
()
Ответ на: комментарий от Legioner

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

Ну, вот и всё.

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

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

Divius ★★
()
Ответ на: комментарий от Divius

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

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

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

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

Skynin
()
Ответ на: комментарий от Skynin

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

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

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

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

LORd
() автор топика
Ответ на: комментарий от Skynin

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

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

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

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

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

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

LORd
() автор топика
Ответ на: комментарий от Legioner 
$ cat stack_alloc_array.cpp 
#include <iostream>

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

$ valgrind --version
valgrind-3.6.0.SVN-Debian

$ valgrind ./stack_alloc_array
==4528== Memcheck, a memory error detector
==4528== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==4528== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==4528== Command: ./stack_alloc_array
==4528== 
b = 1==4528== 
==4528== HEAP SUMMARY:
==4528==     in use at exit: 0 bytes in 0 blocks
==4528==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4528== 
==4528== All heap blocks were freed -- no leaks are possible
==4528== 
==4528== For counts of detected and suppressed errors, rerun with: -v
==4528== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 19 from 8)
kamre ★★★
()
Ответ на: комментарий от kamre

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

Legioner ★★★★★
()
Ответ на: комментарий от LORd

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

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

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

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

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

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

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

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

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

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

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

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

Skynin
()
Ответ на: комментарий от Karapuz

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

Eddy_Em ☆☆☆☆☆
()
Ответ на: комментарий от Ilshat

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

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

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

Skynin
()
Ответ на: комментарий от Divius

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

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

RADO
()
Ответ на: комментарий от kamre 
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

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

Ilshat
()
Ответ на: комментарий от RADO

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

Divius ★★
()
Ответ на: комментарий от Ilshat

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

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

kamre ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5
← [вещества]
Talks
Помогите с оплатой через PayPal →