Здравствуйте, LuciferMoscow, Вы писали:
L>>Ну уж нет. Не согласен категорически. Время сборки — очень даже ресурс. LM>Согласен. Когда стандартная линковка 10-15 минут...
Счастливый ты. А вот когда полчаса и более — этот ресурс начинаешь чувствовать физически.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
L>>>Ну уж нет. Не согласен категорически. Время сборки — очень даже ресурс. LM>>Согласен. Когда стандартная линковка 10-15 минут...
AJD>Счастливый ты. А вот когда полчаса и более — этот ресурс начинаешь чувствовать физически.
Ага... а полный билд ACE/TAO — на рабочей машине это фактически весь рабочий день. Двухпроцессорный Xeon с 2 гигами памяти справляется часа за 4. Правда, примерно половина из этого времени — запуск тестов...
Здравствуйте, SkyDance, Вы писали:
SD> Что-то, что сократит время на разработку. Писать каждый раз по функтору — ну уж нет, индейская хижина, код становится жутким.
ИМХО, гораздо важнее чтобы код легко читался, а не только легко писался. А с лямдой код действительно становится короче, но ясность, имхо, совсем не улучшается.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Left2, Вы писали:
L>ИМХО: Для функционального программирования не подходит не архитектура современных компьютеров. В конце концов, принципы ООП тоже "не родные" для железа (инкапсуляция, наследование, полиморфизм — где тут хоть что-то близкое к ассемблеру?). Для функционального программирования не подходит архитектура современного программиста и современного преподавателя института . Мы только-только "протащили" в массы ООП, а его принципы (имхо!) проще чем принципы функционального программирования.
Само по себе ФП не слишком сложно... Сложно именно перестроиться... Это просто ортогональный способ мыщления по сравинению с привычным... Но уж если его освоил, то можешь работать в плоскости, а не на оси...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, jazzer, Вы писали:
J>>Никак. Время сборки — не ресурс, если у тебя не в одном файле весь проект, конечно же. AJD>Если это занимает весь день — то ресурс.
ну, значит, у тебя весь проект в одном файле и модульность его нулевая, с чем я тебя и поздравляю.
Здравствуйте, Left2, Вы писали:
J>>Никак. Время сборки — не ресурс, если у тебя не в одном файле весь проект, конечно же. J>>Уж чем-чем, а временем сборки за удобство можно заплатить, а грамотная модульность уменьшает время сборки в разы.
L>Ну уж нет. Не согласен категорически. Время сборки — очень даже ресурс. Почему-то его очень сильно недооценивают, но он способен самым кардинальным образом повлиять на скорость разработки — читай, на стоимость (по выбору — на качество) программного продукта. И грамотная модульность способна чуть улучшить ситуацию, но не кардинально.
Как раз кардинально.
Просто разбей свою прогу на библиотеки, лучше — на динамически загружаемые — и будет тебе счастье.
И в любом случае, то, что ты в одном файле (сишном, естественно, не в хедере) заюзал лямбду, а в нем лямбды до этого не было, на времени сборки проекта практически не отразится, а пересобирать весь проект целиком, при грамотном разбиении его на модули, приходится крайне редко.
L>>Ну уж нет. Не согласен категорически. Время сборки — очень даже ресурс. Почему-то его очень сильно недооценивают, но он способен самым кардинальным образом повлиять на скорость разработки — читай, на стоимость (по выбору — на качество) программного продукта. И грамотная модульность способна чуть улучшить ситуацию, но не кардинально.
J>Как раз кардинально. J>Просто разбей свою прогу на библиотеки, лучше — на динамически загружаемые — и будет тебе счастье.
Чёрт с ним, возможно я не слишком грамотно бью свои проекты на модули. Но возьмём тот же TAO — он вроде бы неплохо разбит на динамические библиотеки. И что? Всё равно билд идёт часами даже на самых быстрых серверах. Опять же — даже при самом грамотном разбиении на модули будут куски, на которые завязана большАя часть проекта, изменения в которых неминуемо влекут за собой практически полный перебилд (в случае TAO — это хотя бы компилятор TAO_IDL). Да и интерфейсы между модулями хоть и меняются куда реже чем сами модули, но тоже не статичны — частенько приходится менять и их. Ну и не забываем что время от времени полный перебилд делать всё равно приходится (особенно если проект кросплатформенный и/или имеет несколько разных вариантов билда, а таких проектов сейчас имхо большинство).
J>И в любом случае, то, что ты в одном файле (сишном, естественно, не в хедере) заюзал лямбду, а в нем лямбды до этого не было, на времени сборки проекта практически не отразится, а пересобирать весь проект целиком, при грамотном разбиении его на модули, приходится крайне редко.
А смысл мне её использовать в одном файле? Если уж юзать лямбду — то хотя бы в бОльшей части файлов. То бишь, широко А тащить к себе библиотеку ради экономии десятка строчек кода в единственном месте программы — ну какой в этом смысл? Но как только я её начинаю широко юзать — тут же время билда увеличивается на порядок.
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, jazzer, Вы писали:
J>>ну, значит, у тебя весь проект в одном файле и модульность его нулевая, с чем я тебя и поздравляю.
AJD>Это значит что у меня в солюшене ~250 проектов, модульность нормальная и код в хеадарах не пишем
тогда не очень понятно, если все так хорошо разбито, почему сборка идет долго.
По идее, в основном ребилд должен происходить в одном только проекте в 95% случаев.
Хотя, конечно, сложно судить, не видя, что там и как.
Здравствуйте, Left2, Вы писали:
L>Ну и не забываем что время от времени полный перебилд делать всё равно приходится (особенно если проект кросплатформенный и/или имеет несколько разных вариантов билда, а таких проектов сейчас имхо большинство).
В таких случаях полный ребилд имеет смысл ставить на вечер, чтоб ночью собрался, отыграли автоматические тесты, и с утра был виден статус проекта.
J>>И в любом случае, то, что ты в одном файле (сишном, естественно, не в хедере) заюзал лямбду, а в нем лямбды до этого не было, на времени сборки проекта практически не отразится, а пересобирать весь проект целиком, при грамотном разбиении его на модули, приходится крайне редко. L>А смысл мне её использовать в одном файле? Если уж юзать лямбду — то хотя бы в бОльшей части файлов. То бишь, широко А тащить к себе библиотеку ради экономии десятка строчек кода в единственном месте программы — ну какой в этом смысл? Но как только я её начинаю широко юзать — тут же время билда увеличивается на порядок.
Ну не знаю. У меня до лямбды руки не доходили, ограничивался boost::bind, особой разницы не заметил.
И, опять же, вряд ли ты далешь массированные изменения кода без промежуточной компиляции, так?
Стало быть, в большинстве случаев приходится пересобирать только один файл.
J>В таких случаях полный ребилд имеет смысл ставить на вечер, чтоб ночью собрался, отыграли автоматические тесты, и с утра был виден статус проекта.
Да, конечно — именно так и делалось. Но в итоге получается что ты можешь сделать 5 полных ребилдов в рабочую неделю. Самый что ни на есть ресурс.
J>И, опять же, вряд ли ты далешь массированные изменения кода без промежуточной компиляции, так? J>Стало быть, в большинстве случаев приходится пересобирать только один файл.
Вот тут я честно говоря не понял как одно следует из другого. Если я делаю массивные изменения кода — то мне прийдётся, скорее всего, пересобрать даже не один раз — далеко не все ошибки вылезут при первой же компиляции. Как ни крути но не вижу я реальных возможностей что-то активно менять в большом проекте без массивных перекомпиляций. Мелкие фиксы, локализованные в одном модуле — да, можно. Вот только далеко не все фиксы мелкие.
Здравствуйте, jazzer, Вы писали:
J>тогда не очень понятно, если все так хорошо разбито, почему сборка идет долго. J>По идее, в основном ребилд должен происходить в одном только проекте в 95% случаев.
Обычно это так. Но иногда меняются базовые библиотеки на которые все завязано.
"For every complex problem, there is a solution that is simple, neat,
and wrong."
AJD>Обычно это так. Но иногда меняются базовые библиотеки на которые все завязано.
Но согласитесь, изменение базовых библиотек — отнюдь не рядовая операция? Можно и подождать некоторое время.
Кроме того, существуют precompiled headers, интеллектуальные и распределённые системы сборки.
Здравствуйте, assad, Вы писали:
A>Анатоликс, не хочу вас расстраивать, но в конструкторе копирования квалификатор const вовсе не обязателен. A>см 12.8. A>п.2 A>стандарта си ++
Остается страх только перед тем что компилятор может не прорюхать и сгенерировать конструктор копирования с const. Поэтому лучше не рисковать и поместить KK с const в private секцию
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
1) за то что вступаешь с кандидатом в полемику, что говорит о том, что человеку явно нечем заняться на рабочем месте;
2) раскрываешь копоративные секреты, ибо насколько я понимаю здарвый смысл темы собеседования являются корпоративной тайной.
Здравствуйте, assad, Вы писали:
A>Анатоликс, не хочу вас расстраивать, но в конструкторе копирования квалификатор const вовсе не обязателен. A>см 12.8. A>п.2 A>стандарта си ++
А я где-то утверждал обратное?
Любая проблема дизайна может быть решена введением дополнительного абстрактного слоя, за исключением проблемы слишком большого количества дополнительных абстрактных слоев
Здравствуйте, 0x8000FFFF, Вы писали:
FFF>А я бы тебя выгнал, за
FFF>1) за то что вступаешь с кандидатом в полемику, что говорит о том, что человеку явно нечем заняться на рабочем месте;
Это можно сказать про каждого, более менее активного, RSDN-овца
Выгоните меня! А то уже задолбало по этой <... краткое описание пустыни ...> шататься.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
. Мы только-только "протащили" в массы ООП, а его принципы (имхо!) проще чем принципы функционального программирования.
