Гугл уже несколько лет спокойно
парсит ajax сайты о чем можно убедится используя их Webmaster Tools.
Отсюда реально куча статей, в том числе и из недр самого google давно устарели.
За яндекс не знаю.
Речь о том что инициализировать объекты,
без видимых причин,
внутри тела конструктора а не в initializer list
очень! очень! плохой стиль написания кода.
И если вы до кучи внутри тела конструктора обернете объект локальным объектом-мембером,
то вы получите двойную его инициализацию со всеми вытекающими.
class A{
A() {
//ВОТ ТУТ «a» УЖЕ инициализирован дефолтным конструктором
}
А может вместо смотреть примеры придумаете для конкретно ЭТОГО примера зачем его оборачивать?
Например я уже много лет не создал ни одного указателя не обернув его СмартПоинтером того или иного вида,
и для меня вообще любой код вида a = new A() по умолчанию «плохой»,
но это не значит что «плохой» код приводит к ошибкам всегда — просто он не лежит в «моей» идеологии того как должен выглядеть код.
Аналогично Страуструп приводит примеры как правильно писать код в «общем» не рассматривая частные случаи.
Собственно конкретно в этом примере даже если new бросит исключение ничего страшного нет,
никакой беды не возникнет от того что деструктор ~LockNet не сработает.
Объекта Network и не существовало и нечего деструктить.
Но то что такой стиль написания кода ведет к страшным ошибкам и гемороям это несомненно.
Например если в конструкторе LockNet перед new Network будет получение какого либо хендла который надо закрыть в деструкторе —
то оппа можно получить системный лок ресурса.
Ну а геморои это например желание избавиться от new — получим двойную инициализацию и тп.
А саму базу опубликовать не собираетесь?
Раз уж ваши данные основаны на OSM, то как я понимаю,
в соответствии с лицензией ODbL www.openstreetmap.org/copyright
пункт 4.6 Access to Derivative Databases вы обязаны выложить ее в открытый доступ.
Как то заместо настоящей ёлочки на новый год — я закодил красивейшую анимированную елочку, и выставил ее на монитор.
Не помогло — с большим скандалом всё равно был отправлен за настоящей :-)
и переменные будут и заодно tty нормально работать — можно tmux запустить
только имя пользователя ice смените на root или что там у вас в контейнерах прописано
— nsenter с появления docker 1.3 бесполезная утилита — есть родной docker exec
— fig плохо масштабируем и интересен исключительно командой fig up (звучит по русски красиво)
— сама статья может быть написана в одну строчку — скачайте файлы моего проекта и запустите что то там чтобы увидеть непонятно что
По мне выгодней и понятней писать используя стандартную библиотеку, даже в ущерб гибкости.
Да и гибкость тут несколько надуманная — возврат nil в 99% случаев ожидаемое поведение функции, если данные которые она могла бы вернуть отсутствуют.
А меня всегда восхищало как на западе — преподают курс по началам компьютерной графики например вот graphics.stanford.edu/courses/cs248-videogame-competition/
Что по итогам должен сделать студент — написать любую видеоигру в которой он сможет продемонстрировать знания которые он получил.
К сожалению там почему то почти все странички не работают, точно помню, что часть из этих написанных в виде курсовой работы игрушек стали популярны (за давностью уже не помню какие).
Теория тесно переплетена с практикой, а у нас все как вы пишете — преподаватели не заинтересованы, да и студентам по большей части все равно.
Как итог у нас большая часть предметов в вузах для галочки.
Автор разбил все пространство видов тестирования на кучу переменных, объединение значений каждой из них и есть все виды тестирования. Практически все значения переменных имеют между собой не пустые пересечения, (ручное тестирование может быть отнесено к чему угодно — хоть к ящикам, хоть к анализу кода)
Поэтому каждый реальный тест в классификации автора должен записываться как запись значений всех или почти всех переменных:
что то вроде проведем ка «комплексное» «модульное» «исследовательское» «нефункциональное конфигурационное» «полуавтоматическое» тестирование этой программы.
Какой практический смысл в этой схеме? Все эти разбиения банальны, параметры по которым можно и нужно оценивать приложение можно и без схемы вывести — просто подумав.
Вместо просто научить человека думать, его голову забивают схемами, табличками и т.п., вопрос — что останется в его голове после сдачи экзамена?
Я на сто процентов уверен что если просто дать реальную задачу студенту, а именно написать программу, попросить покрыть ее тестами, обсудить по итогам какие тесты вообще имели смысл для конкретно его задачи, достаточно ли, или перебор с выдаваемыми им результатами, это дало бы в разы больший эффект.
В любом случае добавил в PPS статьи ссылку на ваше решение как на более простое и рекомендованное. Сам подправлю образ boot2docker тем более что он у меня всегда подправленный. Меня не устраивает размер dev/shm в докер контейнерах поэтому всегда пересобираю как сам докер так и boot2docker
парсит ajax сайты о чем можно убедится используя их Webmaster Tools.
Отсюда реально куча статей, в том числе и из недр самого google давно устарели.
За яндекс не знаю.
Речь о том что инициализировать объекты,
без видимых причин,
внутри тела конструктора а не в initializer list
очень! очень! плохой стиль написания кода.
И если вы до кучи внутри тела конструктора обернете объект локальным объектом-мембером,
то вы получите двойную его инициализацию со всеми вытекающими.
class A{
A() {
//ВОТ ТУТ «a» УЖЕ инициализирован дефолтным конструктором
}
Obj a;
}
Например я уже много лет не создал ни одного указателя не обернув его СмартПоинтером того или иного вида,
и для меня вообще любой код вида a = new A() по умолчанию «плохой»,
но это не значит что «плохой» код приводит к ошибкам всегда — просто он не лежит в «моей» идеологии того как должен выглядеть код.
Аналогично Страуструп приводит примеры как правильно писать код в «общем» не рассматривая частные случаи.
никакой беды не возникнет от того что деструктор ~LockNet не сработает.
Объекта Network и не существовало и нечего деструктить.
Но то что такой стиль написания кода ведет к страшным ошибкам и гемороям это несомненно.
Например если в конструкторе LockNet перед new Network будет получение какого либо хендла который надо закрыть в деструкторе —
то оппа можно получить системный лок ресурса.
Ну а геморои это например желание избавиться от new — получим двойную инициализацию и тп.
Раз уж ваши данные основаны на OSM, то как я понимаю,
в соответствии с лицензией ODbL www.openstreetmap.org/copyright
пункт 4.6 Access to Derivative Databases вы обязаны выложить ее в открытый доступ.
Не помогло — с большим скандалом всё равно был отправлен за настоящей :-)
Систему событий (отличную от нативных DOM событий);
Это неправда — вы получите систему отличную нативных — вот facebook.github.io/react/docs/events.html
denter() {
CONTAINER=$1
shift 1
docker exec -it "$CONTAINER" su — ice -c 'script -q /dev/null'
}
и пользуйтесь наздоровье из командной строки
denter имяконтейнера
и переменные будут и заодно tty нормально работать — можно tmux запустить
только имя пользователя ice смените на root или что там у вас в контейнерах прописано
— fig плохо масштабируем и интересен исключительно командой fig up (звучит по русски красиво)
— сама статья может быть написана в одну строчку — скачайте файлы моего проекта и запустите что то там чтобы увидеть непонятно что
Да и гибкость тут несколько надуманная — возврат nil в 99% случаев ожидаемое поведение функции, если данные которые она могла бы вернуть отсутствуют.
some-> some->> cond-> cond->>
делают тоже самое и их код тоже весьма приятен
graphics.stanford.edu/courses/cs248-videogame-competition/
Что по итогам должен сделать студент — написать любую видеоигру в которой он сможет продемонстрировать знания которые он получил.
К сожалению там почему то почти все странички не работают, точно помню, что часть из этих написанных в виде курсовой работы игрушек стали популярны (за давностью уже не помню какие).
Теория тесно переплетена с практикой, а у нас все как вы пишете — преподаватели не заинтересованы, да и студентам по большей части все равно.
Как итог у нас большая часть предметов в вузах для галочки.
Поэтому каждый реальный тест в классификации автора должен записываться как запись значений всех или почти всех переменных:
что то вроде проведем ка «комплексное» «модульное» «исследовательское» «нефункциональное конфигурационное» «полуавтоматическое» тестирование этой программы.
Вам это действительно поможет при планировании?
Вместо просто научить человека думать, его голову забивают схемами, табличками и т.п., вопрос — что останется в его голове после сдачи экзамена?
Я на сто процентов уверен что если просто дать реальную задачу студенту, а именно написать программу, попросить покрыть ее тестами, обсудить по итогам какие тесты вообще имели смысл для конкретно его задачи, достаточно ли, или перебор с выдаваемыми им результатами, это дало бы в разы больший эффект.