В большинстве многопользовательских командных играх есть несколько ролей и если тебе нужна хорошая команда, то тебе надо собрать несколько ролей:
— вов — танк, хил несколько керри
— лол — ад керри, ап керри, соло топ, джанглер, сапорт
— дота — два человека в соло + трипла с одним керри, которого сапортят два других
— кс — кто-то с калашом бегает, а кто-то со слоном
…
В настройках зюна есть галочка похожая на «подтягивать теги самостоятельно». Сейчас под рукой нет зюна — проверить точно не могу. Возможно она у Вас установлена.
Подозреваю, что нет — если Вы переименуете все классы, методы и пакеты Java API и будете выдавать их за свои, то никто к Вам приставать не будет. Другое дело, что Google выбрал Java, в основном, потому, что существует целая армия разработчиков, привыкших работать с Java API.
Я перестал понимать, какую точку зрения Вы отстаиваете:
— pragma pack благо и его надо использовать всегда
— pragma pack вред и его нельзя использовать никогда
— pragma pack вред, но иногда его можно использовать
— pragma pack благо, но иногда лучше обойтись без него
— все любят котиков
>>Когда Вы делаете #pragma pack(push, 1), Вы выигрываете несколько байтов и проигрываете несколько тактов процессора
>Ааааарррргх. Если процессор не может работать с невыровненными данными, значит компилятор, скорее всего, раскидает это на много команд чтения-сдвига-слияния.
Я про это и написал. О чем Вы пытаетесь спорить?
>И откуда вы (и многие другие комментаторы) взяли вообще, что программист волен раскидывать данные как хочет?
Это С++, детка, здесь могут и pragma pack написать, и delete this. Язык разрабатывался в расчете на то, что программист лучше знает. По этому, он дает возможность выстрелить себе в ногу. По этому, он дает возможность писать очень эффективный код для конкретного железа.
1. С помощью pragma pack Вы проигрываете такты процессора.
2. Без pragma pack тоже можно выделить нужное количество памяти и прочитать в нее структуру из файла, если приложение компилируется с одними и теми же настройками компилятора, одним и тем же компилятором. Если приложение компилируется в несколько либ, с разными настройками выравнивания, то чтения из файла это меньшая из Ваших проблем.
Использовать pragma pack, ИМХО, есть смысл использовать только в двух случаях:
1. Вы храните очень много данных в файле и размер жесткого диска и/или оперативной памяти сильно ограничены. В таком случае, скорее всего, процессорное время тоже очень дорого, по этому тут классический трейдоф между памятью и процессорным временем.
2. У Вас несколько версий программы, которые компилируется с разными настройками выравнивания. В таком случае, ИМХО, лучше использовать сериализацию, как писал FlexFerrum.
Когда Вы делаете #pragma pack(push, 1), Вы выигрываете несколько байтов и проигрываете несколько тактов процессора (процессор default архитектуры не станет работать с int32_t, чей адрес не выравнен на границу 4-х). Имхо, нет смысла этого делать, пока Вам не надо по какой-то причине ужать размер структуры. И даже если Вам таки надо ужать структуру, то, ИМХО, лучше руками перетасовать поля структуры, чем делать pragma pack.
На GoingNative говорили, что стандартная библиотека нуждается в новом функционале от сторонних разработчиков. Я бы ОЧЕНЬ хотел видеть что-то подобное в стандартной библиотеке. Вы бы не могли отправить ее комитету? Это будет стоить Вам многих эфортов и даст Вам мало профита, но все же я надеюсь.
Мой опыт показывает, что когда проект более-менее большой (1кк+ строк кода) и монолитный (новый функционал добавляется не плагинами) время разработки крайне мало зависит от ЯП, а по этому нет смысла для таких проектов использовать динамические ЯПы.
>Когда всё просчитают, то тактика белых будет сводиться к: начинай заранее беспроигрышную (если не ошибаться) партию и победа или ничья _гарантирована_
Вариант беспроигрышный для черных.
Чтобы понять достаточно загуглить tf2 hats.
— вов — танк, хил несколько керри
— лол — ад керри, ап керри, соло топ, джанглер, сапорт
— дота — два человека в соло + трипла с одним керри, которого сапортят два других
— кс — кто-то с калашом бегает, а кто-то со слоном
…
Robert Morris
Хотя, конечно, это все мое ИМХО.
— pragma pack благо и его надо использовать всегда
— pragma pack вред и его нельзя использовать никогда
— pragma pack вред, но иногда его можно использовать
— pragma pack благо, но иногда лучше обойтись без него
— все любят котиков
>Ааааарррргх. Если процессор не может работать с невыровненными данными, значит компилятор, скорее всего, раскидает это на много команд чтения-сдвига-слияния.
Я про это и написал. О чем Вы пытаетесь спорить?
>И откуда вы (и многие другие комментаторы) взяли вообще, что программист волен раскидывать данные как хочет?
Это С++, детка, здесь могут и pragma pack написать, и delete this. Язык разрабатывался в расчете на то, что программист лучше знает. По этому, он дает возможность выстрелить себе в ногу. По этому, он дает возможность писать очень эффективный код для конкретного железа.
2. Без pragma pack тоже можно выделить нужное количество памяти и прочитать в нее структуру из файла, если приложение компилируется с одними и теми же настройками компилятора, одним и тем же компилятором. Если приложение компилируется в несколько либ, с разными настройками выравнивания, то чтения из файла это меньшая из Ваших проблем.
Использовать pragma pack, ИМХО, есть смысл использовать только в двух случаях:
1. Вы храните очень много данных в файле и размер жесткого диска и/или оперативной памяти сильно ограничены. В таком случае, скорее всего, процессорное время тоже очень дорого, по этому тут классический трейдоф между памятью и процессорным временем.
2. У Вас несколько версий программы, которые компилируется с разными настройками выравнивания. В таком случае, ИМХО, лучше использовать сериализацию, как писал FlexFerrum.
www.reddit.com/r/IAmA/comments/mmecu/iama_malware_developer_ama/
Этот под Мак/никс ничего не писал, правда.
Вариант беспроигрышный для черных.
imgs.xkcd.com/comics/convincing.png