nirvimel

Создание временного объекта допустимо (по соображениям производительности), если класс этого объекта удовлетворяет нескольким условиям.
Временный класс должен иметь только final поля (то есть никаких других полей кроме final он иметь не должен). И сам экземпляр этого класса (если не передается напрямую) должен храниться в final локальной переменной. Если это условие соблюдено (есть еще незначительные условия), то включается крутейшая оптимизация (кажется, начиная с Java 7, но точно не помню), которая на выходе дает код, практически эквивалентный тому, как если бы все поля этого класса передавались бы в функцию через параметры (никакой объект класса при этом не создается).
Дополнительное условие, требуемое для включения этой оптимизации - код во всех его методах (включая конструктор) не должен вызывать сторонних эффектов (не обращаться к внешним классам, не вызывать new, и др.). Без опыта написания чистых функций проще всего соблюсти это ограничение, если вообще не создавать никаких методов, кроме конструктора, который только инициализирует поля значениями своих параметров.
Еще одно условие - этот класс должен быть унаследован только от Object и должен запрещать наследование от себя (то есть сам должен быть final).

Кстати, в последних версиях версиях Java (7/8) вообще много разных оптимизаций для тех, кто пишет final по умолчанию везде, и убирает только когда это совершенно необходимо.

В гостевой ОС в /etc/acpi/powerbtn.sh прописать shutdown -h now
В host-ОС выполнить VBoxManage controlvm Ubuntu acpipowerbutton

Загляните, например, сюда. Узнаете игрушки?
Нет, вы не угадали, это вовсе не они, а их recreation (как это называют авторы). К известным играм от Westwood Studios, MicroProse и др. они отношения (как бы) не имеют, а представляют собой "оригинальную" разработку под GPL v2.

Делайте выводы.

В основном это будет работа с legacy кодом (которому, больше лет, чем тем, кто с ним работает сегодня).
Разрабатывать с нуля прикладное ПО на С довольно затратно по времени (а это не в интересах бизнеса). Современные ЯП позволяют вести разработку в более короткие сроки. Единственное исключение - области, в которых имеются жесткие ограничения ресурсов (тот самый embedded). В остальных областях время разработчика стоит дороже, чем несколько гигабайт памяти.

Многие так делают. Пройдитесь по профилям в топе, увидите.

Предохранитель сработает только, если в воду кинуть ОБА провода. Но достаточно мощный предохран >25А не сработает и так (электрики такие предохраны наоборот нахваливают, типа "не выбивает без причины").

Если же опустить в воду только фазу, то ... в таком случае могло бы спасти только УЗО, но в где вы их видели в обычных квартирах?

P.S.: Если вы уже прикидываете варианты, как устроить кому-то "несчастный случай", то спешу вас обломать: такие "несчастные случаи" ОЧЕНЬ легко расследуются.

Есть только один способ узнать реальный предел скорости ширины канала - это нагрузить канал до предела. На этом принципе и основаны все спидтесты. Причем для получения достоверных результатов эта нагрузка должна держаться дольше, чем время загрузки одной страницы. И кому тогда нужна такая "оптимизация" загрузки?

Зачем нужна статическая типизация, и можно ли обойтись без неё?

Для HelloWorld она совершенно не нужна.

Ведь можно же просто объявить переменную, и суй в неё что твоей душе угодно, хоть строку, хоть число и т.д.

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

И что может за собой повлечь игнорирование статической типизации

Вырванные волосы при отладке проекта на 5000 строк.

*((int *) 0) = 1;
Ни в одном другом языке это не осуществляется так просто.

В режиме телепатии догадываюсь, что вы хотите реализовать. Видимо, речь идет о совершенно стандартном механизме порождения объекта соединения из объекта БД.
Чтобы понять как строятся подобные велосипеды загляните в код любой ORM или вообще любой ООП-обертки над драйвером БД. Вы увидите в большинстве случаев следующую картину:
1. Конфигурация БД представляет собой фабрику (да, да, те самые паттерны, которые неофитам НИНУЖНЫ).
2. Метод connect возвращает объект соединение.
3. Объект соединение (кроме методов по выполнению запросов) имеет метод close, который закрывает соединение (попытка выполнения запроса на закрытом соединении будет выдавать ошибку).
4. Соединение (как объект) живет один раз и не может быть переоткрыто после закрытия. Но из фабрики БД всегда можно открыть новое соединение.

Почему так:
Главный принцип ООП: отдельному понятию - отдельный класс. БД (на стороне клиента) представляет собой только конфигурацию: адрес сервера, имя юзера, пароль, имя БД и прочие параметры. Соединение к БД - это отдельная сущность, через которую создаются транзакции и курсоры (отдельные сущности), через которые выполняются запросы. Результат выполнения запроса - отдельная сущность. Отдельная строка в выборке - отдельная сущность (если только не кортеж). И только отдельные поля в строке имеют примитивные типы данных.

Как реализовать функцию автоматического уменьшения / оптимизации фотографии если пользователь загружает фотографию больше установленного на сайте размера?

При аплоде изображение (вместе с пометкой от кого оно пришло) ставится в очередь на обработку. В фоне (с низким приоритетом) крутится скрипт, который по одному забирает изображения из очереди конвертирует их (через ImageMagick, например) и прописывает в профиль (ну или куда там у вас) того юзера, который загрузил оригинал. После того как изображение получено, но до того как оно обработано на том месте можно показывать заглушку: "подождите (несколько секунд/часов/дней), идет обработка".