Ключ к счастью, или Качество включенó. Крик души программиста

Немного странно, в начале стать и описываете свой проект как апогей протухшести. Как правило к этому приходят в «неочень качественных» коммандах, какгда расхлябоность сотрудников не позволяет собстно начать: не быдлокодить, думать перед написанием кода, проверять, обсуждать с коллегами…

В конце стати, я так понял что вся ваша команда собственно как раз и начала не быдлокодить, дкмать перед написанием кода, проверять, обсуждать.

С чего бы это? Как долго они сидели на этом проекте и «ничего не делали» и как быстро они перешли на «грамотную разработку»?

Обзор Nexus 7 2-го поколения (2013)

Эм, а nexus 4 (2013 edition) будет?

Курс лекций «Стартап». Питер Тиль. Стенфорд 2012. Занятие 18

как то оно все не ново и уж тем более не срывает покровов.

IP-камеры Foscam по умолчанию транслируют в сеть, каждый 3-й владелец об этом не подозревает

Эта заметка написана не для услады фантазий любителей подглядывать

черт

Базы данных в онлайн-играх. От Аллодов Онлайн до Skyforge

Сервер БД выполняет необходимые проверки (достаточно ли в сумке места, не нужно ли «застекать» эту вещь и так далее). После этого он сохраняет обновлённое состояние сумки аватара в базу.

очевидно что предмет в сумку может попасть только через сервер игровой механики. Соответственно начальные этапы проверок типа (достаточно ли места) можно производить на сервере игровой механики если хранить закешированную информацию из Сервер БД.

Такой кеш загружать полностью нужно только единожды при старте сервера игровой механики, а далее инкрементально обновлять при получении результатов от сервера БД.

Как вам такая идея?

Каково быть слабым в математике

Интересно, а можно ли понять (осознать) математику в уже сознательном возрасте если базы ноль?
Т.е. если например в дошкольно/школьном возрасте не было заложено никаких знаний, возможно ли нагнать все это в студенчестве?
А если в студенчестве не было также заложено ни гроша, можно ли в после студенческом возрасте осознать математику?

Почему я задаю этот вопрос? Потому что математики много, очень много, и что бы хотя бы прочитать несколько книг нужно уже много времени, не говоря уже о том, что нужно не просто прочитать, а именно осознать. Кому то дается это с первого раза, кого нужно бить по голове этой самой математикой что бы она там застряла.

А еще наверно нужно умопомрачительное количество времени для практики.

C++: Когда время жизни объекта определяется временем жизни ссылки на него

осознал никчемность и неправоту своего комментария :( ссылка действительно продлевает время жизни объекта.

#include <iostream>

class Temp
{
public:
	Temp(int i):i_(i){std::cout << "Temp(" << i_ << ")\n";}
	~Temp(){std::cout << "~Temp(" << i_ << ")\n";}
private:
	int i_;
};

int main()
{
	std::cout << "Start main\n";
	Temp(1);
	const Temp& ref = Temp(2);
	std::cout << "Finish main\n";
}

Start main
Temp(1)
~Temp(1)
Temp(2)
Finish main
~Temp(2)

C++: Когда время жизни объекта определяется временем жизни ссылки на него

осознал никчемность и неправоту своего комментария :( ссылка действительно продлевает время жизни объекта.

C++: Когда время жизни объекта определяется временем жизни ссылки на него

int& r = 1; // не компилируется

test.cpp:3:11: ошибка: invalid initialization of non-const reference of type «int&» from an rvalue of type «int»

компилятор как бы намекает почему нельзя. Из чего сразу понятно почему

const int& r = 1;

можно

Когда время жизни объекта определяется временем жизни ссылки на него

Я бы перефразировал

Вау, можно создавать константный ссылки на rvalue объекты (и это работает если у них одна область видимости)

Вводит в небольшой ступор последний пример. Мне кажется что это из за того, что синтаксис { }

foo_holder holder = { foo() };

это именно синтаксис и он не связан с ограничением области видимости как в ( ) и что объект { foo() }; имеет туже области видимости что и holder.

Не зная брода, не лезь в воду. Часть N4

X::operator =(*this);
Y::operator =(*this);

не?

Будущее русского Gentoo Linux

Вам за это кто ни будь платит или это исключительное благотворительность ради экспириенса?

[C++] Всё ли мы знаем об операторах new и delete?

не каждый С++'ник может «на пальцах» объяснить где и как вызывается конструктор при использовании new, поэтому

Этими знаниями можно блеснуть на собеседовании (но мне такой вопрос ни разу не задавали и я кажется знаю почему), но какой от них практический толк?

Ну вот не знаю я (или просто забыл) что operator new != keyword new, но я примерно помню (читал не раз) как переопределяется свой operator new. А теперь я знаю (вспомнил) что operator new != keyword new… и… ничего не изменилось, я все еще не знаю накой мне это может понадобится и тем более на какие грабли при этом я встану (я ведь знания как правильно переопределять operator new гораздо важнее чем знания, что operator new != keyword new).

Какой профит?

Грабли 2: Виртуальное наследование

Удивляться нечему. Ведь виртуальное наследование для того и нужно, что бы наследник имел только одну версию общего предка.
Печаль настанет тогда когда выяснится, что JustVisible и VisualActivity сильно зависимы от данных Renderable.

Грабли 2: Виртуальное наследование

    JustVisiblePlusUpdate(bool visible, bool active)
        : JustVisible(visible)
        , VisualActivity(visible, active)
        , Renderable(visible)
        , Updatable(active)
    {
    }

Воу, сколько раз будет выполнен конструктор Renderable, 1 или 3 раза?

Курцвейл прогнозирует бессмертие через 15 лет

Ну выглядеть то он может не плохо, вопрос в том работает ли организм хорошо у него? Может он 100 метров без одышки пройти не может, зато кожа подтянута.

Потоки, блокировки и условные переменные в C++11 [Часть 2]

При ложном пробуждении g_codes так же будет пустой. А так же у вас не сможет произойти ложное пробуждение между g_codes.push(errorcode) и g_notified = true (если там вдруг сложная логика есть) так как они происходят под мютексом, а при пробуждении wait происходит захват мютекса.

Поправьте меня если я не прав.

Потоки, блокировки и условные переменные в C++11 [Часть 2]

del

Потоки, блокировки и условные переменные в C++11 [Часть 2]

Мне кажется нет смысла использовать g_notified, вместо него используйте g_codes.empty()

Потоки, блокировки и условные переменные в C++11 [Часть 1]

При выполнении этой программы произойдет deadlock (взаимоблокировка, т.е. заблокированный поток так и останется ждать). Причиной является то, что контейнер пытается получить мьютекс несколько раз до его освобождения

По моему вы выбрали не самый лучший пример для deadlock. Это проблема проектирования классов, и есть весьма определенные приемы как не встать на эти грабли.
Да и к тому же такую проблему с лета увидеть вообще сложно (собстно поэтому она и появляется), мне потребовалось пару минут что бы вчухать где же там deadlock.

Интенсивность важнее тщательности

Начинай писать по 10 хабрастатей в день, 7 из них ты допишешь до конца, 5 пройдут модерацию, 3 вылезут из песочницы, 1 взлетит.