Типичные ошибки C++

и Nemerle

и Scala, да и ещё много чего.

+ Common Lisp + Nemerle + Scala

Если твоя программа оттранслировалась без ошибок, скажи об этом системному программисту - он исправит ошибку в трансляторе. (C)

Чем более кривой код будет компилироваться в рабочую программу - тем
больше будет программ.

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

а уж убирание поддержки кода. подходящего для более старых версий компилятора - вообще преступление.

и что ради вот этого стоило писать статью:

class foo
{
public:
foo::foo();
};

?

> Чем более кривой код будет компилироваться в рабочую программу - тем больше будет программ.

Нефиг-нефиг. Кол-во кривого кода и так растет как снежный ком. Если не предпринимать хотя бы минимальных усилий по его уменьшению (на уровне технологии) - будет еще хуже. Кривой код - фтопку.

> А уж сделать ее некривой в бинарнике - задача компилятора.

Достойная задача для AI - сделать из кривого кода прямой бинарник. "Сделай не то, что я тебе приказал сделать, а то, что я хотел, чтоб ты сделал". Телепаты срочно вернулись из отпуска.

> а уж убирание поддержки кода. подходящего для более старых версий компилятора - вообще преступление.

Так компиляторы становятся bloatware. Компилятор - средство не для end-user. Если у человека есть мозги, чтоб заниматься компиляцией - пусть заточит сырцы под новую версию (редко бывает так, чтоб было совсем непонятно, как затачивать - впрочем, документацию на эту тему разработчики компиляторов обычно предоставляют в каком-то виде).

> а уж убирание поддержки кода. подходящего для более старых версий компилятора - вообще преступление.

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

>svu *** (*) (05.04.2006 18:26:39):Так компиляторы становятся bloatware. Компилятор - средство не для end-user. Если у человека есть мозги, чтоб заниматься компиляцией - пусть заточит сырцы под новую версию (редко бывает так, чтоб было совсем непонятно, как затачивать - впрочем, документацию на эту тему разработчики компиляторов обычно предоставляют в каком-то виде).

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

>Чем более кривой код будет компилироваться в рабочую программу - тем больше будет программ.

Не факт. В плане перевариваемости кода, скажем, у нас такая цепочка: Perl > Си > Java > VB.

На практике популярность распределяется как: Java > Си > Perl > VB.

Как видим, корреляции не наблюдается :)

> Не факт. В плане перевариваемости кода, скажем, у нас такая цепочка: Perl > Си > Java > VB.

цепочка пищеварения у разных видов может отличаться

>цепочка пищеварения у разных видов может отличаться

Тьфу, это я тут параллельно заболтался :) Имелось в виду:

Perl > VB > Си > Java.

Или ты с каким-то моментом не согласен? ИМХО, Perl позволяет писать более "вольный" код, чем VB, VB - более "вольный", чем Си и т.д.

А серьёзные люди так и делают.

http://www.sysoev.ru/2005.html Посмотри новость от 20.02.2005

В таком виде корреляция очень даже наблюдается. Это как раз неплохое доказательство (или объяснение), почему жабка рулит;)

Не слушаёте картавого деда - 3.14здит как дышит. Я только недавно перелопачивал проект после перехода с MSVC 7.0 на MSVC 7.1, так что там всё то же самое, только хуже.

>Языки НЕ развиваются. Последним версиям стандартов ISO на С и С++ уже многов времени. А вот пингвиньи компиляторы почему-то развиваются.

Вызывающе неверная информация. Языки развиваются, появляются новые стандарты. А компиляторы до сих пор не все стандартам соответствуют. И особенно это до последнего времени касалось vc++. Сейчас они вроде что-то правят в этом направлении, одумались.

> Ещё - ?

ghc (не на 100% уверен). PyPy. Некоторые реализации Common LISP. Моновский компилятор C# (на чем там VM - я не помню).

"парниковый эффект вызван гигантским выбросом метана" (c) talks

Казалось бы, причем тут lenin?

>Некоторые реализации Common LISP

Какие интересно?

>Моновский компилятор C# (на чем там VM - я не помню).

VM у них на bash-е есно.

>ocaml, например.

Из OCaml, на мой взгляд, букву O можно безболезненно выкинуть:)

> Правда я не знаю как он собирается.

Да хоть в байт-код, хоть в натив.

> Какие интересно?

cmucl, sbcl

>Из OCaml, на мой взгляд, букву O можно безболезненно выкинуть:)

Обоснуй.

>Да хоть в байт-код, хоть в натив.

Это я знаю. Вопрос в том: можно ли его считать самосбирающимся. В дереве исходников, помнится, были куски кода на Ц. Но сколько их было и чем они занимались я не помню.

>Типичной ошибкой С++ программиста является выбор С++ в качестве ЯП

Вот вот. В нормальных ЯП уже существуют статические анализаторы кода http://research.compaq.com/SRC/esc/ http://findbugs.sourceforge.net/, а C++ники все еще ищут утечки ресурсов и потерявшиеся указатели.

>Обоснуй.

Это субъективное мнение.

>Вопрос в том: можно ли его считать самосбирающимся

Да.

>В дереве исходников, помнится, были куски кода на Ц. Но сколько их было и чем они занимались я не помню.

Обертки к функциям ОС или некоторые внутренние функции, переписанные на C с целью оптимизации.

Там, кстати, даже асм есть.

ЕМНИП, интерпретатор байт-кода и отдельные модули из библиотеки

На C там только VM и куски библиотеки. Компилятор на OCaml, бутстрапится из скомпилированных в байткоды бинарников.

что-то в этом есть...

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

6200 пакетов? он что, терминатор??

> ЗЫ Я не помню - я говорил, что плюсы гадость?;)

А разве корпоративные требования у гномеров позволяют НЕ говорить (я бы даже сказал - НЕ вопить) об этом на каждом углу?

> ООП на С - это тяжкий труд;)

Я бы даже сказал - сизифов труд. И результат - тормозной gtk.

> Сначала - разработчикам WinAPI, xlib, libc (stdio.h) etc. etc.

А чё, гном и WinAPI - ровесники? Или гномы обожают наступать на грабельки, по которым все уже прошлись лет 10 назад?

>А чё, гном и WinAPI - ровесники? Или гномы обожают наступать на грабельки, по которым все уже прошлись лет 10 назад?

а libc - тоже грабельки? или у ананимуса просто мозгов не хватает понять, что использование C++ в библиотеке/тулките - это дурной тон?

ааа
geek

который даже С не знает
не то что с++

учит других жить ....
вот это моветон

>вот это моветон

ты знаешь, куда тебе идти? вот и иди

> А тогда весь пингвиникс написан кретинами. Попробуй собрать что-нить десятилетней давности. Выложить ?

Это ты собственную мазню тут собрался выкладывать как образец, что ли? А, ну давай, давно анекдотов на C не было.

> Ещё - ?

freepascal

> а вообще говоря мысль! пытаться собрать свои проекты сразу несолькими компиляторами. если ни один не ругнётся - код верный

Причём желательно - компиляторами разных языков. В сухот остатке получим программу из одного символа ";", которая и олицетворяет абсолютную истину.

>а C++ники все еще ищут утечки ресурсов и потерявшиеся указатели.

Это те кто не умеет программировать на С++. Остальные пользуются smart pointers & Co и горя не знают =)

>Ни одного из "трёх китов" - ни полиморфизма, ни наследования, ни инкапсуляции. Доступ к полям "объектов" через точку - это ещё не ООП :)

Ну не спорь ты, не видишь что ли: тут сидят супер-спецы ООП.... =)))

>Я не помню

А вот если бы ты программировал на плюсах, у тебя бы была прекрасно натреннированная память.

Не грошь, а 12 баксов в час, дяденька.

Гы гы гы :). Знаток Цэ Пэ Пэ компиляторов :).

anonymous (*) (05.04.2006 13:06:59)
> Какой бред программировать на С++, на на Си.

svu *** (*) (05.04.2006 13:15:31)
> ЗЫ Я не помню - я говорил, что плюсы гадость?;)

От анонимусов такое слышать неудивительно, но от тебя svu я не ожидал услышать подобный бред. Признаться, у меня раньше тоже было предубеждение насчет C++, да и пишу я сам до сих пор именно на C, но... Первый же проект на C++, который приходит в голову это rxvt-unicode. Качество отменное. И по скорости и по фичастости. Например, сравним данный продукт по скорости вывода текста с XTerm, который написан на чистом C. И в том и другом случае настройки шрифтов (и там и там Courier New, который выводится через xft), jumpscroll'ы, абсолютно аналогичны, если кто не поверит могу выслать оба конфига.

[9:53]gentoosiast@breeze% ls -lR /dev|wc -l [~]
462

Теперь запускаем рекурсивный вывод ls -l под XTerm и URxvt (запускал по несколько раз, брал последний результат, так что не надо гнать, что там что-то закэшировалось):

[10:14]gentoosiast@breeze% urxvt -h 2>&1|head -n 1 [~]
rxvt-unicode (urxvt) v7.5 - released: 2006-01-31
[9:55]gentoosiast@breeze% time ls -lR /dev|less [~]
... long output skipped ...
real 0m0.511s
user 0m0.017s
sys 0m0.008s

[10:12]gentoosiast@breeze% xterm -version [~]
XTerm(200)
[9:55]gentoosiast@breeze% time ls -lR /dev|less [~]
... long output skipped ...
real 0m1.797s
user 0m0.029s
sys 0m0.022s

Как говорится комментарии излишни. И это притом, что XTerm до сих пор не может выводить заголовках окон и в Icon Names текст в кодировке отличной от ISO 8859-1. Может если локаль UTF-8, то все и нормально, но под восьмибитной KOI8-R вы кириллического текста там не увидите. Томасу я про это писал, он это обещал поправить, но в URxvt это работало с незапамятных времен. Наверняка здесь люди смогут привести еще примеры, это первое что пришло мне в голову из тех проектов на C++, которыми я сам пользуюсь и доволен ими.

Так что не нужно обобщать, что все проекты на C++ гамно, наверное все же качество больше зависит от таланта программист(а|ов).

svu, лучше будь добр, дай URL на описание GNOME hints, а то что-то на вашем портале найти не могу

Блин, не туда попал :( Хотел написать к языкам высокого уровня, компиляторы которых собирают сами себя. Хотя наверно нет языков програмирования уровнем ниже асма.

Для развития памяти жабка помогает. Запомнишь весь J2SE API - и память как бицепсы у Ван Дамма;) (На всякий случай - я, конечно, не помню;)

> Первый же проект на C++, который приходит в голову это rxvt-unicode. Качество отменное. И по скорости и по фичастости

Да, на С++ можно написать хороший код (я обратного нигде не утверждал). Вопрос, сколько лет надо писать плохой, чтоб научиться писать хороший? И сколько стоит поддержка этого плохого плюсового кода?

> Например, сравним данный продукт по скорости вывода текста с XTerm, который написан на чистом C.

На С можно написать плохой код. Примеры не могут быть доказательством. Особенно если их всего два.

> Так что не нужно обобщать, что все проекты на C++ гамно

Где я это сказал??? Я утверждаю, что С++ - гадость. Но никогда не говорил, что все плюсовые проекты никуда не годятся. Цитируйте, пожалуйста, точнее.

> наверное все же качество больше зависит от таланта программист(а|ов)

Однозначно. Но язык таки определяет многое.

> URL на описание GNOME hints,

Энто хто такое? За время жизни гнома этим словом назывались разные вещи;)

> URL на описание GNOME hints,

Это чоль?

http://www.gtk.org/api/2.6/gtk/GtkTooltips.html

> Или гномы обожают наступать на грабельки, по которым все уже прошлись лет 10 назад?

Грабли WinAPI совсем не в том, что он ОО (то же относится к libc и xlibc). Скорее наоборот - в недостаточно последовательном ОО. А менять грабли ОО С на другие - надо иметь достаточно веские основания (и уж тогда лучше брать не плюсы, а что-нибудь managed).

> Или гномы обожают наступать на грабельки, по которым все уже прошлись лет 10 назад?

А линуксоиды и бсдшники - предпочитают наступать на грабли, которым более 30 лет? Все на форточки, товарищи! :-(