Я бы не рекомендовал использовать placement new без крайней необходимости (реализация GC, пулов памяти и прочих "хакерских штучек"): затуманивает смысл кода и представляет собой отличный экземпляр грабель с концом ручки как раз на уровне паха, т.к. деструктор придётся вызывать вручную, а это легко забыть сделать. К тому же, нужно самому следить, чтобы размер памяти был достаточен для размещения объекта, а не то конструктор инициализирует соседний кусок памяти.
А ситуация, в которой VeryImportantFile, veryimportantfile и VERYIMPORTANTFILE — одно и то же, чем-то лучше? Особенно, если имя файла фигурирует где-то в проекте (например, в конфиге).
Вы преувеличиваете мои возможности (см. профиль), к тому же, я не испытываю боли ниже поясницы из-за комментариев в интернете, на которые я даже не отвечал. Каждый имеет право высказаться.
Не в курсе, как в Delphi и C#, а в Java такие методы разработчики обычно аннотируют:
@SuppressWarnings("unused")
public void doSomething()
...
Это решение не идеально, т.к. такие методы никогда не будут "мертвы". Впрочем, при очередной чистке кода можно поискать в проекте методы с этой аннотацией и проверить, используются ли они на самом деле. Но лучше всего, конечно, избегать использования reflection, по возможности, дабы использовать преимущества статической типизации на полную катушку.
Уж не знаю, дело во мне, или все эти методологии разработки — на самом деле жалкие попытки впихнуть разработку в прокрустово ложе бюрократии, но я пока что признаю только эту методологию, самую простую и понятную.
Вот уж точно. На одной прошлой работе я помогал портировать на iOS игру на C++, в ней вся логика и отрисовка были заключены в одном методе на ~3500 строк. Самой большой проблемой было понять, что, чёрт возьми, в нём вообще происходит. О рефакторинге и удалении мёртвого кода я даже не заикался, т.к. там всё было построено на анти-функциональной парадигме: туча глобальных переменных, всё усыпано состояниями, как булка — маком, классы как имена для пачек процедур. В таком проекте нет понятия "мётрвый код", т.к. всё сыпется от малейшего чиха.
Разумеется, речь шла о мёртвом, но незакоментированном коде, иначе тесты не имеют смысла. Моё мнение насчёт закоментированного кода: его быть не должно. Системы контроля версий всегда помогут восстановить удалённый код, а закомментированный код хуже, чем удалённый, по указанным выше причинам — к тому же, он занимает драгоценное место в исходниках, мозоля глаз.
Пожалуй, для новой, «принципиально новой», ОС наличие уже написанного софта на C или C++ не так критично, т.к. подавляющая часть кода пишется с нуля. За исключением, возможно, действительно сложных подсистем вроде TCP/IP, для которых проще будет адаптировать уже существующий код (Linux, lwIP etc.)
Закоментированный код хуже тем, что компилятор не проверяет ни его синтаксическую, ни, тем более, семантическую корректность: даже если он и понадобится в будущем, никто не гарантирует, что он хотя бы скомпилируется, не говоря уж о том, чтобы работать. По возможности, любой мёртвый код, если он может когда-нибудь пригодиться, должен быть покрыт тестами, иначе это бомба замедленного действия.
Перепроверили, да всё равно не поняли, в чём ваша ошибка. В оригинале нет никаких «компьютеров Suns», там есть просто «Suns», которое имеет смысл «Sun computers». Значит, и переводить это надо как «на компьютерах Sun», или, стилистически ближе к оригиналу, «на Sun'ах». Если в тексте было бы «on Intels», вы же не переводили бы это как «на компьютерах Intels»?
Кстати, насчёт дорисовки картинки мозгом в одном из выпусков подкаста The Infinite Monkey Cage была сказано, что мнение, будто мозг строит картинку по зрительному сигналу, ошибочно. Учёный утверждал, что мозг сначала генерирует картинку, а потом корректирует её, согласно зрительному сигналу — то есть, работает «наоборот». Этим и объясняются галлюцинации при отсутствии зрительного стимула. Интересно, правда ли это.
Или просто непонятно, что вы хотели этим сказать. Неплохо бы к картинке, тем более опубликованной в виде ссылки, писать ещё и комментарий, поясняющий вашу мысль. Мы ж не телепаты.
Если кратко, то Rx — это Iterable, вывернутый наизнанку: вместо того, чтобы самому просить данные в цикле и что-то с ними делать, вы предоставляете «обработчики», которые Rx вызывает, когда приходят данные. Только вместо лапши из callback и состояний получаются потоки данных, в которых ваши «обработчики» на каждом шаге преобразуют данные, а Rx их протаскивает далее по цепочке. Этакая смесь асинхронности с функциональщиной.
Посмотрите выступление Эрика Мейера — может, станет понятнее:
https://www.youtube.com/watch?v=sTSQlYX5DU0
Это проблема не «нашего времени», а текстового общения как такового. В разговоре вживую, а также по видео/аудио эмоции человека видны в мимике и слышны в голосе, а в тексте — нет.
Я так с него и ушёл — после очередного обновления всё сломалось (переносили /lib -> /usr/lib, что-то в этом духе), а уже потом я с Ubuntu LiveCD зашёл на сайт ArchLinux и узнал, что это обновление *может* вызвать проблемы. После решил, что буду лучше сидеть на Ubuntu: работает так же криво, но сразу — не нужно неделями настраивать руками, а обновления ничего не ломают :)
Кстати, хохма: в Warface до сих пор фильтр в чате заменяет звёздочками ругательства и слово «чит» — даже в словах «подстрахуй», «учитель», «молчит» и т.д. Интересно, как это реализует РКН.
А при виде звёздочек на месте слова «fucked», мне на ум приходит часть выступления Loius C.K.:
When you say «n-word», you're putting the word «nigger» in my head. That's what saying a word is. You make me say it in my head. Why don't *you* say the word and take responsibilty?
Что-то мне подсказывает, что ещё лучшее усвоение материала покажет то, кто, вместо конспектирования, будет внимательно слушать и задавать вопросы в непонятных местах, а потом просто почитает учебник для детального ознакомления с темой. Лекция должна фокусироваться не на детальном изложении материала, а на доступном объяснении его смысла, с широким использованием аналогий. К примеру, если это лекция по программированию и в ней изучаются функции, то нужно делать акцент на том, для чего функции нужны — для контроля сложности, разбиения задачи на подзадачи, нужно показывать примеры лапши на 100 строк и аналогичного кода, разбитого на функции, объясняя лишь в общих чертах, что делает код.
Я считаю, что конспектирование — это бессмысленное занятие, только отвлекающее студента от усвоения материала, и является пережитком системы, в которой всё ориентировано на зубрёжку. Нередка ситуация, когда из 10-минутного видео на Youtube узнаёшь больше, чем из полуторачасовой лекции. Лекция должна быть интересной и передавать суть: что мы изучаем, зачем и как это применимо на практике. Тогда будет и понимание материала, и мотивация решать примеры, проводить эксперименты и т.д.
Я бы не рекомендовал использовать placement new без крайней необходимости (реализация GC, пулов памяти и прочих "хакерских штучек"): затуманивает смысл кода и представляет собой отличный экземпляр грабель с концом ручки как раз на уровне паха, т.к. деструктор придётся вызывать вручную, а это легко забыть сделать. К тому же, нужно самому следить, чтобы размер памяти был достаточен для размещения объекта, а не то конструктор инициализирует соседний кусок памяти.
А ситуация, в которой VeryImportantFile, veryimportantfile и VERYIMPORTANTFILE — одно и то же, чем-то лучше? Особенно, если имя файла фигурирует где-то в проекте (например, в конфиге).
Не в курсе, как в Delphi и C#, а в Java такие методы разработчики обычно аннотируют:
Это решение не идеально, т.к. такие методы никогда не будут "мертвы". Впрочем, при очередной чистке кода можно поискать в проекте методы с этой аннотацией и проверить, используются ли они на самом деле. Но лучше всего, конечно, избегать использования reflection, по возможности, дабы использовать преимущества статической типизации на полную катушку.
Вот уж точно. На одной прошлой работе я помогал портировать на iOS игру на C++, в ней вся логика и отрисовка были заключены в одном методе на ~3500 строк. Самой большой проблемой было понять, что, чёрт возьми, в нём вообще происходит. О рефакторинге и удалении мёртвого кода я даже не заикался, т.к. там всё было построено на анти-функциональной парадигме: туча глобальных переменных, всё усыпано состояниями, как булка — маком, классы как имена для пачек процедур. В таком проекте нет понятия "мётрвый код", т.к. всё сыпется от малейшего чиха.
Разумеется, речь шла о мёртвом, но незакоментированном коде, иначе тесты не имеют смысла. Моё мнение насчёт закоментированного кода: его быть не должно. Системы контроля версий всегда помогут восстановить удалённый код, а закомментированный код хуже, чем удалённый, по указанным выше причинам — к тому же, он занимает драгоценное место в исходниках, мозоля глаз.
Закоментированный код хуже тем, что компилятор не проверяет ни его синтаксическую, ни, тем более, семантическую корректность: даже если он и понадобится в будущем, никто не гарантирует, что он хотя бы скомпилируется, не говоря уж о том, чтобы работать. По возможности, любой мёртвый код, если он может когда-нибудь пригодиться, должен быть покрыт тестами, иначе это бомба замедленного действия.
Посмотрите выступление Эрика Мейера — может, станет понятнее:
https://www.youtube.com/watch?v=sTSQlYX5DU0
Я считаю, что конспектирование — это бессмысленное занятие, только отвлекающее студента от усвоения материала, и является пережитком системы, в которой всё ориентировано на зубрёжку. Нередка ситуация, когда из 10-минутного видео на Youtube узнаёшь больше, чем из полуторачасовой лекции. Лекция должна быть интересной и передавать суть: что мы изучаем, зачем и как это применимо на практике. Тогда будет и понимание материала, и мотивация решать примеры, проводить эксперименты и т.д.