надоело писать често такое

нельзя ли как нибудь динамически вызвать нужный метод?

ещё вопрос, нельзя ли как-нибудь работать со свичём без enum? напрямую со значениями

А смысл какой у такой конструкции?

Тигер

map + указатель на функцию.

А может быть имеется в виду чтото такое?



Это сообщение отредактировал(а) toxx - 19.4.2010, 20:17

Фабрика команд, более усложненный случай map+указателя на функцию.

Если константы идут подряд можно вместо map'а использовать обычный массив.

можно даже если не идут, тут вопрос что важнее. Если к примеру ключ умещается в short то вполне реально создать массив размером в 65536 элементов, но взамен получить константную сложность поиска. Я так делал в одной низкоуровневой библиотеке, прирост был фантастический на аппарате с процессором 70mhz.

azesmcar
дык эмм. эту карту сначало заполнить надо.
вообщем, как реализуются паттерны фабрика или serviceLocator в с++

Это сообщение отредактировал(а) Тигер - 19.4.2010, 22:10

  ничего не поделаешь, не умеет C++ угадывать что нужно пользователю  


http://forum.vingrad.ru/forum/topic-266893...tml#st_0_view_0

ну тоже через map
а нет какой-нибудь функции каторая проверит существует ли метод в классе?

Добавлено через 3 минуты и 2 секунды
гуглил гуглил. из подтекста виднелось что это можно сделать при помощи dll?
заодно и динамическую подгрузку модулей?

нет, в run-time эта информация недоступна.

В DLL можно  через GetProcAddress.

пример "саморегистрирующийся" фабрики есть у Александреску в "Современном проектировании"

выглядит это примерно так


регистрацию метода в карте можно завернуть в макрос.

более полный пример 
http://forum.vingrad.ru/forum/topic-273518...atch/index.html
(пункт 2)

Добавлено через 1 минуту и 19 секунд
также, методы можно сделать виртуальными, и использовать какой-нибудь хак с таблицей виртуальных методов

А чем не подходит передавать указатель на функцию/метод?

Из текущей программы или динамически слинкованной библиотеки можно получить (и проверить на существование) функцию по string-имени. В POSIX.1-2001 это dlopen, dlsym и т.д., в винде какие-то winAPI-шные аналоги, кроме того на гуглокоде есть реализация dl-интерфейса под винду. Вытаскиваемая функция должна быть экспортируемой extern "C", с++-ные методы так не вытащить.

имхо : ну прежде всего тем, что автор ищет не решение задачи, а замену свитчу. А так как последнее без первого предполагает массу вариантов, то к цели придет, к сожалению, не скоро..

djamshud, покажи, как методы с extern "C" экспортировать
алсо прописывать неймспейс функции в ее имени - зло

GoldFinch, к методам extern "C" вообще не применим, кажется я писал об этом.

>алсо прописывать неймспейс функции в ее имени - зло 

Где я это предлагал?

djamshud, да, действительно, писал.

насчет неймспейсов - чтобы сохранить имя при С компоновке, придется заменять все имена функций на
namespace1_namespace2_...namespaceN_functionname,
иначе они могут начать пересекаться с другими именами

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

По сабжу же: либо, как уже предлагали, заполнить таблицу соответствия "строка"-"функция/метод", либо, если лень или по другим неозвученным пока причинам, тянуть С-функции и перекладывать ответственность за соответствие типов с компилятора на себя.

  


скорей наоборот, не любовь к неймспейсам из за того что многие не умеют их готовить  хотя С++ сам частично в этом виноват, точнее его кривость в этой области.. Но пару условных договоренностей и плюсы от неймспейсов сразу преобладают над минусами.



А наши бабушки и дедушки обходились без компа .. Долой прогресс и удобства. 
  

Оффтопик на оффтопике.

Я не говорил, что неймспейсы зло и вообще не нужны. Конечно нужны и конечно удобны. Просто если задача встает так, что они мешают, нет совершенно никакой проблемы от них отказаться, и именно эта "проблема" и связана с привычкой выдумывать длиннющие названия, разложенные по иерархии неймспейсов и классов, т.е. с неумением кратко и емко выразить смысл сущности. Хороший пример жизни без неймспейсов - POSIX, интерфейсы ядра Linux. Плохой - winAPI.

>А наши бабушки и дедушки обходились без компа .. Долой прогресс и удобства.

Си цветет и пахнет, а бабушки с дедушками уже только пахнут:D. Фу, злой юмор какой-то.

Это сообщение отредактировал(а) djamshud - 20.4.2010, 20:00

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

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

Это проблема не языка, а специалистов, которые готовили плохие библиотеки. Хорошие ведь тоже есть:).

языка тоже.. он не позволяет сделать так как хочется - чисто и красиво 

Добавлено через 24 секунды
чего то мы сильно ушли в оффтоп ))

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

Добавлено через 1 минуту и 6 секунд
>чего то мы сильно ушли в оффтоп ))

Придет модератор и порежет или отправит в холиворы:).

т.е. развивать язык и не стоит ?  и, в частности,  обещанных новшеств С++ вы не ждете ?


ну до функц. прогр. асму далеко, но в целом Вы правы, считаю.. 

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

Добавлено @ 21:00

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


Это сообщение отредактировал(а) mes - 20.4.2010, 21:00

>т.е. развивать язык и не стоит ?  и, в частности,  обещанных новшеств С++ вы не ждете?

Развивать стоит, новшеств не жду, боле того я о них слышал лишь краем уха. Но как стандарт примут, так и посмотрю, чем стоит воспользоваться, а чем нет. Я прежде всего исхожу из позиции, что нужно эффективно применять то, что есть. Да и нынешние некоторые возможности плюсов не использую: stl, хитросплетенные шаблоны (привет Александурску), исключения... может что еще забыл.

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

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

Если язык не позволяет программисту решить задачу "красиво", значит программист выбрал не тот язык или не правильно спроектировал свое решение под этот. Значит это плохой специалист. Микроскопом гвозди не забивают.

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

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


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

насчет неймспейсов, если быть объективными, то здесь "вина" не самого языка..  язык С идеологически "повторяет" модель принятую в системе, а в ней они не приняты и для введения в язык пришлось бы делать обходные пути ( как это сделано в С++), а это бы нарушило бы чистоту языка..




Что то эти два высказывания между собой не вяжутся...   
я так понимаю, что работаете на С++ в стиле С_с_классами ?.. а что ж тогда не на plain С ?

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

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

>насчет неймспейсов,..

полностью согласен. Это причина по которой их нет и, думаю, не появится.

>Что то эти два высказывания между собой не вяжутся

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

>а что ж тогда не на plain С ?

На plain C неудобно писать в объектно-ориентированном стиле, он для этого не особо предназначен.

Upd.
В плюсах еще шаблоны функций, классов и методов использую.

Это сообщение отредактировал(а) djamshud - 21.4.2010, 12:08

OpenSSL написана на plain C в ОО стиле

>OpenSSL написана на plain C в ОО стиле 

GLIB тоже, и что? На си можно сделать практически любой прыжок изподвыподверта,.. но зачем?

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

Добавлено через 3 минуты и 37 секунд

сразу видно что язык выбран под задачу ! 

Добавлено через 5 минут и 12 секунд
и все ж чем не угодила стл? 

mes, один программный продукт не обязан быть заточен в одном исполняемом файле; в одну кучу линковать все - делать мегакомбайн.

>сразу видно что язык выбран под задачу

Наверное это была ирония, но я ее не понял:).

>и все ж чем не угодила стл?

Объективно - ничем, библиотека хорошая. Но как-то давно пошло, что успешно и быстро пишу без нее. И еще очень не нравится идея "итератор на все", хотя опять же объективно она хороша.