Когда нельзя кидать исключение и почему? (нельзя из деструктора, так невозможно будет написание кода, удовлетворяющего базовой гарантии… эээ как это по-русски… юезопасности исключений? basic exception-safety guarantee — что-то типа того)
ну и собственно какие гарантии безовасности исключений известны, какие гарантируются контейнерами STL и т.п.
на виндах и юниксе интересно спросить про разницу в реализации catch(...)
Какие бывают виды оператора new()? (интересен главным образом placement new)
На виртуалках не только потраченное время (wall-clock time) сложно мерять, но и затраченное процессорное время тоже — соседние виртуальные машины вносят очень сильные помехи (в случае совместно используемого процессора, не выделенного).
У меня Eclipse+Jetty делают это моментально — за 1-2 сек.
Но, конечно, возникают проблемы поддержки паралельно основного билда из командной строки (на Gradle), и встроенного билда Eclipse.
Я не о том. Система контроля версий с этим не связана — без нее вообще нельзя.
У нас просто продукт собирается на 10+ разных вариантах юниксов, не считая виндов. Поэтому работать можно исключительно с исходниками, лежащими на сетевом диске. Иначе разработчики будут заниматься исключительно копированием и синхронизацией своих изменений. А так я редактирую исходники в одном месте, и запускаю параллельную компиляцию на нескольких платформах для проверки.
Еще один момент, который тоже сильно тормозит компиляцию —
в некоторых организациях (у нас так было когда-то). исходники лежат в сети (домашние директории пользователей расположены на центральном файл сервере. Само по себе это не так чтобы сильно тормозит (локальный файл кеш справляется), а вот если и результирующие файлы пишутся в сеть, вот тут начинаются тормоза. Решается настройкой локальной директории для всех временных и результирующих файлов.
Общее время компиляции более критично для ночных сборок. В процессе разработки нечасто приходится перекомпилировать все с нуля.
Для разработки интереснее время компиляции проекта, когда изменился только один файл. И это время должно быть порядка 10 секунд (лучше меньше, но 10 секунд это вполне приемлимо).
Немного офф-топика:
В этом плане (быстрая перекомпиляция изменившихся файлов) создают проблемы инструменты сборки основанные на тяжелых интерпретируемых языках типа BuildR, Gradle, или сами тяжелые языки типа Scala — у них, как правило, есть фиксированное время загрузки, доходящее зачастую до тех самых 10 секунд). Решается, как правило, поднятием фонового процесса, который занимается компиляцией, и кеширует все эти файлы.
Нет. У меня настоен Thunderbird на Linux-e, а на Виндах можно Outlook настроить, и они в фоновом режиме все синхронизируют — так всегда есть полная локальная копия почты.
На самом деле не редки случаи, когда почтовые аккаунты блокируются или крадутся, и почта теряется. У моего знакомого взломали gmail account, так он его сначала смог восстановить и один раз залогинится, как вдруг ему почти сразу аккаунт заблокировали (уже сам Гугл) и все — вся почта потерялась. Восстановить свой аккаунт он так и не смог.
Вывод — надо почту бэкапить, благо это несложно — настроить почтового клиента и выгружать периодически свой ящик.
Например, создатель такого сета описывает его в XML как набор иконок столько-на-столько, каждой иконке назначает название и состояние (для кнопок). Для использования указываешь название иконки, а с состояниями уже библиотека разбирается. И какой-нибудь простенький просмотрщик/библиотекарь. Тут главное, чтобы стандарт был.
сегодня в одном из топиков указывали стоимость изготовления оригинальных пресс-форм — в десятки раз дороже одного принтера… зато стоимость детали будет порядка центов… дальше — математика :-)
ну и собственно какие гарантии безовасности исключений известны, какие гарантируются контейнерами STL и т.п.
на виндах и юниксе интересно спросить про разницу в реализации catch(...)
Какие бывают виды оператора new()? (интересен главным образом placement new)
У меня Eclipse+Jetty делают это моментально — за 1-2 сек.
Но, конечно, возникают проблемы поддержки паралельно основного билда из командной строки (на Gradle), и встроенного билда Eclipse.
У нас просто продукт собирается на 10+ разных вариантах юниксов, не считая виндов. Поэтому работать можно исключительно с исходниками, лежащими на сетевом диске. Иначе разработчики будут заниматься исключительно копированием и синхронизацией своих изменений. А так я редактирую исходники в одном месте, и запускаю параллельную компиляцию на нескольких платформах для проверки.
в некоторых организациях (у нас так было когда-то). исходники лежат в сети (домашние директории пользователей расположены на центральном файл сервере. Само по себе это не так чтобы сильно тормозит (локальный файл кеш справляется), а вот если и результирующие файлы пишутся в сеть, вот тут начинаются тормоза. Решается настройкой локальной директории для всех временных и результирующих файлов.
Для разработки интереснее время компиляции проекта, когда изменился только один файл. И это время должно быть порядка 10 секунд (лучше меньше, но 10 секунд это вполне приемлимо).
Немного офф-топика:
В этом плане (быстрая перекомпиляция изменившихся файлов) создают проблемы инструменты сборки основанные на тяжелых интерпретируемых языках типа BuildR, Gradle, или сами тяжелые языки типа Scala — у них, как правило, есть фиксированное время загрузки, доходящее зачастую до тех самых 10 секунд). Решается, как правило, поднятием фонового процесса, который занимается компиляцией, и кеширует все эти файлы.
К сожалению, маркетинг часто конфликтует с удобством использования.
В душе я склоняюсь к тому, что удобство использования должно превалировать, а маркетинг вторичен. На практике-же бывает по всякому :-)
К примеру, с одноклассников приходят оповещения без текста сообщения, и жутко напрягает переходить по ссылке и логинится.
Вывод — надо почту бэкапить, благо это несложно — настроить почтового клиента и выгружать периодически свой ящик.