Что есть в сабже сильно и что есть слабого ?
Хотелось бы увидель , что думают по этому поводу программеры!

PS ждемс обсуждения 

сильно - шаблоны. где ещё такое есть?

запутанная система подключения заголовочных файлов

Распространенность.  

The Problem with Programming
Bjarne Stroustrup, the inventor of the C++ programming language,
defends his legacy and examines what's wrong with most software code.
Tuesday, November 28, 2006

More Trouble with Programming
The second part of our interview with Bjarne Stroustrup, the inventor of C++.
Thursday, December 07, 2006

Там и комментариев много

И вот тут комментируют

SergeCpp, я знаю , что ты силен в С++ , но я не просил ссылок , я просил обсуждение!


понятно

эт ты к чему относишь? к сильной или слабой стороне?

    PS чет сишники молчат 

Да нету у него слабостей, сила одна!   

В бытность мою С++ программером временами приходилось использовать сишные макросы, не хватало возможности делать вложенные макросы, т.е. подставлять одни макроопределения в #defin-ы других. Хотя, как я понимаю, грамотнее не использовать макросы вообще, но... (к примеру для кроссплатформенных приложений они часто где юзаются)

Добавлено @ 15:56 
З.Ы, насчёт

Комментарии будут ? 

Пример №1: есть 2 класса должны "знать" друг о друге, но объявлены в разных .h-файлах. Пример: указатель на Parent и массив Child-ов, классы разнородные (не наследники). Как правильно подключить один .h к другому без колдунства с прототипами  ?   

Пример №2: один заголовочный файл используется в нескольких других. Чтобы избежать повторных объявлений всего что есть в этом файле, приходится колдовать с #if/#endif в начале и конце файла, ставить разные #pragma once и т.п.

Добавлено @ 16:00 
Ещё один минус, возможно что спорный: сложность при отладке. При использовании таких возможностей языка, как шаблоны, typedef-ы, макросы, переопределения операторов, найти баг становится сложнее (к рантаймовым багам добавляются неявные ошибки времени компиляции - неправильный вывод типа, подстановка и т.п.)

А я еще в соседней теме говорил, что никакого неявного кода быть не должно.
Кстати только у меня из несишников чуство, что сишники только тем и занимаются, что пишут шаблоны, собственные строковые классы и перегружают операторы?  

И МЕНЕДЖЕРЫ ПАМЯТИ !!!         

Одни словом -  занимаются настоящим программированием, в отличие от жабистов, дотнетчиков и драг-энд-дроп программистов   

mr.DUDA, см. 8.1 Modularization and Interfaces & 9 Source Files and Programs в Специальном Издании


Это сообщение отредактировал(а) SergeCpp - 5.2.2007, 16:43

имхо чушь, иначе был бы он идеален и его юзали бы все, а такого нет , юзают много чего, вывод,
значит твоя фраза не есть истина, и мистер Дуда много чего привел!
mr.DUDA, сиба , интересные мысли 

Кса чет не вижу реальных представлений силы? тем более шаблоны , и их использование понизилось в статусе силы....

сишники не могут делать этого по определению   

почему?
хоть один сишник забрел 

Ибо С != С++   

Romikgy, 
потому что Сники это не С++ниики  

Добавлено @ 17:49 

а то
такая тема, грех не зайти  

Добавлено @ 17:54 
имхо, единственная проблема С++ - препроцессор
делаем встроенный оператор include, расширяем шаблоны (чтобы не хотелось макросами пользоваться), стандартизуем тип файла, который можно включить оператором include (т. е если в нем есть кроме описаний - код - ошибка (кроме inline функций)), делаем template export и убираем препроцессор

Это сообщение отредактировал(а) MAKCim - 5.2.2007, 17:48

mr.DUDA, во всём этом виноват не C++, а его препроцессор. В "Дизайн и эволюция C++" Бъярни писал, что когда-то предлагал сделать инклюд-конструкцию на уровне языка, естественно более продвинутую. По непонятным для меня причинам комитет это отверг (как будет в будущем - не знаю).

Далее - по сабжу написаны плюсы => говорим про плюсы.

А в чём сила плюсов? В том, что плющит конкретно.   А если серьёзно - дял меня в неповторимом стиле программирования, в некоей атмосфере что ли. Я не против многих языков, рассисткой ненависти не испытываю, но плюсы... (см. подпись).

Недостатков - много, не спорю. Плюсы разрабатывались не пойми как. Самое интересное, что всё таки популрность завоевали обалденную.


Ещё чего!  

Добавлено @ 18:02 

  А условная компиляция?

Лично меня больше всего на коня подсадило в свое время невозможность отделения объявления от реализации для шаблонов.
Скорее бы это в стандарт!  

все делаем в виде операторов

Добавлено @ 18:05 

это уже в стандарте
только вот реализовать это сложно
по-моему только 1 компилятор на сегодня способен на export

Можно поподробней? Весь все равно путь даже синтаксически по другому, другой, но по сути препроцессор.

Насчёт экспорта - да, он в стандарте. Реализует его вроде только Comeau ([offtop]кто-то вообще этот компилер вживую видел [/offtop]). После прочтения Саттера по этому поводу возникает мысль, что поспешили с введением экспорта. О его необходимости никто не спорти - но в другом виде. ТЕкущий экспорт - бесполезная вещь.

Это сообщение отредактировал(а) Любитель - 5.2.2007, 18:21

Так его только и юзают для разработки серьезного ПО. Тут можно в принципе даже не отделять С от С++, так как С код компилирутеся С++ компилятором и можно смешивать С и С++. Всё остальное - прикладное программрование на уровне VB. 

Кто привык использовать инклюды препроцессора никакого дискомфорта по их поводу не испытывает. Есть стандартные решения для корректного инклюда. Просто вы привыкли чтобы за вас всё делал визард или фреймворк, вот и боитесь лишний раз напречься   

Насчет шаблонов я вообще не понял о чём речь? Они то в С++ уже есть не первый десяток лет. А в  Java и C# появились сравнительно недавно. И кто их понизил в статусе силы, не вы ли случайно?   

Вот когда добьетесь производительности от программы написанной на каком нибудь другом языке, отличном от С/С++ (ассемблер не предлагать), тогда я сниму перед вами шляпу. А так я готов терпеть все его "неудобства", зато они окупаются сторицей   

Это клевета!!! Нет там шаблонов. Дженерики != шаблоны. Полное !=.   Никакого метапрограммирования они не несут, лишь некоторое обобщение, да и то и в яве, и в шарпе, если не ошибаюсь, только для классов. Никакого автоопределения типов шаблонов - нет. Нельзя это сравнивать с шаблонами. Я не говорю, что шарп с явой из-за этого хуже - нет, ни в коем случае, но сранивать дженерики и шаблоны - не позволю!!!   

Любитель, хорошо - некое подобие шаблонов    Такая формулировка вас устроит?   

Ага, если ещё добавить жалкое подобие - это нас устроит   

Fortran подойдет?  

LSD, только математика. Эффективное управление памятью - сомневаюсь. Но собсно говоря и плюсы не совсем дял того создавались. Есть Си - хороший по своему, но по идеолгоии далёкий от плюсов.

Добавлено @ 19:04 
[offtop]
млин что-то я совсем - очепятки горой идут   
[/offtop]

Это сообщение отредактировал(а) Любитель - 5.2.2007, 19:04

Есть не так много вещей кроме математики, способных загрузить процессор на 100%.
И вообще какое это имеет отношение к тому, что я написал?

Есть бесконечное количество вещей кроме математики способных загрузить проц на 100%


С точки зрения вычислимости  C=C++

да я думаю
С = C++ = Pascal = Delphi = ... (на одной архитектуре)
разница будет только в "хорошести" компиляторов

Не нравятся указатели.

знак * ?

Однако возможности компилятора по оптимизации в некоторой мере зависят и от свойств языка. Пример: введение restrict в C99.

  Не очень прозрачные и не очевидные. Насколько мне известно, главная проблема плюсов это утечки памяти. Предвижу комментарии, типа утечки только у чайников, но помните, что профи не рождаются, а становятся благодаря большому опыту и знаниям, но все это не приходит вмиг! А живем мы раз и хочется (да и нужно) постоянно иметь результат работы, а не только потом, спустя годы.
  Вот только сегодня уперся - дебагер виснет на операции delete[] m_bufer, при этом просто виснет и ничего не сообщает. Даже код ошибки узнать нельзя, потому что после ничего не выполняется. Указатель с виду "хороший", запретных операций тоже, на глаз не видно, хотя точно есть, но где неочевидно. 
  Сишники будут активно возмущаться, но я все скажу. ИМХО указатели это вообще прошлый век, и пора от них совсем отказываться, как от плохого стиля программирования, такого как GoTo и т.д.

 Это что значит? По performance что ли? Не думаю. Чем более формален язык -  тем эффективние код.
Поэтому в ряду ASM - FORTRAN - C - C++ - Pascal скорость кода убывает



 Испльзуйте smart pointers.... Контроль за памятью - это не забота языка и к языку никакого отношения не имеет. Это уже библиотеки. База у С - достаточная. Компилятор должен обеспечивать только корректное обращение по указанному адресу.

Это сообщение отредактировал(а) Sartorius - 5.2.2007, 21:11

Sartorius, 



любой язык описан формально

да ты что?
все зависит от компилятора
в большинстве случаев код плохого программиста на ассемблере будет хуже кода хорошего С-компилятора
И вообще, что за понятие такое: скорость кода?

Это сообщение отредактировал(а) MAKCim - 5.2.2007, 21:18

Ясное дело при прочих равных условиях   



 Да.. ерунду сказал. ...

Чем ниже уровень языка - тем эффективнее код.

ЗЫ Что за вычислимость такая? Можно говорить о вычислимости выражения и т.п. А код здесь причем?

Это сообщение отредактировал(а) Sartorius - 5.2.2007, 21:25

ну видно имелось в виду что-то типа этого

По простому так. 


И С и С++ эквивалентны машине тьюринга. А соответсвенно и эквиваленты один другому.


Эквивалентны машине тьюринга, это значит они могут симулировать М.Т.  И М.Т может симулировать их.

1. я не хотел делить С и С++, имхо это практически одно и тоже (хотя различий хватает),
и в данном топике , я бы хотел увидеть обсуждения С++
2. сравнивать языки друг с другом , конечно хорошо , но хотелось бы видет именно недостатки и достоинства С++

точнее можно?

по подробнее плз

чем можно узнать?

да , конечно запутано , но это дело привычки имхо , и очепяток   

чет я не понял чем эта вещь хороша?

это проблема у тех кто не пользуется smart pointer'ами. Я уже не помню когда писал сам "delete"/"delete[]".

 Нет, сама необходимость их использовать.

 +1 =) чисто интуитивно )

 А можно поподробнее?

  имхо STL можно vector   

тоже интересно послушать 

кса и некто не говорит о сильных сторонах С++  

Они априори ясны разумным людям

Позволяет указать компилятору, что данный указатель… э-э… не подвержен aliasing, тем самым позволяя более агрессивные оптимизации.

здесь не все настолько разумны! плз по буквенно и медленно , так что бы поняли все , включая чайников!

  и агрессивный компилятор  

 

если провести параллель - в Delphi так реализованы экземпляры - интерфейсы - вместо вызова конструктора вызывается getInstance(увеличивает счетчик ссылок на 1), деструктор тоже не вызывается, а вызывается специальный метод, который уменьшает количество ссылок на 1. при достижении счетчиком ссылок 0, интерфейс выбрасывается из памяти без привлечения программиста. такая же фишка  - в паттерне "одиночка", только там всё через статические поля класса. А "умные указатели" реализуются на шаблонах С++.
Я правильно понимаю тему гребли, товарищи С++-ники?

т.е. 

это плюс этого языка

по направлению оптимизации?!

Romikgy, скорее костыль, заплатка.

Я к тому, что язык влияет на возможности оптимизатора. Обладая большей информацией о коде (система типов и т.д.) компилятор вправе делать более смелые предположения, не рискуя нарушить семантику кода.

т.е. это минус?

Romikgy, ты можешь отвлечься от понятий абсолютного добра и зла? 

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

<Стерто>
Модераторы, уберите плиз.

Это сообщение отредактировал(а) Beltar - 5.2.2007, 23:48

гна, ясности хоцца


хмммм как все запутано ...

Возвращаясь к теме инклюдов, отвечаю Sun: нет, "нас" не испортили визарды и фреймворки. Вопрос тут не в том, "как правильно нужно делать и почему", а в том "почему в С++ приходится подстраиваться под неудобный препроцессор"  

Он не неудобен - он прост. Не нравтяся инклюды - пиши код в одном текстовом файле. Не нравится препроцессор - не используй. Это всё вещи опциональные и вспомагательные. Можно в конце концов свой препроцессор написать, который будет соединять тексты так, как вам удобно. 

Зато вы хоть знате как всё устроено и как всё работает а некоторую сложность использования С++ я отношу также к его сильной стороне, потому что в среде С++ чайников несравнимо меньше чем среди других популярных языков. 

ну-ну   
теоретически да, а практически...

в смысле?

В прямом. Берётся код программы компилируется в объектный код и линковщиком собирается в исполняемый бинарный код. Все можно посмотреть как оно работает в ассемблере, какие регистры заполняются, что по какому адресу лежит, какие API функции вызываются - красота одним словом. Никаких тебе чёрных ящиков с байткодом или дебрями рантайма.

restrict "говорит" компилятору, что в данной области видимости, данные, на которые указывает restrict pointer, могут изменяться только через этот указатель
в связи с этим возможны оптимизации с его (компилятора) стороны
правда, вот сейчас ради интереса, решил "поиграться" с restrict и разницы между "с restrict" и "без restrict" не заметил вообще   (ставил -O3 на gcc 4.1)

Это сообщение отредактировал(а) MAKCim - 6.2.2007, 13:00

Это иллюзия  Просто чайники дольше ходят по граблям синтаксиса, и только потом переходят на грабли API 

Sun, 
а, в этом смысле согласен

Полный текст беседы со Страуструпом 1 декабря 2006 (PDF, 74 K)

Structured Programming with go to Statements. Donald Ervin Knuth (PDF, 2.9 M)

    ИМХО как и любой другой язык

 Интересно это о разработчиках какой страны? (Ну не знаю, где сейчас Страуструп живет...  )

 Ну не знаю ... не знаю

Это сообщение отредактировал(а) Sartorius - 6.2.2007, 16:42

под лежачий камень вода не течет - так и здесь...

но если есть идеи, то С++ любую из них реализует...

Преподавание информатики: потерянная дорога
Никлаус Вирт
Приветствие на открытии Международной конференции по преподаванию информатики ITiCSE
г. Аархус (Дания), 24 июня 2002 г.

 Какая разница какой знак приписать операции. В рапире вообще "->" для присвоения использовалось. ИМХО к любому более менее очевидному синтаксису достаточно легко привыкнуть.

По-моему очень многие компилеры, если и поддерживают рестрикт, то тем не менее просто его игнорируют. Также, как скажем инлайн. Лично я против неизкоуровневой оптимизации со стороны програмиста в высокоуровневых языках. Нефиг - пусть компилер сам старается   

Romikgy, недостатки в недоделанности на самом деле. Тот же языковой инклюд. Возможность нормального разделения объявления и реализации шаблонов (хотя, конечно, исходники, либо какой-то псевдокод все равно понадобится при компиляции). Спецификации исключений, так недружащие с шаблонами и вообще вызывающие много споров. Функциональная недоделанность стандартной библиотеки (по сравнению со многими другими языками). Отсутствие STL везде где только можно   В частности мне бы хотелось иметь стандартизированный прототип main, принимающий любой STL-совместимый контейнер с std::basic_string. Вообще наличие всяких WinMain вызывает мое недовольство. По мне так так ограничить по стандарту несоклько прототипов, а остальное запретить! Отсутствие естественных final(sealed). Да и вообще достаточно много.. Но повторюсь, это не потому что язык плохой - а просто недоделанный.


Уже было сказано, но потворюсь - не о тех плюсах думаете   delete - используется чрезвычайно редко. Либо в тривиальных случаях (когда выделение/освобождение в одном блоке), либо в библиотеках самрт-поинтеров   В сях да free забывать нельзя, но как бы разный профиль...



Не математикой единой...

В VC6 опция оптимизации, относящаяся к aliasing, ускорила одну из моих программ на 5%

GCC полностью поддерживает C99, а значит restrict, кроме того была включена оптимизация... вообщем непонятно, каким образом можно оптимизировать случаи, когда применяется restrict   

Все сразу и ничего вместе.

Кстати, а в C есть параметры по умолчанию?

есть