Если тема заинтересовала , предлагаю подумать как реализовать функционал std::vector используя typedef и абстрактные интерфейсы. Сможете ли вы провести границу в этом случае? и насколько формальной такая граница может быть ?

M>Если тема заинтересовала , предлагаю подумать как реализовать функционал std::vector используя typedef и абстрактные интерфейсы. Сможете ли вы провести границу в этом случае? и насколько формальной такая граница может быть ?

тема безусловно интересная

функциональность std::vector используя typedef и абстрактные интерфейсы не сделать, если у нас нет настоящего параметрического полиморфизма как скажем в скале (или на худой конец в яве; еще и имплициты как в скале могут потребоваться для хорошего качества) или шаблонов (как в с++)

известные варианты без ПП -- это

1. коллекции из потомков Object-а, при доставании элемента требуется даункаст

2. интрузивные коллекции -- элементу, чтобы класться в коллекцию, требуется наследование от чего-то-там

но решения по поводу "а как реально программировать log_destination" лежит немного в стороне от этих важных моментов

если бы с++ был бы хорошим языком, то там бы не было проблемы "делать хорошо или, наоборот, делать быстро, удобно и понятно даже последнему юниору"; а в с++ эта проблема есть, так что приходится выбирать

скажем, мы выбрали хорошо (как сделаны потоки или std::vector) -- а как в таком случае, позвольте спросить, передать в функцию f пару std::vector<T*> так, что T *неизвестен*, но гарантированно *одинаков* у обоих векторов? и какая сигнатура будет у функции f? вот тут-то мы вспомни про старый добрый void*, слегка прикрытый шаблонами, или не вспомним, а?

так что я не зря говорю про традиции

пример функции f, про которую я говорил:

она должна вытолкнуть (pop_back) последний элемент из вектора номер 1, и затолкать его в конец вектора номер 2 (т.е. push_back)

Здравствуйте, m e, Вы писали:

ME>функциональность std::vector используя typedef и абстрактные интерфейсы не сделать....

Вот этот момент и хотелось бы заострить. Почему не сделать, какие ограничения, чем отличается "сделать" и "не сделать"? Т.е. у вас есть понимание, что можно и как сделать, но вам тяжело это сформулировать, структуировать?

ME>но решения по поводу "а как реально программировать log_destination" лежит немного в стороне от этих важных моментов

Скорее не соглашусь. Только отмечу что пример с std::vector более яркий.

M> Сможете ли вы провести границу в этом случае? и насколько формальной такая граница может быть ?

(с разбега) я думаю, очень близка к формальной -- т.е.

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

коллекцию типа std::vector не сделать

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

ME>>функциональность std::vector используя typedef и абстрактные интерфейсы не сделать....

M>Вот этот момент и хотелось бы заострить. Почему не сделать, какие ограничения, чем отличается "сделать" и "не сделать"? Т.е. у вас есть понимание, что можно и как сделать, но вам тяжело это сформулировать, структуировать?

мне так кажется, что это в принципе тяжело -- например, в предыдущем посте я попытался это сделать, но мне пришлось запретить склейку макропроцессором; а ведь никто не гарантирован от того, что ее очень редко, но придется использовать даже в шаблонном коде!

А как на вопрос по дизайну вы бы начали отвечать ?

M>Вот этот момент и хотелось бы заострить. Почему не сделать, какие ограничения, чем отличается "сделать" и "не сделать"?

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

тогда полиморфизм в ооп сводится к полиморфизму функции по первому аргументы

т.е. грубо говоря template<class T> int f(T, int) еще можно запихать в рамки ооп

дальше, template<class T> T f(T, int) тоже более-менее запихивается в ооп -- в нашем распоряжении есть virtual function covariant return, НО уже может потребоваться, фактически, интрузивность + шаблоны в виде CRTP (для всяких функций типа clone)

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

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

M>А как на вопрос по дизайну вы бы начали отвечать ?

не-не-не! хотя, по-моему, твои вопросы по с++ представляют скорее теоретическую ценность, чем практическую, мне стало интересно над ними подумать именно с теоретической стороны, а тут дизайн

ну ладно, отвечу про дизайн

M>"Есть несколько альтернативных дизайнов раббиения функционала на модили и их взаимодействия. По каким критериям вы будете сравнивать между собой разные дизайны?"

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

код, конечно, надо стараться писать общим, но часто написание общего кода требует слишком много усилий, и проще написать частный

2. определить моменты, подобные п.1 и тем самым яснее очертить ситуацию -- т.е. скорректировать веса критериев

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

3. теперь сами критерии:

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

M>"Есть несколько альтернативных дизайнов раббиения функционала на модили и их взаимодействия. По каким критериям вы будете сравнивать между собой разные дизайны?"

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

M>"Есть несколько альтернативных дизайнов раббиения функционала на модили и их взаимодействия. По каким критериям вы будете сравнивать между собой разные дизайны?"

в тех случаях, когда время -- это деньги, естественно добавится критерий времени на разработку; но в любом случае деньги -- основное

Здравствуйте, StandAlone, Вы писали:

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

Эх, молодежь. Печально.

SA>Кодеры-задроты на марше, это печалька.

"Кодеры-задроты", это как раз те, кто кидаются модными словечками, CRM, WCF, WWF, WPF, WTF, Sharepoint, MVP etc. Настоящие инженера, имеют солидный фундемент, системное мышление и не кидаются дешевыми понтами. А интеллигентные, образованные, умные и воспитанные люди, не обзывают других "кодерами-задротами". Задумайся об этом.

Здравствуйте, gandjustas, Вы писали:

G>Самое главное что ты на этой картинке справа

Ты уже скатился, ниже некуда

___>"Кодеры-задроты", это как раз те, кто кидаются модными словечками, CRM, WCF, WWF, WPF, WTF, Sharepoint, MVP etc.

Здравствуйте, Codechanger, Вы писали:

___>>"Кодеры-задроты", это как раз те, кто кидаются модными словечками, CRM, WCF, WWF, WPF, WTF, Sharepoint, MVP etc.

Ответил отдельной веткой здесь

Автор: b-3
Дата: 03.03.12

.

Здравствуйте, __lambda__, Вы писали:

SA>>Кодеры-задроты на марше, это печалька.

___>"Кодеры-задроты", это как раз те, кто кидаются модными словечками, CRM, WCF, WWF, WPF, WTF, Sharepoint, MVP etc. Настоящие инженера, имеют солидный фундемент, системное мышление и не кидаются дешевыми понтами. А интеллигентные, образованные, умные и воспитанные люди, не обзывают других "кодерами-задротами". Задумайся об этом.

Извините, но солидный фундамент в области работы паяльником по транзисторам в эру схемотехники представляет исключительно теоретический интерес.
А кодеры-задроты, если их назвать mentally challenged geeks, задротами-кодерами быть не перестанут.
Ipso fuckto.

Здравствуйте, Codechanger, Вы писали:

___>>"Кодеры-задроты", это как раз те, кто кидаются модными словечками, CRM, WCF, WWF, WPF, WTF, Sharepoint, MVP etc.

.NET тут не причем, с тем же успехом мог сказать Java, J2EE, Spring, Hibernate.

Здравствуйте, StandAlone, Вы писали:

SA>Извините, но солидный фундамент в области работы паяльником по транзисторам в эру схемотехники представляет исключительно теоретический интерес.

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

SA>А кодеры-задроты, если их назвать mentally challenged geeks, задротами-кодерами быть не перестанут.
SA>Ipso fuckto.

Но только "кодеры-задроты", это как раз таки совсем не те люди, про которых вы говорите.

Здравствуйте, m e, Вы писали:

M>>"Есть несколько альтернативных дизайнов раббиения функционала на модили и их взаимодействия. По каким критериям вы будете сравнивать между собой разные дизайны?"

ME>1. предполагаем ли мы реюзать этот код? или это местная подсистема, которую снаружи точно никто не будет использовать?
миль пардон, но мы в галактике или сферическом вакууме? в реальности дела обстоят приблизительно так:
1) кого мы можем найти/нанять и насколько легко их разогнать и собрать заново;
2) манеры+продукт+говно (с)
3) на дизайн всем ложить, главное -- это саппорт и салеза

ME>3. теперь сами критерии:
ИМХО вы совершаете большую ошибку, пытаясь построить систему в условиях идеальной невесомости. систему нужно строить не в абстрактных рамках, а с оглядкой на сложившиеся производственные отношения. мне довелось работать в тиме, где навыки девов вообще не перекрывались и потому модули приходилось писать в стык, а в не в нахлест (блин, этот чувак не знает что такое call-back'и, ладно, хрен с ним, сделаем все на итераторах). плюс был в том, что система представляла из себя сооружение в стиле конструктора "лего" и потому любая комбинация ее элементов была работоспособна и на что-то способна. минус -- дикий оверхид. один и тот же функционал был реализован дважды, а то и трижды. вы считаете, что это минус дизайна? да, конечно, это минус. но это и плюс. если васе нужен петин функционал, то вместо того, чтобы пробивать тоннель в виде апи и получать адъ зависимостей и версионностей -- вася пишет эту часть самостоятельно и никакие изменения в петином коде его не волнуют. петин модуль можно вообще изъять из системы -- вася это даже не почувствует. к тому же дублирование функционала снижает стоимость ошибок. допустим, петя реализовал базовый алгос, который заюзан в десяти других модулях. допустим, у него там есть баг. и он распространяется на все десять модулей. а если эти модули от него независимы -- все не так уж и плохо. к тому же один и тот же алгос может работать с блоками данных в пару килобайт, а в другом модулей идентичный алгос молотит гигабайты данных. алгос один -- а реализации различны (в первом случае это просто буфер в памяти, а во втором случае гигабайты ни в ram, ни в адресное пространство не влезают и все приходится писать сильно иначе)