Здравствуйте, jazzer, Вы писали:
AC>>Но я знаю людей которые предпочтут MFC, и будут правы поскольку они его очень хорошо зают и все их задачи удачно решаются в терминах MFC. AC>>И у них есть огромная база готовых решений под их задачи.
J>только это будет не С++-программер, а MFC-программер. J>Потому что его нельзя будет использовать, например, в юниксовом проекте — там нету никакой MFC.
Почему тогда человек, знающий BOOST, но не знающий ACE, будет C++ программером, а не BOOST программером? Ведь его нельзя будет использовать на многих платформах на которых BOOST просто не живет.
Re[13]: Проф. пригодность, boost, Александреску и Ko
Привет.
AC>Дык я о том, что или-или — это подход сомнительный, но очень горячо отстаиваемый. Я говорил про _и_. AC>И еще я говорил про BOOST, например. Есть к примеру в бусте замечательный format. У меня тоже есть, но не такой сложный, более быстрый и четко соответствующий _мом_ требованиям и не делающий того что мне _не_ нужно. Вопрос, прав ли я, что использую свой, а не из BOOST'а?
Нормально отнесусь. Я вполне понимаю, что есть места, не нужны универсальные решения.
Лично у меня такие куски есть — максимально заточенные под конкретные типы данных даже, а не просто под задачу. После тестирования разных вариантов.
Правда это так сделано было после написания простым способом с использованием "трактора" — потом профайлер показал, что
там надо переделывать. Я это сразу подозревал, но разработка идет по своим законам — сначала надо сделать хоть что-то работающее, чтобы вовремя понять, что сделано что-то не так.
AC>Как лично ты отнесешся увидев, что в коде используется класс рамером в ~200 строк, а не 5 фалов плюс ядро буста, для которого вообще-то, по уму, все дцать мегов за собой тащить надо? Или используется не STL строка, для которой многие вещи неоднозачны или не определены, а своя. Причем совместно с STL алгоритмами, векторами, мапами... Интересно, например, твое мнение на эту тему.
Нормально отнесусь — у меня есть и побольше классы, решающие вроде бы те же задачи, что и стандартные, но с учетом всех условий, что позволяет им работать намного быстрее и меньше памяти есть. Опять же — только в конкретном типе задач. В универсальных библиотеках таких классов нет, и слава богу — они же не универсальны...
Правда я всегда сначала стандартными велосипедами пользуюсь, а потом уже пятиколесные изобретаю, если действительно надо — по причине из предыдущего пункта.
--
Vitaly Belekhov
Re[19]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Alexey Chen, Вы писали:
J>>только это будет не С++-программер, а MFC-программер. J>>Потому что его нельзя будет использовать, например, в юниксовом проекте — там нету никакой MFC. AC>Почему тогда человек, знающий BOOST, но не знающий ACE, будет C++ программером, а не BOOST программером? Ведь его нельзя будет использовать на многих платформах на которых BOOST просто не живет.
ACE шагает по стране?
--
Vitaly Belekhov
Re[20]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, VVB16, Вы писали:
VVB>ACE шагает по стране?
Типа того. Дурной пример, он как известно заразительный . На моей памяти, он лет пять как шагает.
Здравствуйте, Alexey Chen, Вы писали:
AC>Дык, а зачем пытаться обьять необьятное? Особенность же 'наследует идеи STL' трудно назавать плюсом. Это именно особенность.
Основная идея STL кроется в ее первой букве — Standard. Это не особенность — это огромный плюс.
AC>Кстати, идеи STL местами тоже слишком универсальны... в результате чего, меня, например, иногда упрекают, что здесь вот, я типа не использовал STL, а писал свое. Как же так? А то, что свое везде работает одинаково [...]
Кто сказал, что работает одинаково? Есть ли тесты? Есть ли 10 млн. бетатестеров? Есть ли математическое обоснование эффективности? STL — стандартна, а если кто-то что-то там "написал свое", то сразу становиться вопрос — а что он там понаписал, почему он не использовал готовые решения, сколько ему на это потребовалось времени да и просто банальный: "Где деньги, Зин?", ведь экзерсисы ненавистника стандартов, мегабайт "чужого кода" да и вовсе мистеров "а-че-мне-boost-я-и-сам-так-могу" приходиться оплачивать. А потом оплачивать саппорт его кода, где в итоге не разберешься и с бутылкой.
AC> [...] как почему и сколько это будет стоить знать не надо, об этом уже подумали умные дяди. Правда потом, ингода, в гости заходит мелкий пушной зверёк, и приходится разбираться, что же эти умные дяди такого напридумывали.
В случае boost'a можно спросить этих умных дядек или пару-тройку миллионов других умных дядек, а вот в слуае "суперкомпактного" (без мегабайт ненужных библиотек) "суперэффективного" (еще бы: контролировать ошибки и ловить исключения — это же так тормозит) кода Васи Пупкина спросить вообще не у кого, Вася в запое и отключил мобильник или вообще обиделся, что его затяжную гениальность не оценили и свалил.
К>>Про "конкретные и весьма не новые подходы" — огласите весь список пожалуйста. AC>Ну, можно просто по конкретному примеру... вот совсем недвно, сделал я простинький колбэк, на что мне сказали, что я ламер, буст рулит, а Александреску давно придумал функтор .... забыв при этом внмательно посмотреть, что я написал.
О! То о чем я говорил. Если бы вы использовали что-то стандартное вопросов бы не было, а тут вы сетуете на то, что ваш коллега должен сбегать за пивом и уже с бутылкой разбираться в вашем коде. Ему за _это_ зарплату платят? На кой добавлять в разработку дополнительный хаос?
AC>И не всегда то, что он пишет хорошо подходит под задачи, о чем я кстати в его книге не видел ни слова.
Ну книги-то о другом . Там же подходы описаны, а не готовые решения .
AC>Если человек не спользует shared_ptr, а пишет свой класс в несколько строк, и не тянет за собой дцать метров сырков он ламер
Да. Эти несколько строк пожирают ресурсов (времени и денег) больше, чем стоимость жестких дисков, процессоров и трафика, которые потребовались бы для обслуживания "дцать метров сырков", да и то в случае, если эти строчки будут работать. Не интересно.
AC>Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны.
Просто допустите мысль, что это не мода, а средство снижения издерждек в острой конкурентной борьбе, и на сегодняшний день — мера очень эффективная (может завтра это будет .NET, а может что-то еще). И будет вам счастье.
Re[4]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Frostbitten, Вы писали:
F>Здравствуйте, Alexey Chen, Вы писали:
AC>>Дык, а зачем пытаться обьять необьятное? Особенность же 'наследует идеи STL' трудно назавать плюсом. Это именно особенность. F>Основная идея STL кроется в ее первой букве — Standard. Это не особенность — это огромный плюс.
Это решение которое не вызвало отрицания у всех представителей комитета — компромис, тобишь.
ИМХО, он однобок, крив и монструозен, но тем немение он достаточно 'полит корректен'.
AC>>Если он не использует мега-bind и function, а стыдно сказать, пишет свой кусочек кода в несколько строк он недостоен быть C++ программером Да, мода рулит! Собственно, об этом я говорил, а не о том что в C++ не нужны шаблоны. F>Просто допустите мысль, что это не мода, а средство снижения издерждек в острой конкурентной борьбе, и на сегодняшний день — мера очень эффективная (может завтра это будет .NET, а может что-то еще). И будет вам счастье.
Нет не допущу. И сделаю это аргументированно.
О чем вы хотели сказать? Что распределенее сложности между компонентами/библиотеками позволяет знать чтолько их интерфейсы и не греть мозги по их устройству. Это несомненно снижает издержки, и, как нестранно, требуемый уровень программистов. Все логично. И очень правильно по поводу Java или C# и вообще .NET языков. Но у native C++ есть маленькая особенность. Малюсенькая ошибка в коде, который пишет/сопровождает студент Вася Пупкин, может легко порушить мега-сложную либу, порушить так, что проект придется свернуть. Это я конечно утрирую, но думаю, идея о том, что использование внешнего сложного кода без понимания его работы (именно работы а не использования) именно в плюсах чревато крахом проекта. И я уверен что, 90% пользующих BOOST, да и STL тоже, не понимают как там все работает.
Для 'снижения издерждек в острой конкурентной борьбе' при отсутствии кадров, лучше использовать песочницы типа Java или .NET.
Re[5]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Alexey Chen, Вы писали:
AC>Здравствуйте, Frostbitten, Вы писали:
F>>Просто допустите мысль, что это не мода, а средство снижения издерждек в острой конкурентной борьбе, и на сегодняшний день — мера очень эффективная (может завтра это будет .NET, а может что-то еще). И будет вам счастье.
AC>Нет не допущу. И сделаю это аргументированно. AC>О чем вы хотели сказать? Что распределенее сложности между компонентами/библиотеками позволяет знать чтолько их интерфейсы и не греть мозги по их устройству. Это несомненно снижает издержки, и, как нестранно, требуемый уровень программистов. Все логично. И очень правильно по поводу Java или C# и вообще .NET языков. Но у native C++ есть маленькая особенность. Малюсенькая ошибка в коде, который пишет/сопровождает студент Вася Пупкин, может легко порушить мега-сложную либу, порушить так, что проект придется свернуть. Это я конечно утрирую, но думаю, идея о том, что использование внешнего сложного кода без понимания его работы (именно работы а не использования) именно в плюсах чревато крахом проекта. И я уверен что, 90% пользующих BOOST, да и STL тоже, не понимают как там все работает.
AC>Для 'снижения издерждек в острой конкурентной борьбе' при отсутствии кадров, лучше использовать песочницы типа Java или .NET.
Т.е. у тебя есть мегасложные проекты на несколько мегов сырцов, но которые ты в состоянии сам весь понять и легко найти баги? Так чтоли получается?
Тебе уже далеко не 1 человек тебе пишет, что экономически не обоснованно и нисколько не выгодно, в случае реально серьёзного приложения.
Конечно, если у тебя классов пара штук и строчек аля пару сотен (или даже тысяч), то, конечно, без проблем.
Но имхо речь идёт о системах посложнее, где надо учитывать гораздо больше рисков.
А про песочницы соглашусь, но STL это тоже отчасти "песочница".
А если наплевать на все песочницы, то почему бы на ассемблере проги не писать? Или, лучше, вообще в машинных кодах, зачем нам буквенное представление?
Утрирую, конечно
Re[6]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Alexey Chen, Вы писали: К>Т.е. у тебя есть мегасложные проекты на несколько мегов сырцов, но которые ты в состоянии сам весь понять и легко найти баги? Так чтоли получается? К>Тебе уже далеко не 1 человек тебе пишет, что экономически не обоснованно и нисколько не выгодно, в случае реально серьёзного приложения. К>Конечно, если у тебя классов пара штук и строчек аля пару сотен (или даже тысяч), то, конечно, без проблем. К>Но имхо речь идёт о системах посложнее, где надо учитывать гораздо больше рисков.
Мнея просто умиляют коменты с этого форума, в которых люди говорят про абстрактные сложные системы, в которых типа....
Да есть такие системы, всего я естественно в них не знаю, но багу (не из предметной области) найти смогу, и именно по причине отсутствия там сложных решений. B STL там используется и своие решения. А вот BOOST'а нет и не будет. Просто к сведенью, время создания утильных классов для таких систем несоизмеримо с реализацией предметной облости.
Кстати встречный вопрос, как много ты сделал _законченых_ и _комерчески_успешных_ проектов, длительность хотябы в пару-тройку лет и командой человек шесть-пять? Которые живут и развиваются. Можно не отвечать. Это просто для размышления о том, на тему чего ты тереотезируешь.
К>А про песочницы соглашусь, но STL это тоже отчасти "песочница". К>А если наплевать на все песочницы, то почему бы на ассемблере проги не писать? Или, лучше, вообще в машинных кодах, зачем нам буквенное представление?
Я разве предлогал не сто-то наплевать? Я обратил внимание на специфику программирования на C++, про которую 'теоретики', очень часто забывают.
Re[4]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Frostbitten, Вы писали:
F>Здравствуйте, Alexey Chen, Вы писали:
AC>>Дык, а зачем пытаться обьять необьятное? Особенность же 'наследует идеи STL' трудно назавать плюсом. Это именно особенность. F>Основная идея STL кроется в ее первой букве — Standard. Это не особенность — это огромный плюс.
Если и плюс, то в кавычках.
Еще один пример — реализация std::list::size() в stlport как return distance(begin(),end());
std::string это вообще кусочек гемороя.
Хотя ярые stl-исты от него всячески отрекаются
Если всегда и везде использовать одну и ту же импелементацию
(это если повезёт и это возможно), то отсюда вопрос — а при чём тут stl?
Практика показывает, в большинстве конкретных случаев можно
написать более оптимальный по нужным параметрам (скорость<->место) контейнер/класс/алгоритм.
Мнение о сложности тестирования и потенциальной глючности считаю преувеличенным
В одноразовом коде, где скорость и т.д. не важны,
я не раздумывая юзаю stl. В "производственном" коде — только как следует подумав.
Кстати, вопрос то оригинальный был больше про boost, чем про stl
Пока что я увидел только утверждения по поводу того,
что в бусте есть *_ptr, препроцессор (оспорено) и биндеры.
А нужен ли весь этот вагон кода, ради нескольких условно полезных вещей?
Здравствуйте, Alexey Chen, Вы писали:
VVB>>ACE шагает по стране? AC>Типа того. Дурной пример, он как известно заразительный . На моей памяти, он лет пять как шагает.
А в ACE-то ты что плохого видишь? Вполне себе приличная либа.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Vogul, Вы писали:
V>Здравствуйте, Alexey Chen, Вы писали:
V>Создание программных продуктов — это бизнес. Использование различных библиотек позволяет заработать больше денег и поэтому в основном, сейчас, программисты пишут программы, напоминающие многоруких монстров, у которых руки — ноги связаны, все, кроме пары рук и ног, эти программы идут по своей дороге жизни, упорно преодолевая все неровности пути. Если надо специальную руку, то неважно, что с ней идет еще с десяток других, пусть будут авось пригодятся. И с точки зрения бизнеса — это правильно, потому что позволяет зарабатывать на коде, который будет работать не у всех, но заплатять за него все, кто купил продукт. И хорошо, что пользователи не могут видеть внутреннюю структуру программ.
V>Но с другой стороны есть еще "Дон-Кихоты" програмирования. Они до предела оттачивают каждую функцию, каждую строчку и создают простые и элегантные программы, неповторимые по своей сути, которые с невообразимой легкостью преодолевают все неровности и ухабы, встречающиеся у них на пути.
V>В программировании, как и в любой другой профессии есть свои топ-дизайнеры и свои Да Винчи. Главное выбрать — к чему стремиться.
По-моему, об этом в конечном итоге и идет речь. Как там, "тварь я дрожащая или право имею" (на творчество). Зарубим тупым предметом старушку STL!
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Alexey Chen, Вы писали:
AC>>Здравствуйте, Курилка, Вы писали:
К>>>Я не ослышался, или MFC нонче лучше STL считается? AC>>Я разве сказал лучше? Я привел вполне себе аргумент.
AC>>Но я знаю людей которые предпочтут MFC, и будут правы поскольку они его очень хорошо зают и все их задачи удачно решаются в терминах MFC. AC>>И у них есть огромная база готовых решений под их задачи.
J>только это будет не С++-программер, а MFC-программер. J>Потому что его нельзя будет использовать, например, в юниксовом проекте — там нету никакой MFC.
J>Это как раз напрямую касается вопроса о профпригодности. J>Вот ты, насколько я понимаю, знаешь и понимаешь и STL, и boost,
Ты вот лучше объясни, почему я потроха STL знаю лучше, чем многие её адепты?
J>соответственно твоя ценность как программиста гораздо выше, чем ценность программиста, знающего только MFC, и уж подавно выше ценности программиста, знающего только свои велосипеды.
Да брось ты. Неужели осовение любого библа, хоть STL, хоть MFC, требует десятилетних усилий? А если так, то может это библо плохое?
Здравствуйте, Sinclair, Вы писали:
S>Вся практика менеджмента разработкой софта гласит: "Не изобретай". Каждое отступление от стандарта должно быть обосновано. Творчество — очень трудный, дорогостоящий, а главное — вредный процесс.
И теория примерно о том же говорит — "оставь мозги за воротами...". Ну и — ну их в одно место! Антон, не пугай народ. Эдак мы докатимся до того, что помнить наизусть — лучше, чем понимать суть явлений.
P.S. Насколько я понял, ты сослался на практику менеджмента не иронии ради, а усиления аргументации для.
... << RSDN@Home 1.1.3 stable >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[22]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Геннадий Васильев, Вы писали: VVB>>>ACE шагает по стране? AC>>Типа того. Дурной пример, он как известно заразительный . На моей памяти, он лет пять как шагает. ГВ>А в ACE-то ты что плохого видишь? Вполне себе приличная либа.
Хм, вроде как я не сильно очепятываюсь, слова, вроде, вполне читаемые получаются Где я сказал что она мне не нравиться? Или имелся в виду 'дурной пример', дык это я про то, что оно не BOOST и не STL и даже называется по другому.
Re[18]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Alexey Chen, Вы писали:
AC>>На тему не изобрети. Для офшорной разработки и конвеера, это правда, для создания собственных высокотехнологичных продуктов продуктов — нет. Конкуренты (которые изобретают) сожрут. Я занимаюсь разработкой продуктов. S>Сильный аргумент. Опровергнуть не могу, т.к. продуктов не разрабатывал. Хотя нутром чую ( (С) В.Корнеев), что и там будет справедливо. Сведя изобретательство велосипедов к минимуму, ты высвободишь дорогостоящие изобретательские ресурсы на изобретение конкурентных преимуществ.
Извините, что влезаю, но если конкурентное преимущество это скорость и компактность, и увереность в багоустойчивости своего кода (если используется сторонняя либа без исходников), при условии конечно что всё оттестено до безумия, то тогда хочешь или не хочешь, а придумывать свои велосипеды приходиться.
Приведу пример, делаем сложный framework для бизнес програм, что сами разработали:
1. Протокол вызова удаленных процедур (аналог dcom);
Был вариант изначально использовать компоненты dcom, но как только поняли, что будем делать кросс-платформенный фреймворк, пришлость разрабатывать свою систему (какие-то левые порты dcom под линухами не катили, а corba нам идейно не подходила). Получилось даже очень и очень, не такое универсальное, как dcom, но очень производительное и кроссплатформеное.
2. Компонентную архитектуру;
Опять таки думали на com'е въехать.
3. Gui контроллы;
Та же опера, qt, wxwindows и еще какая-то кроссплатформенная лабудень нам не подходила (качеством)
... еще много чего, но там уже не изобретение колеса, а "больше"
Может я это всё привел не к месту, но например мы многое что изобрели (в том числе и велосипеды, но свои ), так как делаем как раз "собственные высокотехнологичные продукты".
p.s. а stl мы сами напильником заточили
... << RSDN@Home 1.1.3 stable >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Re[5]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Шахтер, Вы писали:
K>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг. K>>А вот Саттера и Мейерса очень рекомендую. K>>Именно как популизацию грамотного стиля и методик программирования на C++.
Ш>Все трое -- ламеры.
А вот это мощно, я помню в своё время считал Вейерштрасса, Абеля, Коши просто м*даками
p.s. а ведь великие люди были.... чо то я бред понёс...
... << RSDN@Home 1.1.3 stable >>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Re[19]: Проф. пригодность, boost, Александреску и Ko
Здравствуйте, Shady, Вы писали:
S>Здравствуйте, Шахтер, Вы писали:
K>>>Ну Александреску я бы не рекомендовал читать новичкам, лишняя нагрузка на мозг. K>>>А вот Саттера и Мейерса очень рекомендую. K>>>Именно как популизацию грамотного стиля и методик программирования на C++.
Ш>>Все трое -- ламеры. S>А вот это мощно,
Да ладно, это естественно, гипербола.
Хотя, если серьёзно, тот же Мейерс частенько лажает.
S>я помню в своё время считал Вейерштрасса, Абеля, Коши просто м*даками
Ну это зря.
S>p.s. а ведь великие люди были.... чо то я бред понёс...
Здравствуйте, Шахтер, Вы писали:
Ш>Ты вот лучше объясни, почему я потроха STL знаю лучше, чем многие её адепты?
Подозреваю, потому, что ты — клевый программер
И, как минимум, изучал аспекты использования STL в своих задачах, причем не абстрактно, а с профайлером и исходниками в руках.
J>>соответственно твоя ценность как программиста гораздо выше, чем ценность программиста, знающего только MFC, и уж подавно выше ценности программиста, знающего только свои велосипеды.
Ш>Да брось ты. Неужели осовение любого библа, хоть STL, хоть MFC, требует десятилетних усилий?
По-моему, слово "десятилетний" впервые всплывает в этом твоем сообщении.
По крайней мере, я ничего похожего не говорил.
Ш>А если так, то может это библо плохое?
C какой точки зрения? Вот упомянутая MFC — плохая библиотека?
Во многих технических аспектах — да.
В маркетинговых — нет. Потому что море отлично работающего кода под Win32 написано с использованием MFC.
И, кстати, MFC — это та же STL, но для Win32.
Потому что при всех ее недостатках она является реальным стандартом для программирования под Win32.
Причем быстрого программирования под Win32, потому что на MFC приходится писать в разы меньше кода по сравнению с WinAPI.
И, соответственно, ценность программиста, знающего MFC, несомненно выше ценности программиста, знающего только сишное WinAPI.
Я говорю в среднем, естественно. Не спорю, есть асы в WinAPI, которые заткнут за пояс десяток MFC программеров.
Но только на своих специфических задачах.
Для большинства же реальных задач уровня MFC хватает за глаза, и апишный хакер будет уже не просто оверкиллом, он будет вреден для проекта.
Тот же пример с вектором, который ты сейчас вынес на обсуждение в форуме С/С++: он в чем-то лучше std::vector, в чем-то — хуже, и главный вопрос, который остается — стоит ли игра свеч?
Т.е. стоит ли тот выигрыш, который ты получаешь по сравнению с конкретной реализацией STL (кстати, а действительно ли ты нашел и соптимизировал узкое место в программе, или это просто были мысли вслух?), с проблемами этого же решения, если оно работает не со строками, и с проблемами сопровождения (потому что программисту еще нужно будет въехать и в твой код, а STL он уже знает)?
P.S. И, в общем-то, мой тезис остается в силе.
Ибо даже если ты лично ты не используешь STL, ты можешь в каждом конкретном примере объяснить, почему, что как минимум подразумевает знание STL.
Следовательно, твоя стоимость как программиста, по сравнению с программистом, не знающим STL — выше.
. На моей памяти, он лет пять как шагает.
Эдак мы докатимся до того, что помнить наизусть — лучше, чем понимать суть явлений.
