Вот я тут подумал - почему народ все тянется к С++ и не
программит на С? С++ этоже такой немеряный отстой .. я не
говорю о том что ООП кал - ООП супер вещь но на С он явно
не ложится .. если нужен обязательно ООП подход и писать
надо на С - то все(может быть почти все) можно
реализовать на С например классы или наследования
достаточно простым путем.
struct class_ex {
int pubint1;
int pubint2;
char *pubstr3;
int (*getpub1)(struct class_ex *this); /* method */
int (*getpub2)(struct class_ex *this); /* method */
int (*getpub3)(struct class_ex *this); /* method */
int (*convert)(struct class_ex *this, int, char*);
..
};
наследование от одного предка
strct parent {
int data1;
int data2;
char *data3;
... /* methods */
}
struct p_parent {
struct parent;
int data_specific_to_p_parent;
char kkk[12];
.... /* p_parent specific methods */
};
struct pp_parent {
struct p_parent;
int data_specific_to_pp_parent;
.... /* pp_parent specific methods */
};
...
...
#define PARENT(x) (struct parent*)(x)
#define P_PARENT(x) (struct p_parent*)(x)
#define PP_PARENT(x) (struct pp_parent*)(x)
если нужно множественное наследование то это тоже можно
реализовать высчитывая соответствующие оффсеты.
помоему это гораздо наглядние и быстрее и натуральнее и
вообще более по настоящему нежеле в C++
struct class_ex*
init_newclass(void)
{
struct class_ex *newc;
newc = (struct class_ex*)malloc(sizeof(struct class_ex));
/* TODO: err checks */
newc->getpub1 = class_getpub1;
newc->getpub2 = class_getpub2;
newc->getpub3 = class_getpub3;
newc->convert = class_convert;
...
return newc;
}
newc = init_newclass();
P_PARENT(newc)->get_p_sec_val(P_PARENT(newc));
newc->pub1 = 2;
p1 = newc->getpub1(newc);
помоему все это гораздо натуральнее и нет той херовости
что в C++
Вот я подумал: почему народ пилит лес бензопилами и не хочет пилить лобзиками?
Лобзик - это же такой рулез! Я лобзиком из фанерки такие кульные штуки
выпиливал в детстве! А бензопила - отстой! Попробуй выпили бензопилой по фанерке!
Тут же все поломаешь к чертям! А лобзиком все гораздо удобнее и нагляднее!
Я вот только сейчас лобзиком перепилил карандаш. Раз можно перепилить карандаш,
значит можно и сосну в три обхвата. Так что давайте ребята - нефиг юзать всякий
отстой.
Страуструп вообще мудило мне видится - не рюхает он ни хрена и бензопила у него галимая получилась - бензина хватает только на 10 минут и лезвие ломается через каждый час .. и держать ее надо в идеале четырмя с половиной руками и возможно надо еще снизу поддерживать специальной поддержкой для бензопилы которая крепится к поясу .. и после использования возможны побочные эффекты типа чувак не сможет пилить нечем кроме нее
А если по существу - то сюда еще нужно:
- таблицу виртуальных функций и полиморфизм
- поддержку RTTI (у меня список указателей на базовый класс, а мне приспичило
сделать что-то специфичное для потомка - но я должен быть уверен, что я могу
безопасно привести указатель к типу).
- вызовы конструкторов и деструкторов в правильном порядке при сложном наследовании
- самое главное: поддержку всех библиотек, написанных на С++
- ну и по мелочи: инапсуляцию данных, разрешение имен, шаблоны
(ах да, у нас есть препроцессор, немного потренироваться и нет проблем!)
ЗЫ: мне и самому С++ не особо нравится. Но если задача хорошо ложится на
С++, то я буду писать на С++. Если задача хорошо ложится на lex/yacc, я буду использовать их,
если надо написать скрипт, то буду использовать shell или perl. И т.д.
2) Все (в т.ч. рутинные вещи) делаешь сам, а компилятор филонит.
3) Хочешь сделать ACOS (ANSI C Object System)? А пупок не развяжется?
P.S. Да и собственно к ООП все эти наследования имеют слабое отношение. Базовых идей в ООП всего две - 1) Все есть объекты. 2) Объекты общаются между собой обмениваясь сообщениями. А уж как и на каком языке это будет реализовано - дело дцатое.
На самом деле кроме объектов и сообщений есть еще и иерархия классов и объектов.
По Бучу - пятый признак сложной системы - эволюционность и развитие из работающих
прототипов. Если язык объектный, то он эту концепцию поддерживает изначально.
В С++ в качестве прототипов используются базовые классы.
Этот мудила просто выбрал самый популярный язык - если бы в то время был бы basic самым значимым - имели бы мы basic++ - и было бы это тоже таким же говном
ООП должно быть причалом для более высоких языков где не надо задумываться что откуда как и куда происходит, то есть для языков на которых программируют а не пишут комманды для компилятора
2 PETER да а че там доказывать - создал более менее работающий C++ с хрен знает какой попытки(все помнят C with Objects?) и в итоге получилось говно. Свои мысли в книжке смог сформулировать более менее только с третьего или четвертого раза ...
> На самом деле кроме объектов и сообщений есть еще и иерархия классов и объектов. По Бучу - пятый признак сложной системы - эволюционность и развитие из работающих прототипов. Если язык объектный, то он эту концепцию поддерживает изначально. В С++ в качестве прототипов используются базовые классы.
Классы? Это просто удобное решение. Популярный технический трюк, "паттерн" как теперь модно выражаться. _Необходимости_ в классах для ООП нет.
P.S. Вы уверены, что под "эволюционностью и развитием из работающих прототипов" Буч понимал именно наследование? Мне казалось, что он имел в виду легкость модификации уже имеющейся и работающей ОО-системы, нет?
P.P.S. Сегодня же перечитаю Буча. Люблю такую беллетристику.
Да что вы все об ООП, да ООП! Есть универсальные языки, а есть заточенные под конкретную задачу.
На одном ООП свет клином не сошелся. Есть еще и задачи синт. разбора, запросы к базам,
задачи, которые хорошо ложаться на функциональные языки типа ocaml. Но даже
когда пишешь на универсальном языке, то сначала раскладываешь предметную область
на систему абстракций, потом реализуешь эти абстракции на языке, и уже потом
используешь их для решения задачи. По сути на заключительном этапе
программирование уже идет не на изначальном универсальном языке, а на
языке формализованных и реализованных абстракций. Проблемный язык содержит их изначально.
Универсальный дребует дополнительного этапа. Разница по сути может быть
в деталях на уровне синтаксиса - не более. С этой точки зрения С - тоже не фонтан,
причем сильно не фонтан. Хорошо бы если бы был универсальный язык с открытым
синтаксисом, чтобы при реализации системы абстракций не быть связанным
условностями этого языка, но нету такого....
Да что вы все об ООП, да ООП! Есть универсальные языки, а есть заточенные под конкретную задачу.
На одном ООП свет клином не сошелся. Есть еще и задачи синт. разбора, запросы к базам,
задачи, которые хорошо ложаться на функциональные языки типа ocaml. Но даже
когда пишешь на универсальном языке, то сначала раскладываешь предметную область
на систему абстракций, потом реализуешь эти абстракции на языке, и уже потом
используешь их для решения задачи. По сути на заключительном этапе
программирование уже идет не на изначальном универсальном языке, а на
языке формализованных и реализованных абстракций. Проблемный язык содержит их изначально.
Универсальный дребует дополнительного этапа. Разница по сути может быть
в деталях на уровне синтаксиса - не более. С этой точки зрения С - тоже не фонтан,
причем сильно не фонтан. Хорошо бы если бы был универсальный язык с открытым
синтаксисом, чтобы при реализации системы абстракций не быть связанным
условностями этого языка, но нету такого....
во! дельные мысли .. на ООП свет клином не сошелся.
И если человеку програмещему на С дейстивельно необходимо ввести абстракцию типа класс или наследование он может спокойно это сделать и не нужны ему никакие C++. А если человек задумал везде использовать ООП(типа это модно и супер юзабельно) подход и начинает _всё_ писать на С++ то он мудак.
Обратное тоже верно: если есть простое решение на С++ или вообще надо вызвать утилиту из shell,
а человек упертый и вместо этого все время пишет программы на С, то он - ну ты типа понял...
Очевидно, что для каждой задачи есть языки подходящие и не очень. И есть языка "общего" назначения - одинаково(плохо) подходящие для широкого круга типов задач. Если программист хорошо знает один из таких языков - он будет продолжать его использовать. Ибо ему платят не за изучение языков, а за написание программ. Недополученая в результате эффективность не учитывается - ибо сложно доказать, что она вообще могла бы быть.
Это можно считать инерционностью технологий - массовое внедрение новых альтернатив возможно только при большом давлении со стороны - либо компаний, продвигающей технологию(sun+java, ms+c#) - либо конкурентов, получающих преимущества от более эффективной технологии. Но последнее сложнее - по причине "страха" перед новой технологией. Цитируя кого-то "никто еще не был уволен за выбор C++". А зря;-)
Возвращаясь к предмету спора: предлагать C на замену C++ неправильно. C++ испольуют там, где он лучше C. И заменять один на другой только по причине "это такой немеряный отстой" - глупо. Должны быть какие-то реальные(*) преимущества.
Так что Haskell тебе в руки, lg. :-)
(*) реальность преимуществ - предмет отдельного обсуждения. эта категория сильно зависит от многих условий - типа задачи, условий разработки, критериев качества программы, ...
lg! Несколько недель назад ты в галерее раздавал хорошие советы по аутотренингу.
Воспользуйся собственным советом - повтори про себя раз 500 "Синтаксис языка и ООП - вещи разные". "ОО-язык - язык, который дает максимальное удобство для ООП, а не тот, в котором есть классы или наследование".
Unix way - маленькие тупые утилитки, которые взаимодействуя дают невиданные мощность и гибкость - вот ярчайшая иллюстрация ОО-дизайна.
хаскел был уже в моих руках повертел его повертел да и не нашел что написать на нем действительно дельное и полезное.
возможно например такое (дан бильярдный стол(с параметрами), даны шары(с параметрами)[уже расставлены], дан набор знаний типа:
* ударить надо по зеленому шару
* зеленый шар не должен касаться красного
* зеленый шар обязан хотя бы раз коснуться борта
* черный шар должен закатится в верхнюю правую лузу
* желтый должен закатится в среднюю нижнюю лузу
* черный шар должен закатится первым
...
дать это все дело проге и она посчитает в какую точку битка и с какой силой надо ударить чтобы удовлетворить все условия либо выдать что это невозможно .. может кто нибудь возмется на досуге ? :))
я не предлагаю C как замену C++ я говорю что если в представлении реализации какой то вещи возникает понятие класс - то у народа мнгновенно происходит ассоциативная связь с C++ и они делают выбор языка в пользу C++ _только_ по этой причине .. пожалуй соглашусь с тем что народ выбирает C++ как основной инструмент потому что за это не увольняют :)
Ну, я вообще думаю, что ООП - ошибка природы. В свое время эту парадигму
раскручивали, как очередную панацею -- сколько их было! Лисп, форт, пролог,
структурное программирование, РАД, итдитп -- и, как всегда, имеем сухой остаток
- ЦеПП. Не самый элегантный, не самый шустрый, не самый простой, но - работающий,
а, самое главное, ОЧЕНЬ раскрученный язык.
Я в свое время (лет 10 назад) сильно увлекся ООП. Но потом понял, что программисту
ООП не дает ничего, кроме лишнего геммороя. Другое дело - с точки зрения создания
коммерческих систем ООП в инкарнации ЦеПП оказался весьма полезным, ибоимеет мощные
механизмы скрытия, позволяющие разрабатывать систему независимым разработчикам в
условиях "коммерческой тайны" и даже торговать незаконченными кусками кода.
2lg (*) (2003-03-04 11:24:21.017):
То, что ты предложил - не наследование, а агрегация. Хотя, в принципе, разница -
чисто номинальная. Полиморфики точно так же реализуются.
Чего не хватает в Це - мощной инлайловости, как в ЦеПП.
P.S.
А у Страуструпа мозги набекрень, это ты точно подметил.
кстати lg как то срубил ведя беседы(тренинг психики и мысли) с психически больными - типа проходил практику :)
а никто не видел мультик(не помню чей) как появился жираф .. очень мне это напиманает появление C++ .. мультик следующий: бегает какое-то животное(на вид типа антилопы GNU) и хавает на земле всяких насекомых, мелких животных .. рядышком ползет удав .. удав хавает GNU и офигивает .. у него появляются ноги - шея вытягивается и удав с офигевшей рожей явно не хотя того начинает жрать листву на дереве .. :)) вобщем это смотреть надо .. я ржал наверное минут 15 после просмотра .. серия мультиков называлась както типа "Эволюция" чтоли
Да здесь - не партсобрание. Все равно каждый при своих останется.
Я использую С++ и меня это нисколько не колбасит. Про его недостатки знаю.
А раз знаю - обхожу. На С возвращаться смысла для себя не вижу.
Такое можно написать на чем угодно. Но разработка мат. модели поведения вращающегося шара в момент соударения с бортом|другим шаром требует слишком много "досуга"...
Я подозреваю, что эффективнее решать эту задачу тщательными тренировками и игрой в трехбортовой карамболь :-).
DonkeyHot .. да допустим что модель уже готова то есть (если дано начальное расположение шаров, точка на битке наклон кия и сила удара - подав все это дело модели - она вернет конечную расстановку шаров после удара).. как решить то задачу?
вот кстати вполне себе задача которую можно было бы
подсунуть такой проге
даны шары: o - биток, @, *, *, дана фиксированая точка
внутри бильярда - .
*1, *2 стоят по углам луз - достаточно касания чтобы они
упали.
o - стоит в центре, @ - на середине отрезка соединяющего
o и *1, стол большой, шары из русского (70 мм или сколько
там они не суть важно)
знания:
- бить по o
- o не должен коснуться @
- *1 должен закатиться в лузу возле которой он стоит
- *2 должен закатиться в лузу возле которой он стоит
- *1 должен закатиться первым
- после того как все шары остановятся o должен стоять на
точке .
\____________| |__________/1
\ */
| @ |
| |
| o |
| |
| . |
| ___________ ___________*\
/ / | | \2
Положим модель может выдавать не только конечное положение, но и минимальные расстояния битка до указаных точек,порядок прохода этих минимумов и координаты битка в них - иначе не проверить правильность удара.
Тогда можно разбросать по пространству возможных ударов достаточное кол-во точек, пересмотреть результаты в каждой, выбрать наиболее близкие к требуемому, и повторять то же в некоторой окрестности выбраных - несколько раз. Этот тривиальный перебор с ненулевой вероятностью выдаст близкий к правильному удар. Большая точность тут не нужна - велика погрешность вносимая физикой процесса. Пространство возможных ударов везде ограничено(направление удара[0-360],наклон кия[0-90],точка на шаре[~0.79*R*R], сила - [0-перелом:-]). Посему перебор должен быть "небольшим".
Имея на руках формулы можно попытаться оптимизировать процесс - или придумать другой алгоритм. Математика обещает быть не простой, но может и получиться. Но сначала - покажи уравнения (-;а еще лучше - их решения;-)
Интересную дискуссию развели. Вот у меня принцип такой: если задача не решается путём shell/unix utils, то я её определяю на одно из двух направлений: ANSI С или Java. Т.е. либо задача ложится под алгоритмическую модель, либо под объектную. Третий вариант - вэб - тоже Java (JSP).
да да модель везде захукана .. то есть на любое событие(касание шара,прохождение определенной точки, касание борта, подскок, etc) происходит вызов обработчика(твоего) и там уже можно все проверять ..
и мне еще кажется что в довольно точной модели 1 градус является слишком дискретным, площадь точки касания шаров мне кажется должен быть типа 0.01 мм^2 (всего точек получается 4*3.14*35*35/0.01 = 1538600-<немного точек снизу> [для шара d=70мм]) что много, тогда значимым значением для угла будет 360/(2*3.14*35/0.01) = 0.016 градуса [если считать точку касания кия шара равной точке касания шаров] (если значимым был бы 1 градус то диаметр точки касания кия и шара для шара в 70мм был бы 1.6мм!)
в дискретных моделях возможен перебор малой кровью .. но в точных(нереальных) моделях мне почему то кажется есть какое-то офигенно элегантное и простое решение должно быть .. это не только относительно к билиарду а вообще задача начального положения .. то есть дана какая то система с моделью поведения - дано некоторое состояние системы .. необходимо выяснить состояние системы за 10 мин до данного
Про точность. 0.01 мм для человеческой руки+глаза слишком:-). Поведение шара описывается непрерывными функциями. Посему возможно последовательное приближение. Плохо себя вести он будет только после отражения от 1-2х шаров или угла лузы(губа?). Первое, впрочем, тривиально - вначале мы сужаем область поиска до "удары, попадающие по первому шару, способные потом преодолеть расстояние до 2го(и т.д.). Или можно разделить весь путь на участки(0-1,1-2,2-конец) и проходить их в обратном порядке, вычисляя допустимые на концах участков координаты шаров(9 штук - положение,скорость,вращение).
>в дискретных моделях возможен перебор малой кровью
>в точныхмоделях ... простое решение должно быть
"в дискретных моделях" все гораздо хуже. Для непрерывных функций есть неплохо отработаная математика(возможно это называется теория оптимизации систем или [не]линейное программирование). Всегда можно посчитать значение нескольких производных в точке и предсказать отсутствие интересных точек в значительной окрестности этой. Кроме того можно предсказать приблизительное направление и расстояние
до искомого. В дискретном случае это не работает(только если это - оцифрованая непрерывная).
>необходимо выяснить состояние системы за 10 мин до данного
Это уже где-то было:-) Помоему так: уравнения физики(квантовая не считается) допускают по текущему состоянию вычисление всего, что происходило ранее. И того, что будет в будущем. Т.о. все предопределено.
> Это уже где-то было:-) Помоему так: уравнения
физики(квантовая не считается) допускают по текущему
состоянию вычисление всего, что происходило ранее. И
того, что будет в будущем. Т.о. все предопределено.
Мне видится что это справедливо только в том случае если
у тебя все время есть только одно направление изменения
состояния системы .. если же у тебя есть выбор то мне
кажется что вернуться как назад очень не просто - вот
пример - каждую секунду тебе надо скакнуть в один из
узлов
*. ...
| \__ ...
| \ ...
*-----*---* ...
/ | ...
* \ .....
|\ *----* .....
| \ / \ .....
* * `--o .....
`-------/
через 10 секуд ты стоишь в узле o - в каком узле ты был
10 секунд
понятно что сказав - "да блин в таких условиях да тыры
пыры - типа в любой мог быть" - в принципе оно так и есть
, но понятно дело что это упрощеная модель некой системы
где перескок из состояния в состояние зависим(от каких то
вещей непонятных) но трудно вычислим и трудно предсказуем
.. и наблюдая за людми которые занимаются(работают) с
подобными системами я с трудом верил что можно более
менее точно предсказать состояние, а они(между прочим
классные программисты) делают это практически со 100%
успехом .. впринципе все это можно было бы переложить на
программу если бы факторами влияющими на вероятность
перескока в одно из состояний не был бы человеческими -
то есть не было ло бы такого что в зависимости от того
скажет данный человек в данную секунду слово "да" или
"нет" увеличивает вероятность перехода в правый узел в
два раза, а в верхний уменьшает в 1.5 и так же влияет не
только на данный переход но на последующие ..
мне это напомнило нейросети .. например если есть
возможность расмотреть некую систему как нейросеть, а
состояние систему как веса каждой ячейки, то впринципе
можно воссоздавать состояние системы(возможно не точно,
но очень близко) за счет элементов которые мало
влияют(несут малую долю информации) на общее состояние
системы [не обязательно это относится к нейросетям - к
любой системе просто мне что то подумалось что возможно
любую систему можно представить как нейросеть] .. это в
свою очередь мне напомнило фильм рыбу меч где чувак грил
мол:
- Ты бы убил невинного ребенка ради общего благополучия
людей?
- Я нет.
- Я разочарован, это же великое дело.
- А что если 10 невинных людей или 1000.
- Правильно мыслишь, а что если 100000?"
Выбор делается исходя из каких-то предпосылок. Которые можно учесть.
В общем случае случайность процесса есть свойство не процесса, а наших о нем знаний(или возможностей обработки). Броуновское движение случайно только до того времени, когда мы сможем узнать и обработать данные об состоянии всех молекул в исследуемой системе. Так и в других случаях.
А работа экспертов (и нейронных сетей) основывается на простом знании того, как _обычно_ ведет себя система в таких-то условиях.
Что до системы "с перескоками" - типичный марковский процесс(если я правильно помню термин) - тщательно изученая система, с развитыми методами анализа. По зрелому размыщлению понимаешь, что математики изучили и разработали методы анализа для большинства реально существующих задач, и самая сложная часть работы - угадать название книги, в которой описано все, что нужно для решения текущей проблемы.
Да блин, я в C++ разочаровался однозначно. Во первьiх зклектика немерянная, поддержка плохо совместимьiх фич в одном флаконе. Не идеальньiй синтаксис. Не идеальная семантика. Рестриктного наследования нету, placement delete нету, переменньiх-меток нету -- to name a few. Ассертньiх возможностей встроенньiх в язьiк очень мало. Виртуальное наследование проработано по остаточному принципу, не оптимально, возможностей указать явно тип most derived object нет (хотя например для обьiчного наследования Страуструп гордится что придумал всякие dp->Base::foo()).
Рискую показаться попугаем, но система типов в том же хаскеле(и еще в куче функциональных языков) очень хороша. И ОО туда очень приятно ложится. Впрочем это на мой вкус.