Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Религиозные войны > C++ - его сила и его слабости

Автор: Romikgy 5.2.2007, 12:24

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

Автор: skyboy 5.2.2007, 12:57

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

Автор: mr.DUDA 5.2.2007, 14:14

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

Автор: mr666 5.2.2007, 14:53

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

Автор: SergeCpp 5.2.2007, 15:32

http://technologyreview.com/InfoTech/17831/ 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 http://technologyreview.com/Infotech/17868/ The second part of our interview with Bjarne Stroustrup, the inventor of C++. Thursday, December 07, 2006 Там и комментариев много http://rsdn.ru/Forum?mid=2304517

Автор: Romikgy 5.2.2007, 15:44

SergeCpp, я знаю , что ты силен в С++ , но я не просил ссылок , я просил обсуждение! Цитата(skyboy @  5.2.2007,  11:57 ) сильно - шаблоны. понятно Цитата(mr666 @  5.2.2007,  13:53 ) Распространенность. эт ты к чему относишь? к сильной или слабой стороне?     PS чет сишники молчат

Автор: Sun 5.2.2007, 15:45

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

Автор: mr.DUDA 5.2.2007, 15:49

В бытность мою С++ программером временами приходилось использовать сишные макросы, не хватало возможности делать вложенные макросы, т.е. подставлять одни макроопределения в #defin-ы других. Хотя, как я понимаю, грамотнее не использовать макросы вообще, но... (к примеру для кроссплатформенных приложений они часто где юзаются) Добавлено @ 15:56  З.Ы, насчёт Цитата(mr.DUDA @  5.2.2007,  13:14 ) запутанная система подключения заголовочных файлов Комментарии будут ?  Пример №1: есть 2 класса должны "знать" друг о друге, но объявлены в разных .h-файлах. Пример: указатель на Parent и массив Child-ов, классы разнородные (не наследники). Как правильно подключить один .h к другому без колдунства с прототипами  ?    Пример №2: один заголовочный файл используется в нескольких других. Чтобы избежать повторных объявлений всего что есть в этом файле, приходится колдовать с #if/#endif в начале и конце файла, ставить разные #pragma once и т.п. Добавлено @ 16:00  Ещё один минус, возможно что спорный: сложность при отладке. При использовании таких возможностей языка, как шаблоны, typedef-ы, макросы, переопределения операторов, найти баг становится сложнее (к рантаймовым багам добавляются неявные ошибки времени компиляции - неправильный вывод типа, подстановка и т.п.)

Автор: Beltar 5.2.2007, 16:12

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

Автор: mr.DUDA 5.2.2007, 16:25

Цитата(Beltar @  5.2.2007,  15:12 ) Кстати только у меня из несишников чуство, что сишники только тем и занимаются, что пишут шаблоны, собственные строковые классы и перегружают операторы? И МЕНЕДЖЕРЫ ПАМЯТИ !!!

Автор: Sun 5.2.2007, 16:35

Цитата(Beltar @  5.2.2007,  13:12 ) Кстати только у меня из несишников чуство, что сишники только тем и занимаются, что пишут шаблоны, собственные строковые классы и перегружают операторы? smile   Цитата(mr.DUDA @  5.2.2007,  13:25 ) И МЕНЕДЖЕРЫ ПАМЯТИ !!!  smile  smile  smile  smile   Одни словом -  занимаются настоящим программированием, в отличие от жабистов, дотнетчиков и драг-энд-дроп программистов

Автор: SergeCpp 5.2.2007, 16:41

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

Автор: Romikgy 5.2.2007, 16:49

Цитата(Sun @  5.2.2007,  14:45 ) Да нету у него слабостей, сила одна!  имхо чушь, иначе был бы он идеален и его юзали бы все, а такого нет , юзают много чего, вывод, значит твоя фраза не есть истина, и мистер Дуда много чего привел! mr.DUDA, сиба , интересные мысли  Кса чет не вижу реальных представлений силы? тем более шаблоны , и их использование понизилось в статусе силы....

Автор: MAKCim 5.2.2007, 17:19

Цитата(Beltar @  5.2.2007,  16:12 ) Кстати только у меня из несишников чуство, что сишники только тем и занимаются, что пишут шаблоны, собственные строковые классы и перегружают операторы?  сишники не могут делать этого по определению

Автор: Romikgy 5.2.2007, 17:42

Цитата(MAKCim @  5.2.2007,  16:19 ) сишники не могут делать этого по определению почему? хоть один сишник забрел

Автор: skyboy 5.2.2007, 17:47

Цитата(Romikgy @  5.2.2007,  16:42 ) Цитата(MAKCim @  5.2.2007,  16:19 ) сишники не могут делать этого по определению почему? Ибо С != С++

Автор: MAKCim 5.2.2007, 17:47

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

Автор: Любитель 5.2.2007, 17:58

mr.DUDA, во всём этом виноват не C++, а его препроцессор. В "Дизайн и эволюция C++" Бъярни писал, что когда-то предлагал сделать инклюд-конструкцию на уровне языка, естественно более продвинутую. По непонятным для меня причинам комитет это отверг (как будет в будущем - не знаю). Далее - по сабжу написаны плюсы => говорим про плюсы. А в чём сила плюсов? В том, что плющит конкретно.   А если серьёзно - дял меня в неповторимом стиле программирования, в некоей атмосфере что ли. Я не против многих языков, рассисткой ненависти не испытываю, но плюсы... (см. подпись). Недостатков - много, не спорю. Плюсы разрабатывались не пойми как. Самое интересное, что всё таки популрность завоевали обалденную. Цитата(mr.DUDA @  5.2.2007,  16:25 ) И МЕНЕДЖЕРЫ ПАМЯТИ !!!   Ещё чего!   Добавлено @ 18:02  Цитата(MAKCim @  5.2.2007,  17:47 ) делаем встроенный оператор include, расширяем шаблоны (чтобы не хотелось макросами пользоваться), стандартизуем тип файла, который можно включить оператором include (т. е если в нем есть кроме описаний - код - ошибка (кроме inline функций)), делаем template export и убираем препроцессор   А условная компиляция?

Автор: Kuvaldis 5.2.2007, 18:03

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

Автор: MAKCim 5.2.2007, 18:04

Цитата А условная компиляция?  все делаем в виде операторов Добавлено @ 18:05  Цитата(Kuvaldis @  5.2.2007,  18:03 ) Скорее бы это в стандарт! это уже в стандарте только вот реализовать это сложно по-моему только 1 компилятор на сегодня способен на export

Автор: Любитель 5.2.2007, 18:10

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

Автор: Sun 5.2.2007, 18:49

Цитата(Romikgy @ 5.2.2007,  13:49) имхо чушь, иначе был бы он идеален и его юзали бы все, а такого нет , юзают много чего, вывод, значит твоя фраза не есть истина, и мистер Дуда много чего привел! mr.DUDA, сиба , интересные мысли  Кса чет не вижу реальных представлений силы? тем более шаблоны , и их использование понизилось в статусе силы.... Так его только и юзают для разработки серьезного ПО. Тут можно в принципе даже не отделять С от С++, так как С код компилирутеся С++ компилятором и можно смешивать С и С++. Всё остальное - прикладное программрование на уровне VB.  Кто привык использовать инклюды препроцессора никакого дискомфорта по их поводу не испытывает. Есть стандартные решения для корректного инклюда. Просто вы привыкли чтобы за вас всё делал визард или фреймворк, вот и боитесь лишний раз напречься    Насчет шаблонов я вообще не понял о чём речь? Они то в С++ уже есть не первый десяток лет. А в  Java и C# появились сравнительно недавно. И кто их понизил в статусе силы, не вы ли случайно?    Вот когда добьетесь производительности от программы написанной на каком нибудь другом языке, отличном от С/С++ (ассемблер не предлагать), тогда я сниму перед вами шляпу. А так я готов терпеть все его "неудобства", зато они окупаются сторицей

Автор: Любитель 5.2.2007, 18:52

Цитата(Sun @  5.2.2007,  18:49 ) А в  Java и C# появились сравнительно недавно. Это клевета!!! Нет там шаблонов. Дженерики != шаблоны. Полное !=.   Никакого метапрограммирования они не несут, лишь некоторое обобщение, да и то и в яве, и в шарпе, если не ошибаюсь, только для классов. Никакого автоопределения типов шаблонов - нет. Нельзя это сравнивать с шаблонами. Я не говорю, что шарп с явой из-за этого хуже - нет, ни в коем случае, но сранивать дженерики и шаблоны - не позволю!!!

Автор: Sun 5.2.2007, 18:55

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

Автор: Любитель 5.2.2007, 18:56

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

Автор: LSD 5.2.2007, 18:59

Цитата(Sun @  5.2.2007,  18:49 ) Вот когда добьетесь производительности от программы написанной на каком нибудь другом языке, отличном от С/С++ (ассемблер не предлагать), тогда я сниму перед вами шляпу. Fortran подойдет?

Автор: Любитель 5.2.2007, 19:01

LSD, только математика. Эффективное управление памятью - сомневаюсь. Но собсно говоря и плюсы не совсем дял того создавались. Есть Си - хороший по своему, но по идеолгоии далёкий от плюсов. Добавлено @ 19:04  [offtop] млин что-то я совсем - очепятки горой идут    [/offtop]

Автор: LSD 5.2.2007, 19:31

Цитата(Любитель @  5.2.2007,  19:01 ) только математика. Эффективное управление памятью - сомневаюсь. Но собсно говоря и плюсы не совсем дял того создавались. Есть не так много вещей кроме математики, способных загрузить процессор на 100%. И вообще какое это имеет отношение к тому, что я написал?

Автор: esperant0 5.2.2007, 20:27

Цитата(LSD @ 5.2.2007,  19:31)  Есть не так много вещей кроме математики, способных загрузить процессор на 100%. И вообще какое это имеет отношение к тому, что я написал? Есть бесконечное количество вещей кроме математики способных загрузить проц на 100% С точки зрения вычислимости  C=C++

Автор: MAKCim 5.2.2007, 20:31

Цитата(esperant0 @  5.2.2007,  20:27 ) С точки зрения вычислимости  C=C++ да я думаю С = C++ = Pascal = Delphi = ... (на одной архитектуре) разница будет только в "хорошести" компиляторов

Автор: nerezus 5.2.2007, 20:31

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

Автор: MAKCim 5.2.2007, 20:39

Цитата(nerezus @  5.2.2007,  20:31 ) Не нравятся указатели. знак * ?

Автор: Void 5.2.2007, 21:01

Цитата(MAKCim @  5.2.2007,  22:31 ) С = C++ = Pascal = Delphi = ... (на одной архитектуре) разница будет только в "хорошести" компиляторов  Однако возможности компилятора по оптимизации в некоторой мере зависят и от свойств языка. Пример: введение restrict в C99.

Автор: Alexeis 5.2.2007, 21:08

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

Автор: Sartorius 5.2.2007, 21:08

Цитата С = C++ = Pascal = Delphi = ... (на одной архитектуре) разница будет только в "хорошести" компиляторов  Это что значит? По performance что ли? Не думаю. Чем более формален язык -  тем эффективние код. Поэтому в ряду ASM - FORTRAN - C - C++ - Pascal скорость кода убывает Цитата Не нравятся указатели.   Испльзуйте smart pointers.... Контроль за памятью - это не забота языка и к языку никакого отношения не имеет. Это уже библиотеки. База у С - достаточная. Компилятор должен обеспечивать только корректное обращение по указанному адресу.

Автор: MAKCim 5.2.2007, 21:17

Sartorius,  Цитата(esperant0 @  5.2.2007,  20:27 ) С точки зрения вычислимости  C=C++  Цитата(MAKCim @  5.2.2007,  20:31 ) да я думаю С = C++ = Pascal = Delphi = ... (на одной архитектуре) разница будет только в "хорошести" компиляторов Цитата(Sartorius @  5.2.2007,  21:08 ) Чем более формален язык -  тем эффективние код. любой язык описан формально Цитата(Sartorius @  5.2.2007,  21:08 ) Поэтому в ряду ASM - FORTRAN - C - C++ - Pascal скорость кода убывает да ты что? все зависит от компилятора в большинстве случаев код плохого программиста на ассемблере будет хуже кода хорошего С-компилятора И вообще, что за понятие такое: скорость кода?

Автор: Sartorius 5.2.2007, 21:23

Цитата все зависит от компилятора в большинстве случаев код плохого программиста на ассемблере будет хуже кода хорошего С-компилятора Ясное дело при прочих равных условиях    Цитата любой язык описан формально  Да.. ерунду сказал. ... Чем ниже уровень языка - тем эффективнее код. ЗЫ Что за вычислимость такая? Можно говорить о вычислимости выражения и т.п. А код здесь причем?

Автор: MAKCim 5.2.2007, 21:28

Цитата(Sartorius @  5.2.2007,  21:23 ) ЗЫ Что за вычислимость такая? Можно говорить о вычислимости выражения и т.п. А код здесь причем? ну видно имелось в виду что-то типа этого Код int a, b, c, d, e, f = 9876; int x = (a + b) * (d - e) / f - 1;

Автор: esperant0 5.2.2007, 21:39

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

Автор: Romikgy 5.2.2007, 21:47

1. я не хотел делить С и С++, имхо это практически одно и тоже (хотя различий хватает), и в данном топике , я бы хотел увидеть обсуждения С++ 2. сравнивать языки друг с другом , конечно хорошо , но хотелось бы видет именно недостатки и достоинства С++ Цитата(MAKCim @  5.2.2007,  16:47 ) единственная проблема С++ - препроцессор точнее можно? Цитата(Любитель @  5.2.2007,  16:58 ) Недостатков - много, не спорю. по подробнее плз Цитата(nerezus @  5.2.2007,  19:31 ) Не нравятся указатели.  чем можно узнать? Цитата(Alexeis @  5.2.2007,  20:08 ) главная проблема плюсов это утечки памяти да , конечно запутано , но это дело привычки имхо , и очепяток    Цитата(Void @  5.2.2007,  20:01 ) Пример: введение restrict в C99.  чет я не понял чем эта вещь хороша?

Автор: Daevaorn 5.2.2007, 21:48

Цитата(Alexeis @  5.2.2007,  22:08 ) Насколько мне известно, главная проблема плюсов это утечки памяти.  это проблема у тех кто не пользуется smart pointer'ами. Я уже не помню когда писал сам "delete"/"delete[]".

Автор: nerezus 5.2.2007, 22:04

Цитата знак * ?  Нет, сама необходимость их использовать. Цитата ИМХО указатели это вообще прошлый век, и пора от них совсем отказываться, как от плохого стиля программирования, такого как GoTo и т.д.  +1 =) чисто интуитивно ) Цитата Испльзуйте smart pointers  А можно поподробнее?

Автор: Romikgy 5.2.2007, 22:10

Цитата(nerezus @  5.2.2007,  21:04 ) Нет, сама необходимость их использовать.   имхо STL можно vector    Цитата(nerezus @  5.2.2007,  21:04 ) А можно поподробнее? тоже интересно послушать  кса и некто не говорит о сильных сторонах С++

Автор: Daevaorn 5.2.2007, 22:12

Цитата(Romikgy @  5.2.2007,  23:10 ) кса и некто не говорит о сильных сторонах С++  Они априори ясны разумным людям

Автор: Void 5.2.2007, 22:28

Цитата(Romikgy @  5.2.2007,  23:47 ) Пример: введение restrict в C99.  чет я не понял чем эта вещь хороша?  Позволяет указать компилятору, что данный указатель… э-э… не подвержен http://en.wikipedia.org/wiki/Aliasing_(computing), тем самым позволяя более агрессивные оптимизации.

Автор: Romikgy 5.2.2007, 22:33

Цитата(Daevaorn @  5.2.2007,  21:12 ) Они априори ясны разумным людям здесь не все настолько разумны! плз по буквенно и медленно , так что бы поняли все , включая чайников!

Автор: Sartorius 5.2.2007, 22:33

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

Автор: skyboy 5.2.2007, 22:35

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

Автор: Romikgy 5.2.2007, 22:40

т.е.  Цитата(Void @  5.2.2007,  21:28 ) restrict это плюс этого языка Цитата(Void @  5.2.2007,  21:28 ) более агрессивные оптимизации. по направлению оптимизации?!

Автор: Void 5.2.2007, 23:09

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

Автор: Romikgy 5.2.2007, 23:13

Цитата(Void @  5.2.2007,  22:09 ) скорее костыль, заплатка. т.е. это минус?

Автор: Void 5.2.2007, 23:21

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

Автор: Beltar 5.2.2007, 23:46

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

Автор: Romikgy 6.2.2007, 00:01

Цитата(Void @  5.2.2007,  22:21 ) ты можешь отвлечься от понятий абсолютного добра и зла?  гна, ясности хоцца Цитата(Void @  5.2.2007,  22:21 ) Это плюс, потому что Цитата(Void @  5.2.2007,  22:21 ) Минус дизайну языка, что для этого хмммм как все запутано ...

Автор: mr.DUDA 6.2.2007, 10:33

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

Автор: Sun 6.2.2007, 12:31

Цитата(mr.DUDA @  6.2.2007,  07:33 ) Вопрос тут не в том, "как правильно нужно делать и почему", а в том "почему в С++ приходится подстраиваться под неудобный препроцессор" smile   Он не неудобен - он прост. Не нравтяся инклюды - пиши код в одном текстовом файле. Не нравится препроцессор - не используй. Это всё вещи опциональные и вспомагательные. Можно в конце концов свой препроцессор написать, который будет соединять тексты так, как вам удобно.  Зато вы хоть знате как всё устроено и как всё работает а некоторую сложность использования С++ я отношу также к его сильной стороне, потому что в среде С++ чайников несравнимо меньше чем среди других популярных языков.

Автор: MAKCim 6.2.2007, 12:44

Цитата(Sun @  6.2.2007,  12:31 ) Не нравтяся инклюды - пиши код в одном текстовом файле. ну-ну    теоретически да, а практически... Цитата(Sun @  6.2.2007,  12:31 ) Зато вы хоть знате как всё устроено и как всё работает в смысле?

Автор: Sun 6.2.2007, 12:54

Цитата(MAKCim @  6.2.2007,  09:44 ) в смысле?  В прямом. Берётся код программы компилируется в объектный код и линковщиком собирается в исполняемый бинарный код. Все можно посмотреть как оно работает в ассемблере, какие регистры заполняются, что по какому адресу лежит, какие API функции вызываются - красота одним словом. Никаких тебе чёрных ящиков с байткодом или дебрями рантайма.

Автор: MAKCim 6.2.2007, 12:57

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

Автор: LSD 6.2.2007, 12:57

Цитата(Sun @  6.2.2007,  12:31 ) Зато вы хоть знате как всё устроено и как всё работает а некоторую сложность использования С++ я отношу также к его сильной стороне, потому что в среде С++ чайников несравнимо меньше чем среди других популярных языков. Это иллюзия  Просто чайники дольше ходят по граблям синтаксиса, и только потом переходят на грабли API

Автор: MAKCim 6.2.2007, 12:58

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

Автор: SergeCpp 6.2.2007, 16:16

Цитата(Is C++ too hard for most programmers?) It shouldn’t be. C++ has become “expert friendly,” partly by design and partly because the notion of professionalism hasn’t taken root in the software development world. The best uses of C++ involve deliberate design. You design classes to represent the notions of your application, you organize those classes into hierarchies, you express your algorithms precisely and abstractly (no, that “and” is not a mistake), you use libraries, you build libraries, you devise error handling and resource management strategies and express them in code. The result can be beautiful, efficient, maintainable, etc. However, it’s not just sitting down and writing a series of statements directly manipulating characters, integers, and floating point numbers. Nor is it simply plugging a few pieces of code into a huge corporate framework. The demands of using C++ well are mainly maturity of system designers and understanding of design and programming technique. They are not primarily demands on the understanding of obscure programming language features. In that sense, the critics are right: Not everybody should write C++, but then I never did claim they should. I do not know if too many people use C++ today, but many do, many more than in the mid-90s, and the use of C++ is still growing in some areas. Obviously, C++ wasn’t too difficult for quite a few people. C++ is designed to allow you to express ideas, but if you don’t have ideas or don’t have any clue about how to express them, C++ doesn’t offer much help. In that, C++ is not that different from other languages, but it is different from languages/systems/tools/frameworks designed to make it easy to express specific things in a specific domain. The relatively small size of the C++ standard library – primarily reflecting the lack of resources in the ISO C++ standards committee – compared with the huge corporate libraries can be a real disadvantage for C++ developers compared to users of proprietary languages. Given that C++ is designed as a language for writing and using libraries, too many C++ programmers use too few libraries and reinvent the wheel too often. It is far easier to use a good library (such as the C++ STL) than to design and implement it. Цитата(In retrospect. Wasn't the decision to trade off programmer efficiency and security and and software reliability in exchange for runtime performance a fundamental mistake?) Well, I don’t think I made such a tradeoff. I want elegant and efficient code. Sometimes I get it. The efficiency vs. correctness, efficiency vs. programmer time, efficiency vs. high level, etc. dichotomies are largely bogus. What I did do was to design C++ as a systems programming language first of all: I wanted to be able to write device drivers, embedded systems, and other code that needed to use hardware directly. I still want that. Next, I wanted C++ to be a good language for designing tools. That required flexibility and performance, but also the ability to express elegant interfaces. My view was that to do higher level stuff, to build complete applications, you first needed to buy, build, or borrow libraries providing appropriate abstractions. Often, when people have trouble with C++, the real problem is that they don’t have appropriate libraries available – or that they can’t find the libraries that are available. Other languages have tried to more directly support high-level applications. That (also) works, but often that support comes at the cost of specialization. Personally, I wouldn’t design a tool that could do only what I wanted – I aim for generality. Цитата(...) In theory, the answer is simple: educate our software developers better, use more appropriate design methods, and design for flexibility and for the long haul. Reward correct, solid, and safe systems. Punish sloppiness. In reality, that’s essentially impossible. People want new fancy gadgets right now and reward people who deliver them cheaply, buggy, and first. People don’t want inconvenience, don’t want to learn new ways of interacting with their computers, don’t want delays in delivery, and don’t want to pay extra for quality (unless it’s obvious up front – and often not even then). Even major security problems and crashes seem not to make people willing to change their use of software – and without changes in user behavior, the software suppliers are unlikely to change. http://research.att.com/~bs/MIT-TR-original.pdf (PDF, 74 K)

Автор: SergeCpp 6.2.2007, 16:34

Цитата(Alexeis @  5.2.2007,  23:08 ) ...от плохого стиля программирования, такого как GoTo... http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pdf (PDF, 2.9 M)

Автор: Sartorius 6.2.2007, 16:35

Цитата but if you don’t have ideas or don’t have any clue about how to express them, C++ doesn’t offer much help     ИМХО как и любой другой язык Цитата In theory, the answer is simple: educate our software developers better  Интересно это о разработчиках какой страны? (Ну не знаю, где сейчас Страуструп живет...  ) Цитата People don’t want inconvenience, don’t want to learn new ways of interacting with their computers  Ну не знаю ... не знаю

Автор: Rodman 6.2.2007, 16:39

Цитата(Sartorius @  6.2.2007,  15:35 ) but if you don’t have ideas or don’t have any clue about how to express them, C++ doesn’t offer much help под лежачий камень вода не течет - так и здесь... но если есть идеи, то С++ любую из них реализует...

Автор: SergeCpp 7.2.2007, 12:44

http://www.inr.ac.ru/~info21/texts/2002-06-Aarhus/ru.htm Никлаус Вирт Приветствие на открытии Международной конференции по преподаванию информатики ITiCSE г. Аархус (Дания), 24 июня 2002 г. Цитата Вспоминается рассказ Э.Дейкстры о его ночном кошмаре после чтения спецификаций нового языка программирования PL/1 в 1965 г. Ему представилось, что в будущем программирование приравняют к выучиванию PL/1, а информатику — к овладению OS/360 JCL <речь идет о языке программирования и языке управления заданиями для компьютеров фирмы IBM, печально известных своим крайне неудачным дизайном; российские программисты старшего поколения помнят, что это такое, по опыту работ на ЕС ЭВМ — прим. перев.>. Достаточно заменить PL/1 на C++ или Java, а JCL — на Windows или Linux, и вы чудесным образом перенесетесь в настоящее. Цитата Порочный круг был однажды разорван, когда распространился Паскаль. При поддержке коллег-единомышленников и в упорном противостоянии рутинерам, Паскаль распространился в учебных заведениях и проник в индустрию. Это произошло, несмотря на могучую конкуренцию со стороны индустрии и других больших организаций, в соперничестве с языками PL/1, Алгол 68 и Ада. Однако наследники Паскаля, существенно его превосходившие, Модула-2 и Оберон, не получили должного внимания среди преподавателей, и сами пали перед лицом самого недостойного из соперников — C. Самого недостойного, т.к. в этом языке были нарушены все открытые к тому времени принципы серьезного программирования. Он запутывает студентов, допуская разный смысл для x = y и y = x и принуждая всех писать x = = y вместо обычного x = y. Только за одни эти пороки он заслуживает изгнания из учреждений образования. Однако сей уродливый синтаксис был целиком воспроизведен в языке Java, принятие которого академическим сообществом произошло, отчасти благодаря этой преемственности.

Автор: Sartorius 7.2.2007, 13:01

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

Автор: Любитель 7.2.2007, 18:17

Цитата(MAKCim @  6.2.2007,  12:57 ) правда, вот сейчас ради интереса, решил "поиграться" с restrict и разницы между "с restrict" и "без restrict" не заметил вообще  По-моему очень многие компилеры, если и поддерживают рестрикт, то тем не менее просто его игнорируют. Также, как скажем инлайн. Лично я против неизкоуровневой оптимизации со стороны програмиста в высокоуровневых языках. Нефиг - пусть компилер сам старается    Romikgy, недостатки в недоделанности на самом деле. Тот же языковой инклюд. Возможность нормального разделения объявления и реализации шаблонов (хотя, конечно, исходники, либо какой-то псевдокод все равно понадобится при компиляции). Спецификации исключений, так недружащие с шаблонами и вообще вызывающие много споров. Функциональная недоделанность стандартной библиотеки (по сравнению со многими другими языками). Отсутствие STL везде где только можно   В частности мне бы хотелось иметь стандартизированный прототип main, принимающий любой STL-совместимый контейнер с std::basic_string. Вообще наличие всяких WinMain вызывает мое недовольство. По мне так так ограничить по стандарту несоклько прототипов, а остальное запретить! Отсутствие естественных final(sealed). Да и вообще достаточно много.. Но повторюсь, это не потому что язык плохой - а просто недоделанный. Цитата(Alexeis @  5.2.2007,  21:08 ) Сишники будут активно возмущаться, но я все скажу. ИМХО указатели это вообще прошлый век, и пора от них совсем отказываться, как от плохого стиля программирования, такого как GoTo и т.д. Уже было сказано, но потворюсь - не о тех плюсах думаете   delete - используется чрезвычайно редко. Либо в тривиальных случаях (когда выделение/освобождение в одном блоке), либо в библиотеках самрт-поинтеров   В сях да free забывать нельзя, но как бы разный профиль... Цитата(LSD @  5.2.2007,  19:31 ) Есть не так много вещей кроме математики, способных загрузить процессор на 100%. И вообще какое это имеет отношение к тому, что я написал?  Цитата(Sun @  5.2.2007,  18:49 ) Вот когда добьетесь производительности от программы написанной на каком нибудь другом языке, отличном от С/С++ (ассемблер не предлагать), тогда я сниму перед вами шляпу Не математикой единой...

Автор: SergeCpp 7.2.2007, 20:47

В VC6 опция оптимизации, относящаяся к aliasing, ускорила http://sergecpp.mylivepage.ru/file/1/701/ на 5%

Автор: MAKCim 7.2.2007, 21:19

Цитата(Любитель @  7.2.2007,  18:17 ) По-моему очень многие компилеры, если и поддерживают рестрикт, то тем не менее просто его игнорируют. Также, как скажем инлайн. Лично я против неизкоуровневой оптимизации со стороны програмиста в высокоуровневых языках. Нефиг - пусть компилер сам старается GCC полностью поддерживает C99, а значит restrict, кроме того была включена оптимизация... вообщем непонятно, каким образом можно оптимизировать случаи, когда применяется restrict

Автор: Beltar 8.2.2007, 13:22

Цитата но если есть идеи, то С++ любую из них реализует... Все сразу и ничего вместе. Кстати, а в C есть параметры по умолчанию?

Автор: Romikgy 8.2.2007, 14:18

Цитата(Beltar @  8.2.2007,  12:22 ) Кстати, а в C есть параметры по умолчанию? есть

Автор: Void 8.2.2007, 16:20

А вот именованных параметров (лично мне) не хватает и в C++, и в Delphi, и в Java, и в C#…

Автор: Daevaorn 8.2.2007, 17:40

Цитата(Romikgy @  8.2.2007,  15:18 ) есть  Не совсем. Есть скорей всего только в С99. Ну и в С++ конечно. Цитата(Void @  8.2.2007,  17:20 ) А вот именованных параметров (лично мне) не хватает и в C++, и в Delphi, и в Java, и в C#…  за-то в С++ они почти красиво реализуются средствами языка.

Автор: Beltar 8.2.2007, 18:13

Цитата именованных параметров А что это?

Автор: MAKCim 8.2.2007, 18:58

Цитата(Romikgy @  8.2.2007,  14:18 ) есть  нету Цитата(Daevaorn @  8.2.2007,  17:40 ) Есть скорей всего только в С99 нету

Автор: Romikgy 8.2.2007, 19:05

Цитата(MAKCim @ 8.2.2007,  17:58) Цитата(Romikgy @  8.2.2007,  14:18 ) есть  нету Цитата(Daevaorn @  8.2.2007,  17:40 ) Есть скорей всего только в С99 нету Я имел ввиду С++ , а не просто С просто не обратил внимания на то что в том посте без плюсов PS многие здесь программируют на чистом си без плюсов?

Автор: Void 8.2.2007, 19:06

Beltar Код # это вызов функции somefunction(x, arg1 = y, arg2 = z) Помогает, когда у функции много параметров, а указать надо лишь часть. И читается в таком случае лучше.

Автор: Beltar 8.2.2007, 19:27

Но в Delphi тоже можно: function f(X:Integer;Y:Integer=1):Integer; И вызывать можно f(x) и f(x,y). В чем разница?

Автор: Void 8.2.2007, 19:29

Попробую словами: при вызове функции опциональные (строго говоря, не только) аргументы можно указывать в произвольном порядке с помощью синтаксиса <имя параметра> = <значение>.

Автор: Beltar 8.2.2007, 20:14

Теперь понятно.

Автор: Romikgy 8.2.2007, 20:52

Цитата(Void @  8.2.2007,  18:29 ) Попробую словами: при вызове функции опциональные (строго говоря, не только) аргументы можно указывать в произвольном порядке с помощью синтаксиса <имя параметра> = <значение>.  пример можно

Автор: SergeCpp 8.2.2007, 20:58

Про именованные аргументы Страуструп писал в http://research.att.com/~bs/dne.html Это было предложение Роланда Хартингера Причина отклонения: группа по расширениям единодушно решила, что предложение не даёт почти ничего нового, приведёт к несовместимости с существующим кодом и будет способствовать распространению неудачного стила программирования Там есть и альтернативы именованным аргументам, например, дополнительные типы для представления наиболее типичных вариантов Void, а ну марш покупать и читать D&E!

Автор: Void 8.2.2007, 21:36

Я Страуструпа уважаю (а вопросы обратной совместимости уважать себя просто заставляют  ), но подход с реализацией всего что только можно через библиотеки, не трогая ядро языка, и то, во что он [подход] превратил нынешний C++, как-то не очень… На когда-то желанный C++0x теперь приходится смотреть с опаской.

Автор: SergeCpp 8.2.2007, 21:43

http://www.stepanovpapers.com/notes.pdf (примерно 900 K)

Автор: Любитель 8.2.2007, 23:28

Насчёт именованных параметров - никогда не будет на уровне языка хотя бы потому, что мы имеем права (и некоторые так делают) в хейдере называть параметры по одному, а в сорсе - по другому. Скажем типично (хотя я не приветствую): Код // my_func.h void my_func(int height, int width); // my_func.cpp void my_func(int h, int w) {     // ... } Естьhttp://boost.org/libs/parameter/doc/html/index.html. Не вглядывался в реализацию, но использование достаточно приятно, правда редко нужно. Насчёт рестрикта - ещё пару слов. Как таковой он должен применяться не к конкретному указателю, а к их парам. Если функция принимает два параметра, то здесь всё понятно (хотя нелогично к какому именно указателю ставить рестрикт). Но допустим, что у функции три параметра. Между двумя первыми гарантировано соблюдение рестрикта, а вот третий может "вклиниться" в любой из первых двух. Вполне возможно, что однако (теоретически) возможна оптимизация. Возможно, что третий указатель, нужен для просто задания элемента (не из массива). То есть существующий синтаксис рестрикта нелогично описывает ситуацию. Получается мы гарантируем отсутствие алиасов с любыми другими указателями - это возможно очень редко. Кстати, Цитата(MAKCim @  7.2.2007,  21:19 ) GCC полностью поддерживает C99, а значит restrict, Пддержка не означает использование. Компилер вправе поддерживать его на уровне игнорирования (как это обычно бывает с инлайн). Если функция не экспортируется, то глобальная оптимизация зачастую позволяет выявить отсутствие алиасов (и заюзать оптимизацию) без подсказок с нашей стороны (кроме подсказки в опциях компилера   ), что на мой взгляд лучше.

Автор: Artemios 9.2.2007, 11:19

Цитата(Romikgy @  8.2.2007,  21:52 ) пример можно  Код >>> def f(a1=1,a2=2,a3=3,a4=4,a5=5): ...         return a1+a2+a3+a4+a5 ... >>> f(a3=25) 37 >>> f() 15 >>> f(3,4,a5=10) 24 >>> f(a5=1,a3=0,a1=2) 9 >>>

Автор: MAKCim 9.2.2007, 18:19

Цитата(Любитель @  8.2.2007,  23:28 ) Компилер вправе поддерживать его на уровне игнорирования (как это обычно бывает с инлайн). какой-то странный уровень поддержки    если что то игнорируется в GCC (например export), то warning соответствующий появляется

Автор: Любитель 9.2.2007, 21:02

Но ведь с инлайн именно так часто получается. Или register-переменные (которыми никто не пользуется   ) -  боюсь, что компилер не обратит внимание на ваше требование. В то же время для других (обычных) переменных он при желании возможно разместит их в регистрах.

Автор: SergeCpp 9.2.2007, 21:36

Цитата(Любитель @  9.2.2007,  23:02 ) ...register-переменные (которыми никто не пользуется)... Последняя stable версия Perl (5.8.8). Начало одной из функций файла util.c Код char * Perl_fbm_instr(pTHX_ unsigned char *big, register unsigned char *bigend, SV *littlestr, U32 flags) {     register unsigned char *s;     STRLEN l;     register const unsigned char *little     = (const unsigned char *)SvPV_const(littlestr,l);     register STRLEN littlelen = l;     register const I32 multiline = flags & FBMrf_MULTILINE;     if ((STRLEN)(bigend - big) < littlelen) {     if ( SvTAIL(littlestr)          && ((STRLEN)(bigend - big) == littlelen - 1)          && (littlelen == 1          || (*big == *little &&              memEQ((char *)big, (char *)little, littlelen - 1))))         return (char*)big;     return Nullch;     } //... Дата модификации файла: 9 января 2006

Автор: Sartorius 9.2.2007, 21:40

Мнда. Многовато чего-то регистров. А ведь еще и результаты промежуточные где то хранить нада....

Автор: MAKCim 9.2.2007, 21:46

Цитата(Любитель @  9.2.2007,  21:02 ) Но ведь с инлайн именно так часто получается. Или register-переменные (которыми никто не пользуется  smile ) -  боюсь, что компилер не обратит внимание на ваше требование всегда есть Код __attribute__((always_inline)) и Код register int a __asm__("eax") = 7; для таких случаев Добавлено @ 21:48  Цитата(Sartorius @  9.2.2007,  21:40 ) Мнда. Многовато чего-то регистров. А ведь еще и результаты промежуточные где то хранить нада.... так 2 регистра еще есть   (в худшем случае)

Автор: Любитель 9.2.2007, 22:46

MAKCim, я, конечно понимаю твои взгляды, но не надо всё же равнять gcc и стандартные плюсы

Автор: MAKCim 9.2.2007, 23:08

Цитата(Любитель @  9.2.2007,  22:46 ) MAKCim, я, конечно понимаю твои взгляды, но не надо всё же равнять gcc и стандартные плюсы нет, подожди В С++ по стандарту inline функция - есть подстановочная функция, а register переменные - переменные в регистрах т. е любой компилятор номинально обязан все inline функции подставлять непосредственно (благо ограничений в отличие от register переменных нет) и располагать register переменные в регистрах за исключением ситуации, когда отсутствуют свободные регистров, а заниматься оптимизацией должен при включенной оптимизации т. е я хочу сказать, что в обычном режиме он должен тупо следовать спецификации языка, а со включенной оптимизацией - заниматься эвристикой и прочим шаманством

Автор: Void 9.2.2007, 23:41

MAKCim 7.1.2/2 Цитата The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the usual function call mechanism. An implementation is not required to perform this inline substitution at the point of call; [...] Между предпочтением и обязательством есть разница. Добавлено @ 23:42  7.1.1/3 Цитата A register specifier has the same semantics as an auto specifier together with a hint to the implementation that the object so declared will be heavily used. [Note: the hint can be ignored and in most implementations it will be ignored if the address of the object is taken. —end note]

Автор: Любитель 10.2.2007, 00:45

Что бегло нашёл по restrict: Код The intended use of the restrict qualifier (like the register storage class) is to promote optimization Добавлено @ 00:45  MAKCim, кстати выше я говорил про __atribute__ и __asm__.

Автор: SergeCpp 10.2.2007, 01:09

Вот выдержки из довольно старой статьи Денниса Ритчи (1988, http://www.astro.princeton.edu/~rhl/dmr-on-noalias.html) Цитата       `Noalias' is much more dangerous; the committee is planting timebombs that are sure to explode in people's faces.  Assigning an ordinary pointer to a pointer to a `noalias' object is a license for the compiler to undertake aggressive optimizations that are completely legal by the committee's rules, but make hash of apparently safe programs.  Again, the problem is most visible in the library; parameters declared `noalias type *' are especially problematical.        In order to write such a library routine using the new parameter declarations, it is in practice necessary to violate 3.3.4: `A pointer to a noalias-qualified type ... may be converted to ... the non-noalias-qualified type.  If the pointed to object is referred to by means of the converted pointer, the behavior is undefined.' Thus, the problem that occurs with `const' is now much worse; there are no interesting and legal uses of strchr.        How do you code a routine whose prototype specifies a noalias pointer?  If you fail to violate 3.3.4, but instead try to rewrite the declarations of temporary variables to make them agree in type with parameters, it becomes hard to be sure that the routine works.  Consider the specification of strtok:      char *strtok(noalias char *s1, noalias const char *s2); It retains a static pointer to its writable, `noalias' first argument.  Can you be sure that this routine can be made safe under the rules?  I have studied it, and the answer is conditionally yes, provided one accepts certain parts of the Standard as gospel (for example that `noalias' handles will not be synchronized at certain times) while ignoring other parts.  It is a very dodgy thing.  For other routines, it is certain that complete rewriting is necessary: qsort,  for example, is full of pointers that rove the argument array and change it here and there.  If these local pointers are qualified with `noalias,' they may all be pointing to different virtual copies of parts of the array; in any event, the argument itself may have a virtual object that might be completely untouched by the attempt to sort it.        The `noalias' rules have the assignment and cast restrictions backwards.  Assigning a plain pointer to a const-qualified pointer (pc = p) is well-defined by the rules and is safe, in that it restricts what you can do with pc.  The other way around (p = pc) is forbidden, presumably because it creates a writable access path to an unwritable object. With `noalias,' the rules are the same (pna = p is OK, p = pna is forbidden), but the realistic safety requirements are completely different.  Both of these assignments are equally suspicious, in that both create two access paths to an object, one manifestation of which might be virtual.        Here is another way of observing the asymmetry: the presence of `const type *' in a parameter list is a useful piece of interface information, but `noalias type *' most assuredly is not.  Given the declaration      memcpy(noalias void *s1, const noalias void *s2, size_t n); what information can one glean from it?  Some committee members apparently believe that it conveys either to the reader or to the compiler that the routine is safe, provided that the strings do not overlap.  They are mistaken. Perhaps the committee's intent is not reflected in the current words of the Standard, but I can find nothing there that justifies their belief.  The rules (page 65, lines 19-20) specify `all objects accessible by these [noalias] lvalues,' which is the entirety of both array arguments.        More generally, suppose I see a prototype      char *magicfunction(noalias char *, noalias char *); Is there anything at all I can conclude about the requirements of magicfunction?  Is there anything at all I can conclude about things it promises to do or not to do?  All I learn from the Rationale (page 52) is that such a routine enjoins me from letting the arguments overlap, but this is at variance with the Standard, which gives a stronger injunction.        Within the function itself, things are equally bad.  A `const type *' parameter, though it presents problems for strchr and other routines, does usefully constrain the function: it's not allowed to store through the pointer.  However, within a function with a `noalias type *' parameter, nothing is gained except bizarre restrictions: it can't cast the parameter to a plain pointer, and it can't assign the parameter to another noalias pointer without creating unwanted handles and potential virtual objects.  The interface must say noalias, or at any rate does say noalias, so the author of the routine has all the grotesque inventions of 3.5.3 (handles, virtual objects) rubbed in his face, like or not.        The utter wrongness of `noalias' is that the information it seeks to convey is not a property of an object at all. `Const,' for all its technical faults, is at least a genuine property of objects; `noalias' is not, and the committee's confused attempt to improve optimization by pinning a new qualifier on objects spoils the language. `Noalias' is a bogus invention that is not necessary, and not in any case sufficient for its apparent purpose.        Earlier languages flirted with gizmos intended to help optimization, and generally abandoned them.  The original Fortran, for example, had a FREQUENCY statement that didn't help much, confused people, and was dropped.  PL/1 had `normal/abnormal' and `uses/sets' attributes that suffered a similar fate.  Today, these are generally looked on as adolescent experiments.        On the other hand, the insufficiency of `noalias' is suggested by Cray's Fortran compiler, which has 20 separate keywords that control various details of optimization.  They are specified by an equivalent of #pragma,  and thus, despite their oddness, can be ignored when trying to understand the meaning of a program.        Perhaps there is some reason to provide a mechanism for asserting, in a particular patch of code, that the compiler is free to make optimistic assumptions about the kinds of aliasing that can occur.  I don't know any acceptable way of changing the language specification to express the possibility of this kind of optimization, and I don't know how much performance improvement is likely to result.  I would encourage compiler-writers to experiment with extensions, by #pragma or otherwise, to see what ideas and improvements they can come up with, but I am certain that nothing resembling the noalias proposal should be in the Standard. Цитата       Noalias must go.  This is non-negotiable.        It must not be reworded, reformulated or reinvented.  The draft's description is badly flawed, but that is not the problem.  The concept is wrong from start to finish.  It negates every brave promise X3J11 ever made about codifying existing practices, preserving the existing body of code, and keeping (dare I say it?) `the spirit of C.'

Автор: SergeCpp 10.2.2007, 09:18

Цикл статей Страуструпа о совместимости C и C++ http://www.research.att.com/~bs/sibling_rivalry.pdf AT&T Labs — Research Technical Report. January 2002 http://www.research.att.com/~bs/siblings_short.pdf The C/C++ Users Journal. July 2002 http://www.research.att.com/~bs/compat_short.pdf The C/C++ Users Journal. August 2002 http://www.research.att.com/~bs/examples_short.pdf The C/C++ Users Journal. September 2002 Положение дел http://david.tribble.com/text/cdiffs.htm

Автор: MAKCim 10.2.2007, 10:29

Цитата(Void @  9.2.2007,  23:41 ) Между предпочтением и обязательством есть разница. но фактически ограничений на сегодня использоанию inline нет, и так как Цитата is to be preferred to the usual function call mechanism то логично было бы в обычном (не оптимизирующем) режиме всегда использовать inline, если это явно указано тогда бы программист был уверен, как именно будет в итоге выглядеть код Цитата(Любитель @  10.2.2007,  00:45 ) MAKCim, кстати выше я говорил про __atribute__ и __asm__.  я понял

Автор: mr666 11.2.2007, 17:22

Вроде современные компиляторы игнорируют register переменные... анализируя код ..

Автор: Любитель 11.2.2007, 19:29

MAKCim, ну всё же, если компилер будет просто игнорировать инлайн, формально он удовлетворяет стандарту. К тому же не всегда встраивание возможно. Например, имеем рекурсивную функцию (в тривиальный цикл не разворачиваемую - только с использованием стека). Компилер не сможет её заинлайнить. Да и в жебаге мне кажется любую рекурсивную функцию он встраивать не будет. Игнор инлайна гораздо проще, чем развёртывание рекурсии (даже в цикл). То же имеем и с регистер, и с рестрикт.

Автор: MAKCim 11.2.2007, 21:43

Цитата(Любитель @  11.2.2007,  19:29 ) Например, имеем рекурсивную функцию (в тривиальный цикл не разворачиваемую - только с использованием стека). Компилер не сможет её заинлайнить да как нефиг пусть есть Код static inline void recurse(int N) {     recurse(N + 1); } int main() {     recurse(0);     return 0; } функция Код recurse:     push ebp     mov ebp, esp     sub esp, 4     mov eax, [ebp + 8]     mov [ebp - 4], eax     call recurse ... main:     push 0     call recurse ... inline Код main:     push 0     push offset @1 recurse:     sub esp, 4     mov eax, [esp + 4]     mov [esp], eax     call recurse @1: ...

Автор: Любитель 11.2.2007, 21:50

Цитата(Любитель @  11.2.2007,  19:29 ) в тривиальный цикл не разворачиваемую   Только что писал про tail recursion в Nemerle. А вообще оффтопик почуть пошёл.

Автор: unicuum 15.3.2007, 04:53

Как утверждает создатель С++ Бьерн Страуструп в его третьем издании книги «Язык программирования С++» - «не важно на каком языке программируешь, важно что из себя представляешь ты сам». И я с ним полностью согласен.

Автор: esperant0 15.3.2007, 15:46

Цитата(unicuum @ 15.3.2007,  04:53) Как утверждает создатель С++ Бьерн Страуструп в его третьем издании книги «Язык программирования С++» - «не важно на каком языке программируешь, важно что из себя представляешь ты сам». И я с ним полностью согласен. Это еще Тьюринг доказал. А Страуструп всего лишь процитировал в вольной форме.

Автор: Любитель 15.3.2007, 16:16

Для результата - почти да. Для процесса - ни в коем случае

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)