<iostream.h>

> А реализация функциональности, аналогично виртуальным методам, на чистом С

сотый раз говорю. это не нужно для той ниши, где крутится си. и даже если бы это было бы нужно, оно бы a) вероятнее всего работало быстрее b) было бы ужасным неюзабельным костылём

> rtti - не дает такого огромного оверхеда, а под наследованием, вы уточните, что имеете в виду, если просто наследоватся от класса без виртуальных методов

а вы не используете виртуальные методы? совсем? =)

> Не люблю фанатиков, орущих, что ООП не нужен и фанатиков

где я говорил, что ооп не нужен?

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

несоменно. но на си вы так или иначе работайте на низком уровне, и подводные камни, о которых даже не подозреваешь, постоянно тебя находят. это нормально. просто на си *не нужно* писать почтовые клиенты, жабер клиенты и прочую юзер-спейс лабуду.

> значете почему? Потому что в Apple-овских хедераз определен макрос max.

#ifdef max
#undef max
#endif /*max*/

>В C++, к тому же, ООП не самого лучшего качества.

Ну чтож делать, если альтернатив, сравнимых по скорости, практически нет.

в С++ два вида полиморфизма, поэтому виртуальные методы можно и не использовать.

>но зачем когда уже есть готовое?

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

>спроси об этом разработчиков ядра

вы про kobject? он очень хорошо спроектирован и реализован

4.2, есть, например уже упоминавшийся ранее obj-c

>>спроси об этом разработчиков ядра

> вы про kobject? он очень хорошо спроектирован и реализован

Какой к черту kobject, все ядро практически написано в ООП стиле.

> а вы не используете виртуальные методы? совсем? =)

Я вроде-бы только что сказал, что аналог виртуальных методов на чистом С работать будет так-же по скорости. Чем struct file_operations не таблица виртуальных методов? А чем она будет быстрее чем абстрактный базовый класс IFileOperations ?

>> Книга "практика программирования" от создателей C.

>враньё. циату в студию. я, кажется, упомянал *о чём именно* коворили k&r по поводу макросов. они не говорили, что это костыль, они констатироали, что их нужно использовать осторожно. не более.

Единственное место, где я ее в online нашел: http://mini-soft.ru/book/tech_prog/index.php

Для отчетности, книга «Практика программирования», авторы Б. Керниган, Р. Пайк.

Часть 1-ая, "Стиль" (http://mini-soft.ru/book/tech_prog/Charter1/1.php):

================

Макрофункции

В среде программистов, давно пишущих на С, существует тенденция писать макросы вместо функций для очень коротких вычислений, которые будут часто вызываться: операции ввода-вывода, такие как getchar, и проверки символов вроде isdigit — это, так сказать, официально утвержденные примеры. Причина — в производительности: у макросов нет "накладных расходов", которые свойственны вызовам функций.

На самом деле этот аргумент был не слишком убедительным уже в те времена, когда С только появился, — в эпоху медленных машин и "дорогих" вызовов функций; теперь же он просто нелеп. Для современных машин и компиляторов недостатки макрофункций перевешивают их достоинства.

Избегайте макрофункций. В C++ встраиваемые (inline) функции делают использование макрофункций ненужным; в Java макросов вообще не существует. В С они больше проблем создают, чем решают.

================

-- если это декларация костыльности макросов, то тогда что-же?

> А если вы в своём классе начнёте использовать такие простые и понятные названия, как list, queue и т.п., то проблемы у вас могут начаться и в плюсах. Всё это, конечно, поддаётся детекции, но на неё нужно тратить время программиста, на что обычно фанаты плюсов внимания не обращают.

Почему-же, в C++ я преспокойно могу ипользовать метод с именем queue или list, даже если сделаю using name space std.

> вы про kobject? он очень хорошо спроектирован и реализован

не только, еще есть VFS, файловые дескрипторы, ...

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

Ты когда-нибудь в реальный проектах принимал участие? Руками ты заточишь, чтобы было по производительности как в STL ну или на пару процентов лучше, смысла нет в этом никакого. Если всё будешь затачивать, то проект будешь делать годами, когда у конкурентов уже будет все готово.

> Почему-же, в C++ я преспокойно могу ипользовать метод с именем queue или list, даже если сделаю using name space std.

Не работает:

#include <list> 

using namespace std;

typedef int* iterator;
typedef char* list;

class A {
public:
    iterator a;
    list c;
};

int main(int argc, char* argv[]) {
    A a;
    a.a = 0;
    a.c = 0;
}

Если изголяться с неймспейсами, то и в Си можно делать 

#define MYNS_MYCLASS_MAX abc

что glib сотоварищи успешно и делают.

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

> Не работает:

Я, цитирую, говорил про "метод с именем queue или list".

> Конкуренты контентную фильтрацию на схеме за два месяца напишут

Каждому своя задача, если не требуется производительности, то конечно C++ далеко не всегда стоит выбирать.

>Руками ты заточишь, чтобы было по производительности как в STL ну или на пару процентов лучше

Мухаха... если вы думаете что STL настолька универсальна и производительна, то говорить с вами неочем...

ну тогда досвидания, продолжайте точить дальше

> Я, цитирую, говорил про "метод с именем queue или list".

Я, цитирую, говорил: "А если вы в своём классе начнёте использовать такие простые и понятные названия, как list, queue и т.п."

>> Я, цитирую, говорил про "метод с именем queue или list".

> Я, цитирую, говорил: "А если вы в своём классе начнёте использовать такие простые и понятные названия, как list, queue и т.п."

Я, не цитирую, приводил пример, когда макрос max приводил к проблемам именно с названиями методов, в то время, как inline функция в данном случае никаких проблем не создаст. В данном случае проблема макроса в том, что его "пространство имен" глобальна, и не поддается ограничениям каким-либо, он как медведь, ломится напролом ;)

Знание мест, где разложены грабли, приходит к программисту с опытом.

> -- если это декларация костыльности макросов, то тогда что-же?

это призыв избегать необоснованных макросов. шаблоны, кстати, хотя и являются более секурными и, к слову, довольно хорошей и грамотной идеей, с данной точки зрения также являются "костылём". от чего спасают шаблоны: фактически только от name collision и type violation. причём от последнего частично, тк если допустим некоторый class T a сравнивается с некоторым class T b, и при этом один из них не имеет перегруженного оператора сравнения(отдельная, кстати, песня), вы получите здоровенный трейс. да, он будет более гораздо более детерменированный нежели любой error, вызванный макросами, но "костыльности"(как вы её понимаете) шаблонов это не отменяет.

> Какой к черту kobject, все ядро практически написано в ООП стиле.

нет. только драйверная(интерфейсная, если быть точным) подсистема & vfs.

> Знание мест, где разложены грабли, приходит к программисту с опытом.

это становится уже не знанием, а отточенной эвристикой ;)

> это призыв избегать необоснованных макросов.

По моему, там дословно написано "Избегайте макрофункций.", без каких-либо условий вроде "необоснованных"/"не очень сильно в этом месте нужных". В книжке вежливо но безоговорочно сказано: макросы не используйте, вообще.

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

Обоснуйте это утверждение. Являются ли в таком случае костылем, например Generic (параметризуемые) модули в ADA ? (которые есть суть АБСОЛЮТНО то-же самое, только синтаксис отличается).

> от чего спасают шаблоны

А я полагал что шаблоны не спасают, а расширяют функциональность языка, позволяя писать типонезависимый повтороно реюзаемый код. Ну и плюс к этому, добавляют некоторую возможность декларативного программирования "в compile time", например можно написать шаблон, который в процессе разворачивания во время компиляции, вычислит факторил числа, который в итоге будет зашит в код константой.

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

> нет. только драйверная(интерфейсная, если быть точным) подсистема & vfs.

+ Сетевая подсистема, как минимум, да и любой код, где встречаются struct xxx_operations или бональное оперирование структурами передаваемыми в каждую функцию в качестве первого аргумента, все ООП по своей сути.

>>> К чему болтовня, давай примеры сортировки на си и плюсах, проверим.

>> http://theory.stanford.edu/~amitp/rants/c++-vs-c/

>В appendix-е есть все сорцы.

И ты сам видел эти "сорцы": грязный тест (сортировка на одном и том же наборе в серии), аллокация массива несколько раз без толку - это писец просто, использование целого для потенциально больших массивов. Еще прикол - это его функция сравнения!

У него

int compare_T(const void* a, const void* b) { T ai = *((T*)a), bi = *((T*)b); if(ai<bi) return -1; else if(ai>bi) return 1; else return 0; }

Надо:

int compare_T (void* a, void* b) { return *(T*)a - *(T*)b; }

Даже смотреть не хочется на его самописный код сортировки после этого.

Справедливости ради надо сказать, что с ключами оптимизации, компилятор все же справляется с его функцией сравнения более или менее. Правильный вариант дал на моей машине для 10 000 000 целых 3.35 секунды, когда его "вариант" дал (с ключом -O3, но без реально замедляющего -funroll-all-loops) 3.6 секунды.

Все же взятие по указателю - это зло для целых чисел.

> В книжке вежливо но безоговорочно сказано: макросы не используйте, вообще.

цит.: "Избегайте макрофункций. В C++ встраиваемые (inline) функции делают использование макрофункций ненужным; в Java макросов вообще не существует. В С они больше проблем создают, чем решают."

где здесь сказано "не используйте макросы"? понятное дело, что лучше всего вместо большинства макросов писать static inline, но существуют ситуации, когда без них не обойтись. банальнейший пример - макрос, печатающий error message, если случилась ошибка и показывающий в какой строке и в каком файле она произошла. как здесь обойтись без макроса использующего __FILE__ и __LINE__? и на c и на c++ - никак. или если вам нужен набор констант, который должен быть использован в нескольких файлах. неужели вы будете делать extern enum myconsts? или если вам нужено сделать некоторую абстракцию над побитовыми операциями вы будете писать:

static inline enable_something(abtract_t var, flag_t some_opt) { return (var | some_opt); }

и использовать её my_var = enable_something(var, F_STUFF);

вместо того, чтобы сделать так: #defin enable_something(var, opt) (var |= opt)

и использовать так: enable_something(my_var, F_STUFF);

да?

> Обоснуйте это утверждение.

я всего лишь отталкивался от ваших слов: "макросы - костыль, а шаблоны не костыль". но обе эти фичи - compile time. как одна compile time фича может быть костылём, а другая нет? =)

по мне, так и макросы, и шаблоны костылями *не* являются. объясню почему: костыль - это некоторая уродливая примочка к архитектуре, созданная для решения некоторых задач, решать которые изначальная архитектурная модель не позволяла. макросы же - это не "примочка" к си, это всего лишь макропроцессор, который разворачивается в тот же си. шаблоны опять же, фактически, ни коим образом не противоречат архитектуре c++, поэтому тоже костылём не является.

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

#define getmember(ds)

#define my_typeindependent_cmp(a, b)\ do {\ if(a.greater(a.member, b.member)) \ do_something();\ else\ do_other_thing();\ } while(0)

абсолютно типонезависимый макрос. нужно лишь одно: чтобы некоторые типы a и b имели общий интерфейс. в том числе и ф-ю greater. то же самое мы видим в темплейтах. если мы рассматриваем реализацию аналогичной ф-ии на темплейтах, мы предпологаем, что у любого типа class T должен быть перегружен оператор >. так что типонезависимый код можно было писать и до темплейтов.

> Ну и плюс к этому, добавляют некоторую возможность декларативного программирования "в compile time", например можно написать шаблон, который в процессе разворачивания во время компиляции, вычислит факторил числа, который в итоге будет зашит в код константой.

верно. шаблоны - тьюрин полный язык, кстати =).

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

это уже другой вопрос; + http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions

s/тьюрин/тьюринг/

> да и любой код, где встречаются struct xxx_operations или бональное оперирование структурами передаваемыми в каждую функцию в качестве первого аргумента, все ООП по своей сути.

нет. ооп концепция предпологает: http://en.wikipedia.org/wiki/Object-oriented_programming#Fundamental_concepts

в принципе, в ядре всё это делается с использование kobject. но, отнюдь не любая структура "передаваемая в каждую функцию в качестве первого аргумента" является ооп.

попробуй написать так:

#include <iostream>
using namespace std;