Здравствуйте, remark, Вы писали:
R>Я достаточно сомнительно отношусь к тому, что бы большой корпоративный проект, который использует ряд технологий (сетевые/компонентные/графические и т.д.), в котором [в силу необходимости] проводилась оптимизация кода по быстродействию, в котором в силу понятных причин работали не только профессионалы мирового уровня, переводился на другой компилятор. И уж без необъяснимых ошибок тут никак не обойтись.
А зря.
Я вот таким делом как-то занимался. Даже несколько раз .
И скажу что это вполне возможно. И необъяснимых ошибок не бывает, бывает искусство их отладки.
Но вот что я могу сказать про знание стандарта. К сожалению, в C++ есть очень много чудовищных наворотов, и когда программист пользуется ими по наитию, или методом проб и ошибок, то иногда бывает очень трудно понять что же он имел в виду, если код не соответсвует стандарту
Теперь я требую от подчинённых трёх простых вещей
1) Не пользоваться в коде тонкостями стандарта, если это возможно
2) Если уж никак не обойтись без нарушения п. 1, то надо найти в стандарте описание этих тонокстей.
3) Написать в комментарии к коду на что заложился. Хотя бы ссылку на стандарт дать. По пунктам.
Такой вот компромисс
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[10]: издевательства над switch-ем на собеседовани
Dimentiy wrote: > > K>(у нас все равно главный боттлнек — общение между хостами). > > Ага, в учебном центре, да?
Обучение проводится под профиль работы в конкретной фирме,
где работаем я и еще трое преподавателей из пяти,
пятый читает то же самое в вузе, умеет работать
с совсем начинающими.
Mikhail
Posted via RSDN NNTP Server 2.0
Re[3]: издевательства над switch-ем на собеседовани
Здравствуйте, Lorenzo_LAMAS, Вы писали:
R>>На ВСЕЛЕНСКОМ СТАНДАРТЕ С++ писать программы нельзя, только если на бумажке.
L_L>Вполне можно.
Даже если синтаксически она будет в полном соответствии стандарту языка ISO, то будет иметь место очень большой набор определений тех вещей, которые в упомянутом стандарте implementation specific или просто не указаны, однако влияют на целевые характиристики программы.
Ещё один пример: вычислительная и ёмкостная сложность программы являются её важными хар-ками (которые определяют времена отклика и минимальные требования к аппаратному обеспечению). Однако так любимый многими стандарт языка С++ огранизации ISO ничего не говорит об этих характиристиках программы.
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, remark, Вы писали:
R>>Я достаточно сомнительно отношусь к тому, что бы большой корпоративный проект, который использует ряд технологий (сетевые/компонентные/графические и т.д.), в котором [в силу необходимости] проводилась оптимизация кода по быстродействию, в котором в силу понятных причин работали не только профессионалы мирового уровня, переводился на другой компилятор. И уж без необъяснимых ошибок тут никак не обойтись.
E>А зря. E>Я вот таким делом как-то занимался. Даже несколько раз . E>И скажу что это вполне возможно. И необъяснимых ошибок не бывает, бывает искусство их отладки. E>Но вот что я могу сказать про знание стандарта. К сожалению, в C++ есть очень много чудовищных наворотов, и когда программист пользуется ими по наитию, или методом проб и ошибок, то иногда бывает очень трудно понять что же он имел в виду, если код не соответсвует стандарту
E>Теперь я требую от подчинённых трёх простых вещей E>1) Не пользоваться в коде тонкостями стандарта, если это возможно E>2) Если уж никак не обойтись без нарушения п. 1, то надо найти в стандарте описание этих тонокстей. E>3) Написать в комментарии к коду на что заложился. Хотя бы ссылку на стандарт дать. По пунктам.
E>Такой вот компромисс
Я не очень точно выразил свою мыслю.
Проекты бывают:
— те в которых сразу чётко определено, что проект будет переноситься (или все это понимают)
— те в которых определено, что проект не будет переноситься (или об этом просто не думают)
Судя по тем требованиям, которые Вы выдвигаете к подчинённым, у Вас первый вариант.
Я же имел в виду второй вариант.
В частных случаях перевод проекта не требуется вообще, если пользоваться только очень чётко ограниченным подмножеством языка.
Здравствуйте, Alexey Chen, Вы писали:
AC>Да а так?
Я догадался, (кстати, а при чём здесь ёжики?) — но это же ужас!
Вот не думал, что вложенные свитчи таят такое заподло Хорошо, здесь пример надуманный. Но ведь и в реальной жизни можно об косяк убиться.
Перекуём баги на фичи!
Re[5]: издевательства над switch-ем на собеседовани
Здравствуйте, Кодт, Вы писали:
К>Вот не думал, что вложенные свитчи таят такое заподло Хорошо, здесь пример надуманный. Но ведь и в реальной жизни можно об косяк убиться.
Здравствуйте, kittown, Вы писали:
K>Вчера сам собой придумался пример кода для запугивания K>претендентов на собеседовании:
K>#include <iostream> K>int main() K>{ K> switch(0) default: std::cout << "Hello World!" << std::endl; K>};
На вопрос "как живешь?" — задумался, грязно выругался, потом напился, долго бился головой об стену и набил морду вопрошавшему. Вообщем, ушел от ответа.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Re[6]: издевательства над switch-ем на собеседовани
Здравствуйте, Centaur, Вы писали:
C>Здравствуйте, Кодт, Вы писали:
К>>Вот не думал, что вложенные свитчи таят такое заподло Хорошо, здесь пример надуманный. Но ведь и в реальной жизни можно об косяк убиться.
C>Switch Statement Considered Goto?
В ООП я думаю да Но так как С++ не только ООП язык, то нет
Здравствуйте, remark, Вы писали:
R>Проекты бывают: R>- те в которых сразу чётко определено, что проект будет переноситься (или все это понимают) R>- те в которых определено, что проект не будет переноситься (или об этом просто не думают)
ИМХО, вот разработчики проектов второго типа, обычно и страдают от отсутсвия мыслей о переносимости, ибо довольно часто возникает у заказчика в ходе работы желание сделать все перенгосимым, и влетает заказчик в большие бапки, а разработчики в тупор, и недоволен заказчик, и ругаются разработчики.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Проекты бывают: R>>- те в которых сразу чётко определено, что проект будет переноситься (или все это понимают) R>>- те в которых определено, что проект не будет переноситься (или об этом просто не думают)
S>ИМХО, вот разработчики проектов второго типа, обычно и страдают от отсутсвия мыслей о переносимости, ибо довольно часто возникает у заказчика в ходе работы желание сделать все перенгосимым, и влетает заказчик в большие бапки, а разработчики в тупор, и недоволен заказчик, и ругаются разработчики. S>
Если большие бабки, то почему разработчики ругаются
Здравствуйте, remark, Вы писали:
R>Если большие бабки, то почему разработчики ругаются
Потому как бапки:
1) идут не разработчикам;
2) если бы думать за раннее, то можно срубить теже бапки, но с меньшими затратами;
Как Вариант, если думать за раннее, то в такорм случае можно заьребовать бапки меньше тезх, которые были бы в случае проекта 2го типа, но большие чем если бы изначально заказчик хотел переносимый проект, и тогда вероятней всего и заказчик будет рад (может быть немного расстроен, но уж точно не в ярости ), и разработчики меньше будут ругаться, и отдельный эстимэйт принесет денегна фирму.
Здравствуйте, srggal, Вы писали:
S>Здравствуйте, remark, Вы писали:
R>>Если большие бабки, то почему разработчики ругаются
S>Потому как бапки: S> 1) идут не разработчикам; S> 2) если бы думать за раннее, то можно срубить теже бапки, но с меньшими затратами;
S>Как Вариант, если думать за раннее, то в такорм случае можно заьребовать бапки меньше тезх, которые были бы в случае проекта 2го типа, но большие чем если бы изначально заказчик хотел переносимый проект, и тогда вероятней всего и заказчик будет рад (может быть немного расстроен, но уж точно не в ярости ), и разработчики меньше будут ругаться, и отдельный эстимэйт принесет денегна фирму.
Слава богу у нас не штучный продукт и такой заказцик будет просто послан