egorychWhite Owlесли тебе так уж хочется жить с одной функцией, ну перейди в объектную модель. Не пользуйся POD переменными.на С? можно примерчик?


На самом деле это очень удобно использовать и очень несложно надстраивать.
Из известных библиотек на этом принципе основаны Photon и IUP. Первое насквозь коммерческое (но писать под него сплошное удовольствие) а второе тут: http://iup.sourceforge.net/

Anatoly MoskovskyWhite OwlНа самом деле это очень удобно использовать и очень несложно надстраивать.
Из известных библиотек на этом принципе основаны Photon и IUP. Первое насквозь коммерческое (но писать под него сплошное удовольствие) а второе тут: http://iup.sourceforge.net/
Ну бдсм тоже для кого-то сплошное удовольствие ))Да, да... мы уже знаем что ты не умеешь писать на Си.

Anatoly MoskovskyWhite OwlДа, да... мы уже знаем что ты не умеешь писать на Си.
Че это вдруг не умею? Умею. И даже пишу, когда нет возможности использовать С++ (на данный момент это только драйвера).
Просто не вижу смысла писать на С с момента появления в С++ некоторого набора фич, которые позволяют писать код принципиально качественнее и быстрее. А конкретнее - смарт-указатели и исключения. То, что в С в принципе невозможно реализовать и то, что сокращает и упрощает код в десятки раз.Ну ты ж меня обвиняешь постоянно в неумении использовать С++... Вот наши неумения - явления одного порядка.

egorychWhite OwlНа самом деле это очень удобно использовать и очень несложно надстраивать.ты серьёзно?Да. Я серьезно.
По существу все GUI библиотеки под Си используют один из двух подходов. Либо заводят множество функций на каждый тип объекта (glib, gtk), либо идут по пути создания структур с типом структуры в качестве первого члена и switch по ним (iup, photon).
Попробовав оба, лично я предпочитаю второй (структуры и switch). Больше гибкости и намного проще в поддержке.

egorychты предлагаешь наплодить доп.структур и чудовищный switch? При том, что структуры тоже необходимо как то называть.Посмотри на С++. Когда ты создаешь библиотеку классов, ты занимаешься тем-же самым. На практике, если мы зададимся целью написать аналогичные библиотеки решающие одну и ту-же задачу (на Си и С++), то количество структур будет точно равняться количеству классов.
И switch будет совсем не чудовищный. При наследовании этот switch будет решать всего одно условие: это структура ребенок или нет? Если нет, то напрямую вызывать родительский метод. Да, это будет слегка медленнее чем подход с классами, потому что мы в рантайме будем определять какая именно это структура и какой из перегруженных методов надо вызывать, а с классами эти вопросы решатся еще на этапе компиляции.
Зато подход со структурами и switch позволяет добавлять и изменять "классы" прямо во время рантайма. Можно переопределять скины прямо во время работы. Плагины писать - не просто легко, а очень легко.

egorychТрудно не согласиться с Анатолием ))С ним легко не согласится. Достаточно просто на практике попробовать все парадигмы и увидеть их сильные и слабые стороны. А у Анатолия, к сожалению, нету широты взгляда.

egorychWhite Owl,
>>Да, я серьёзно
сознайся, ты специально делаешь вид, что наследование и перегрузка - это одно и то же, правда? )))
речь ведь шла о перегрузке функций вообще, и о перегрузке операторов, в частности )))Нет, это конечно не одно и то же, но это очень родственные вещи. Любая перегрузка функций это по существу наследование от некоего общего предка, не всегда явно обозначенного. Понимание этого факта позволяет делать перегруженные функции практически в любом языке, а не только в тех которые явно имеют синтаксис перегрузки.
А что касается перегруженных операторов... Да, это в Си сделать не получится.

egorych>>Зато подход со структурами и switch позволяет добавлять и изменять "классы" прямо во время рантайма. Можно переопределять скины прямо во время работы
ну да, шаблоны "Стратегия" и "Состояние", в плюсах их реализация выглядит красивее, потому что в нём есть встроенные средства для решения подобных вопросов, а в С приходится извращаться, как ты это не называй.Расширенный синтаксис многое может сделать "красивее". Но дело то в том, что часто можно решить задачу и на более кратком синтаксисе. Получится не менее надежно и удобно, а красота это дело вкуса :)

egorychWhite OwlДостаточно просто на практике попробовать все парадигмы и увидеть их сильные и слабые стороны.достаточно, действительно. Мой опыт мне говорит, что для объектной парадигмы лучше подходят языки, поддерживающие объектную парадигму )))
Неверно. Опыт тебе должен говорить: Использовать объектную парадигму легче на языках поддерживающих объектный синтаксис.
А так, объектную парадигму можно применить практически к любому языку. Так же как и любую другую парадигму, к любому языку. В одних случаях это будет легче, в других сложнее, но .... парадигма это парадигма.


egorychP.S. А то и Турбо-бэйсик можно языком системного программирования назвать, там ведь был доступ к прерываниям и прямой доступ в память ;-))Это надо понимать что ты не видел системных программ написанных на Quick BASIC (который брат-близнец TB, но от Микрософта)?

egorychWhite Owl,
>>Понимание этого факта позволяет делать перегруженные функции практически в любом языке, а не только в тех которые явно имеют синтаксис перегрузки.
примерчик бы... твой пример про наследование не решает главной проблемы: отсутствия однотипных имён, о которых говорил MasterZiv, тебе всё одно придётся явно называть структуры, и вместо одной головной боли ты предлагаешь добавить сразу 7 )))
Почему не решает? Очень даже решает. Просто расширь пример из 17283801 до полноценного наследования, добавь в нужные структуры указатели на функции и получишь почти полную копию С++.
Посмотри на IUP хотя бы. Там есть практически один единственный тип данных IupHandle*. Конкретные объекты создаются через IupFrame(), IupButton(), IupMenu(), etc. А дальше опять одна единственная функция IupSetAttribute(IupHandle*, ....);
И вся палитра виджетов покрывается этим набором.

egorych>>Расширенный синтаксис многое может сделать "красивее". Но дело то в том, что часто можно решить задачу и на более кратком синтаксисе. Получится не менее надежно и удобно, а красота это дело вкуса :)
не согласен, не получится "не менее надёжно и удобно". Не в "красоте" ведь дело. Если мне не надо изобретать из раза в раз таблицу виртуальных функций, то я, во первых, не ошибусь в её реализации, и, во вторых, мой код не будет загромождён ненужными рутинными подробностями, которые отлично может написать за меня компилятор.Тоже не совсем верно.
Ты будешь делать таблицу функций только на "своем" уровне. Не забывай про наследование.
Да, в С++ за тебя это компилятор сделает, а в Си надо будет в конструкторе самостоятельно наполнить эту таблицу. Но это единственная сложность.

Anatoly MoskovskyWhite OwlЛюбая перегрузка функций это по существу наследование от некоего общего предка, не всегда явно обозначенного. Понимание этого факта позволяет делать перегруженные функции практически в любом языке, а не только в тех которые явно имеют синтаксис перегрузки.
А можно пример?
Вот код на С++:


Это перегрузка функции print двумя типами аргумента.
Как с помощью понимания того что перегрузка это "наследование от некоего общего предка" сделать такую перегруженную функцию не на любом языке, а хотя бы на С? 17283801
В данном случае общий предок это "некая переменная". Ну вот и сделай себе абстрактную переменную. Это будет конечно чуть сложнее чем с POD типами, но не намного.