LINUX.ORG.RU

C++


0

0

Вот я тут подумал - почему народ все тянется к С++ и не 
программит на С? С++ этоже такой немеряный отстой .. я не
говорю о том что ООП кал - ООП супер вещь но на С он явно
не ложится .. если нужен обязательно ООП подход и писать
надо на С - то все(может быть почти все) можно 
реализовать на С например классы или наследования 
достаточно простым путем.

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++
★★

Вот я подумал: почему народ пилит лес бензопилами и не хочет пилить лобзиками? Лобзик - это же такой рулез! Я лобзиком из фанерки такие кульные штуки выпиливал в детстве! А бензопила - отстой! Попробуй выпили бензопилой по фанерке! Тут же все поломаешь к чертям! А лобзиком все гораздо удобнее и нагляднее! Я вот только сейчас лобзиком перепилил карандаш. Раз можно перепилить карандаш, значит можно и сосну в три обхвата. Так что давайте ребята - нефиг юзать всякий отстой.

anonymous
()

Страуструп вообще мудило мне видится - не рюхает он ни хрена и бензопила у него галимая получилась - бензина хватает только на 10 минут и лезвие ломается через каждый час .. и держать ее надо в идеале четырмя с половиной руками и возможно надо еще снизу поддерживать специальной поддержкой для бензопилы которая крепится к поясу .. и после использования возможны побочные эффекты типа чувак не сможет пилить нечем кроме нее

lg ★★
() автор топика

А если по существу - то сюда еще нужно:
- таблицу виртуальных функций и полиморфизм
- поддержку RTTI (у меня список указателей на базовый класс, а мне приспичило
сделать что-то специфичное для потомка - но я должен быть уверен, что я могу
безопасно привести указатель к типу).
- вызовы конструкторов и деструкторов в правильном порядке при сложном наследовании
- самое главное: поддержку всех библиотек, написанных на С++
- ну и по мелочи: инапсуляцию данных, разрешение имен, шаблоны
(ах да, у нас есть препроцессор, немного потренироваться и нет проблем!)
ЗЫ: мне и самому С++ не особо нравится. Но если задача хорошо ложится на
С++, то я буду писать на С++. Если задача хорошо ложится на lex/yacc, я буду использовать их,
если надо написать скрипт, то буду использовать shell или perl. И т.д.

anonymous
()

1) Слишком многословно.

2) Все (в т.ч. рутинные вещи) делаешь сам, а компилятор филонит.

3) Хочешь сделать ACOS (ANSI C Object System)? А пупок не развяжется?

P.S. Да и собственно к ООП все эти наследования имеют слабое отношение. Базовых идей в ООП всего две - 1) Все есть объекты. 2) Объекты общаются между собой обмениваясь сообщениями. А уж как и на каком языке это будет реализовано - дело дцатое.

anonymous
()

На самом деле кроме объектов и сообщений есть еще и иерархия классов и объектов. По Бучу - пятый признак сложной системы - эволюционность и развитие из работающих прототипов. Если язык объектный, то он эту концепцию поддерживает изначально. В С++ в качестве прототипов используются базовые классы.

anonymous
()
Ответ на: комментарий от lg

>Страуструп вообще мудило мне видится - не рюхает он ни хрена и бензопила у него галимая получилась

Докажи

PETER ★★
()

Этот мудила просто выбрал самый популярный язык - если бы в то время был бы basic самым значимым - имели бы мы basic++ - и было бы это тоже таким же говном

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

lg ★★
() автор топика

2 PETER да а че там доказывать - создал более менее работающий C++ с хрен знает какой попытки(все помнят C with Objects?) и в итоге получилось говно. Свои мысли в книжке смог сформулировать более менее только с третьего или четвертого раза ...

lg ★★
() автор топика
Ответ на: комментарий от anonymous

> На самом деле кроме объектов и сообщений есть еще и иерархия классов и объектов. По Бучу - пятый признак сложной системы - эволюционность и развитие из работающих прототипов. Если язык объектный, то он эту концепцию поддерживает изначально. В С++ в качестве прототипов используются базовые классы.

Классы? Это просто удобное решение. Популярный технический трюк, "паттерн" как теперь модно выражаться. _Необходимости_ в классах для ООП нет.

P.S. Вы уверены, что под "эволюционностью и развитием из работающих прототипов" Буч понимал именно наследование? Мне казалось, что он имел в виду легкость модификации уже имеющейся и работающей ОО-системы, нет?

P.P.S. Сегодня же перечитаю Буча. Люблю такую беллетристику.

anonymous
()

Да что вы все об ООП, да ООП! Есть универсальные языки, а есть заточенные под конкретную задачу.
На одном ООП свет клином не сошелся. Есть еще и задачи синт. разбора, запросы к базам,
задачи, которые хорошо ложаться на функциональные языки типа ocaml. Но даже
когда пишешь на универсальном языке, то сначала раскладываешь предметную область
на систему абстракций, потом реализуешь эти абстракции на языке, и уже потом
используешь их для решения задачи. По сути на заключительном этапе
программирование уже идет не на изначальном универсальном языке, а на
языке формализованных и реализованных абстракций. Проблемный язык содержит их изначально.
Универсальный дребует дополнительного этапа. Разница по сути может быть
в деталях на уровне синтаксиса - не более. С этой точки зрения С - тоже не фонтан,
причем сильно не фонтан. Хорошо бы если бы был универсальный язык с открытым
синтаксисом, чтобы при реализации системы абстракций не быть связанным
условностями этого языка, но нету такого....

anonymous
()

Да что вы все об ООП, да ООП! Есть универсальные языки, а есть заточенные под конкретную задачу.
На одном ООП свет клином не сошелся. Есть еще и задачи синт. разбора, запросы к базам,
задачи, которые хорошо ложаться на функциональные языки типа ocaml. Но даже
когда пишешь на универсальном языке, то сначала раскладываешь предметную область
на систему абстракций, потом реализуешь эти абстракции на языке, и уже потом
используешь их для решения задачи. По сути на заключительном этапе
программирование уже идет не на изначальном универсальном языке, а на
языке формализованных и реализованных абстракций. Проблемный язык содержит их изначально.
Универсальный дребует дополнительного этапа. Разница по сути может быть
в деталях на уровне синтаксиса - не более. С этой точки зрения С - тоже не фонтан,
причем сильно не фонтан. Хорошо бы если бы был универсальный язык с открытым
синтаксисом, чтобы при реализации системы абстракций не быть связанным
условностями этого языка, но нету такого....

anonymous
()

Оба-на! Ну и глюки на серваке! Плодитесь и размножайтесь!

anonymous
()

во! дельные мысли .. на ООП свет клином не сошелся. И если человеку програмещему на С дейстивельно необходимо ввести абстракцию типа класс или наследование он может спокойно это сделать и не нужны ему никакие C++. А если человек задумал везде использовать ООП(типа это модно и супер юзабельно) подход и начинает _всё_ писать на С++ то он мудак.

lg ★★
() автор топика

Обратное тоже верно: если есть простое решение на С++ или вообще надо вызвать утилиту из shell,
а человек упертый и вместо этого все время пишет программы на С, то он - ну ты типа понял...

anonymous
()

ООП - для более высоких языков

Очевидно, что для каждой задачи есть языки подходящие и не очень. И есть языка "общего" назначения - одинаково(плохо) подходящие для широкого круга типов задач. Если программист хорошо знает один из таких языков - он будет продолжать его использовать. Ибо ему платят не за изучение языков, а за написание программ. Недополученая в результате эффективность не учитывается - ибо сложно доказать, что она вообще могла бы быть.
Это можно считать инерционностью технологий - массовое внедрение новых альтернатив возможно только при большом давлении со стороны - либо компаний, продвигающей технологию(sun+java, ms+c#) - либо конкурентов, получающих преимущества от более эффективной технологии. Но последнее сложнее - по причине "страха" перед новой технологией. Цитируя кого-то "никто еще не был уволен за выбор C++". А зря;-)
Возвращаясь к предмету спора: предлагать C на замену C++ неправильно. C++ испольуют там, где он лучше C. И заменять один на другой только по причине "это такой немеряный отстой" - глупо. Должны быть какие-то реальные(*) преимущества.

Так что Haskell тебе в руки, lg. :-)

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от lg

lg! Несколько недель назад ты в галерее раздавал хорошие советы по аутотренингу.

Воспользуйся собственным советом - повтори про себя раз 500 "Синтаксис языка и ООП - вещи разные". "ОО-язык - язык, который дает максимальное удобство для ООП, а не тот, в котором есть классы или наследование".

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

anonymous
()

И вообще все можно паписать на всем!!!

anonymous
()

хаскел был уже в моих руках повертел его повертел да и не нашел что написать на нем действительно дельное и полезное.
возможно например такое (дан бильярдный стол(с параметрами), даны шары(с параметрами)[уже расставлены], дан набор знаний типа:
* ударить надо по зеленому шару
* зеленый шар не должен касаться красного
* зеленый шар обязан хотя бы раз коснуться борта
* черный шар должен закатится в верхнюю правую лузу
* желтый должен закатится в среднюю нижнюю лузу
* черный шар должен закатится первым
...
дать это все дело проге и она посчитает в какую точку битка и с какой силой надо ударить чтобы удовлетворить все условия либо выдать что это невозможно .. может кто нибудь возмется на досуге ? :))

я не предлагаю C как замену C++ я говорю что если в представлении реализации какой то вещи возникает понятие класс - то у народа мнгновенно происходит ассоциативная связь с C++ и они делают выбор языка в пользу C++ _только_ по этой причине .. пожалуй соглашусь с тем что народ выбирает C++ как основной инструмент потому что за это не увольняют :)

lg ★★
() автор топика

!!! IMO !!!

Ну, я вообще думаю, что ООП - ошибка природы. В свое время эту парадигму
раскручивали, как очередную панацею -- сколько их было! Лисп, форт, пролог,
структурное программирование, РАД, итдитп -- и, как всегда, имеем сухой остаток
- ЦеПП. Не самый элегантный, не самый шустрый, не самый простой, но - работающий,
а, самое главное, ОЧЕНЬ раскрученный язык.

Я в свое время (лет 10 назад) сильно увлекся ООП. Но потом понял, что программисту
ООП не дает ничего, кроме лишнего геммороя. Другое дело - с точки зрения создания
коммерческих систем ООП в инкарнации ЦеПП оказался весьма полезным, ибоимеет мощные
механизмы скрытия, позволяющие разрабатывать систему независимым разработчикам в
условиях "коммерческой тайны" и даже торговать незаконченными кусками кода.

2lg (*) (2003-03-04 11:24:21.017):
То, что ты предложил - не наследование, а агрегация. Хотя, в принципе, разница -
чисто номинальная. Полиморфики точно так же реализуются.

Чего не хватает в Це - мощной инлайловости, как в ЦеПП.

P.S.
А у Страуструпа мозги набекрень, это ты точно подметил.

Die-Hard ★★★★★
()

кстати lg как то срубил ведя беседы(тренинг психики и мысли) с психически больными - типа проходил практику :)

а никто не видел мультик(не помню чей) как появился жираф .. очень мне это напиманает появление C++ .. мультик следующий: бегает какое-то животное(на вид типа антилопы GNU) и хавает на земле всяких насекомых, мелких животных .. рядышком ползет удав .. удав хавает GNU и офигивает .. у него появляются ноги - шея вытягивается и удав с офигевшей рожей явно не хотя того начинает жрать листву на дереве .. :)) вобщем это смотреть надо .. я ржал наверное минут 15 после просмотра .. серия мультиков называлась както типа "Эволюция" чтоли

lg ★★
() автор топика

зашел сюда случайно, но проголосую за LG и C ;)

anonymous
()

Да здесь - не партсобрание. Все равно каждый при своих останется.
Я использую С++ и меня это нисколько не колбасит. Про его недостатки знаю.
А раз знаю - обхожу. На С возвращаться смысла для себя не вижу.

anonymous
()

Такое можно написать на чем угодно. Но разработка мат. модели поведения вращающегося шара в момент соударения с бортом|другим шаром требует слишком много "досуга"...
Я подозреваю, что эффективнее решать эту задачу тщательными тренировками и игрой в трехбортовой карамболь :-).

DonkeyHot ★★★★★
()

DonkeyHot .. да допустим что модель уже готова то есть (если дано начальное расположение шаров, точка на битке наклон кия и сила удара - подав все это дело модели - она вернет конечную расстановку шаров после удара).. как решить то задачу?

lg ★★
() автор топика

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

*1, *2 стоят по углам луз - достаточно касания чтобы они 
упали.
o - стоит в центре, @ - на середине отрезка соединяющего 
o и *1, стол большой, шары из русского (70 мм или сколько
там они не суть важно)

знания:
- бить по o
- o не должен коснуться @
- *1 должен закатиться в лузу возле которой он стоит
- *2 должен закатиться в лузу возле которой он стоит
- *1 должен закатиться первым
- после того как все шары остановятся o должен стоять на 
  точке .

 \____________| |__________/1
\                          */
 |                   @      |
 |                          |
 |             o            |
 |                          |
 |                    .     |
 | ___________  ___________*\
/ /           | |          \2

lg ★★
() автор топика

Артистический бильярд большими шарами:-0?

Положим модель может выдавать не только конечное положение, но и минимальные расстояния битка до указаных точек,порядок прохода этих минимумов и координаты битка в них - иначе не проверить правильность удара.
Тогда можно разбросать по пространству возможных ударов достаточное кол-во точек, пересмотреть результаты в каждой, выбрать наиболее близкие к требуемому, и повторять то же в некоторой окрестности выбраных - несколько раз. Этот тривиальный перебор с ненулевой вероятностью выдаст близкий к правильному удар. Большая точность тут не нужна - велика погрешность вносимая физикой процесса. Пространство возможных ударов везде ограничено(направление удара[0-360],наклон кия[0-90],точка на шаре[~0.79*R*R], сила - [0-перелом:-]). Посему перебор должен быть "небольшим".

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

DonkeyHot ★★★★★
()

Интересную дискуссию развели. Вот у меня принцип такой: если задача не решается путём shell/unix utils, то я её определяю на одно из двух направлений: ANSI С или Java. Т.е. либо задача ложится под алгоритмическую модель, либо под объектную. Третий вариант - вэб - тоже Java (JSP).

anonymous
()

да да модель везде захукана .. то есть на любое событие(касание шара,прохождение определенной точки, касание борта, подскок, 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 мин до данного

lg ★★
() автор топика

Про точность. 0.01 мм для человеческой руки+глаза слишком:-). Поведение шара описывается непрерывными функциями. Посему возможно последовательное приближение. Плохо себя вести он будет только после отражения от 1-2х шаров или угла лузы(губа?). Первое, впрочем, тривиально - вначале мы сужаем область поиска до "удары, попадающие по первому шару, способные потом преодолеть расстояние до 2го(и т.д.). Или можно разделить весь путь на участки(0-1,1-2,2-конец) и проходить их в обратном порядке, вычисляя допустимые на концах участков координаты шаров(9 штук - положение,скорость,вращение).

>в дискретных моделях возможен перебор малой кровью
>в точныхмоделях ... простое решение должно быть
"в дискретных моделях" все гораздо хуже. Для непрерывных функций есть неплохо отработаная математика(возможно это называется теория оптимизации систем или [не]линейное программирование). Всегда можно посчитать значение нескольких производных в точке и предсказать отсутствие интересных точек в значительной окрестности этой. Кроме того можно предсказать приблизительное направление и расстояние
до искомого. В дискретном случае это не работает(только если это - оцифрованая непрерывная).

>необходимо выяснить состояние системы за 10 мин до данного
Это уже где-то было:-) Помоему так: уравнения физики(квантовая не считается) допускают по текущему состоянию вычисление всего, что происходило ранее. И того, что будет в будущем. Т.о. все предопределено.

DonkeyHot ★★★★★
()

Не хочу никого обидеть, но

>ANSI С или Java. Т.е. либо под алгоритмическую модель, либо под объектную

Если "под алгоритмическую" то решаем ее не лучшим для написания алгоритмов языком . Зато если "под объектную" - то не лучшим для написания объектов...

Забавные принципы однако :-)

DonkeyHot ★★★★★
()

> Это уже где-то было:-) Помоему так: уравнения 
физики(квантовая не считается) допускают по текущему 
состоянию вычисление всего, что происходило ранее. И 
того, что будет в будущем. Т.о. все предопределено.

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

   *.          ...
   | \__       ...
   |    \      ...
   *-----*---* ...
 / |           ...
*   \        .....
|\   *----*  .....
| \ / \      .....
*  *   `--o  .....
 `-------/

через 10 секуд ты стоишь в узле o - в каком узле ты был 
10 секунд

понятно что сказав - "да блин в таких условиях да тыры 
пыры - типа в любой мог быть" - в принципе оно так и есть
, но понятно дело что это упрощеная модель некой системы 
где перескок из состояния в состояние зависим(от каких то
вещей непонятных) но трудно вычислим и трудно предсказуем 
.. и наблюдая за людми которые занимаются(работают) с 
подобными системами я с трудом верил что можно более 
менее точно предсказать состояние, а они(между прочим 
классные программисты) делают это практически со 100% 
успехом .. впринципе все это можно было бы переложить на 
программу если бы факторами влияющими на вероятность 
перескока в одно из состояний не был бы человеческими - 
то есть не было ло бы такого что в зависимости от того 
скажет данный человек в данную секунду слово "да" или 
"нет" увеличивает вероятность перехода в правый узел в 
два раза, а в верхний уменьшает в 1.5 и так же влияет не 
только на данный переход но на последующие ..

мне это напомнило нейросети .. например если есть 
возможность расмотреть некую систему как нейросеть, а 
состояние систему как веса каждой ячейки, то впринципе 
можно воссоздавать состояние системы(возможно не точно, 
но очень близко) за счет элементов которые мало 
влияют(несут малую долю информации) на общее состояние 
системы [не обязательно это относится к нейросетям - к 
любой системе просто мне что то подумалось что возможно 
любую систему можно представить как нейросеть] .. это в 
свою очередь мне напомнило фильм рыбу меч где чувак грил 
мол:
- Ты бы убил невинного ребенка ради общего благополучия 
людей?
- Я нет.
- Я разочарован, это же великое дело.
- А что если 10 невинных людей или 1000.
- Правильно мыслишь, а что если 100000?"

lg ★★
() автор топика

Выбор делается исходя из каких-то предпосылок. Которые можно учесть.
В общем случае случайность процесса есть свойство не процесса, а наших о нем знаний(или возможностей обработки). Броуновское движение случайно только до того времени, когда мы сможем узнать и обработать данные об состоянии всех молекул в исследуемой системе. Так и в других случаях.

А работа экспертов (и нейронных сетей) основывается на простом знании того, как _обычно_ ведет себя система в таких-то условиях.

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

DonkeyHot ★★★★★
()

Да блин, я в C++ разочаровался однозначно. Во первьiх зклектика немерянная, поддержка плохо совместимьiх фич в одном флаконе. Не идеальньiй синтаксис. Не идеальная семантика. Рестриктного наследования нету, placement delete нету, переменньiх-меток нету -- to name a few. Ассертньiх возможностей встроенньiх в язьiк очень мало. Виртуальное наследование проработано по остаточному принципу, не оптимально, возможностей указать явно тип most derived object нет (хотя например для обьiчного наследования Страуструп гордится что придумал всякие dp->Base::foo()).

Та..

Фи..

dilmah ★★★★★
()
Ответ на: комментарий от lg

Ну ты даешь!!! Такой поток сознания!!! Уважаю!!!! 

А касательно Ц и Ц++  - дурная голова рукам покоя не дает.... 

omerm
()

smalltalk и python - самые что ни на есть языки в которых OOП легло на удивление удачно ..

lg ★★
() автор топика

Рискую показаться попугаем, но система типов в том же хаскеле(и еще в куче функциональных языков) очень хороша. И ОО туда очень приятно ложится. Впрочем это на мой вкус.

DonkeyHot ★★★★★
()

>  *.          ...
>   | \__       ...
>   |    \      ...
>   *-----*---* ...
> / |           ...
>*   \        .....
>|\   *----*  .....
>| \ / \      .....
>*  *   `--o  .....
> `-------/

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

Anonymous ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.