Денис Загаевский,
Вот так будет наиболее понятно, что происходит в С++: bool value1 = (new bool(true) != 0);
При этом, в С поведение программы зависело от того, как был определён тип BOOL. Пишу new, потому что не помню синтаксис malloc/free.
если BOOL = int, а sizeof(int) >= sizeof(void*), то: BOOL value1 = static_cast(new BOOL(TRUE));, т.е. все биты указателя сохранялись в целом числе. Потом можно было это целое число интерпретировать, как указатель и освободить память.
если BOOL = char, а sizeof(char) < sizeof(void*), то: BOOL value1 = static_cast(new BOOL(TRUE));, т.е. из указателя сохранился бы только младший байт, а старшие байты потерялись бы и освободить память уже не получилось бы.
Т.е. даже в С поведение программы зависело бы от очень многих факторов.
Если кратенько, то, при использовании выделения памяти, результат нужно записываь в указатель или в объект, инкапсулирующий указатель.
armadillo-cld, prama pack задаёт максимально допустимое выравнивание, т.е. смещение адресов данных-членов будет кратно заданному значению. С pack 1 всё будет нормально во всех случаях, но это может очень серьёзно отразиться на производительности. Для всяких SSE делается выравнивание по 16 байтам вообще, чтобы эффективн к ним обращаться.
В общем случае, данные-члены желательно располагать в порядке уменьшения размера типа данных. Т.е. сперва все double, потом int, short, char. В этом случае структура будет наиболее компактной и эффективно работающей, даже без pragma pack.
Напрмиер, есть две структуры (1){double, char} и (2){char,double}. В сависимости от настроек компиляции и ptagma pack, из размер может быть (1)=9 байт, (2)=16 байт. Или обе по 9 байт. или обе по 16 байт. Или что-то между 9 и 16 байт. При большо желании даже 32 байта может быть...
А вот чтобы об этом всём не думать, не нужно сохранять структуру как дамп памяти, а нужно сохранять каждое поле по очереди. Да, это больше писанины, зато подводных камней намного меньше и можно сделать поддержку разных версий этой структуры.
Если буфер будет вынесен за пределы цикла, в целях оптимизации, то проблема вернётся. Так что возьми за правило нуль-терминант добавлять самостоятельно, для этого dwByteRead и возвращается :)
chupasaurus, Я о чём и гвоорю, что безразлично, какая там максимальная линейная скорость, на практике это бывает важно почти никогда и почти никому. Вопрос задан про компиляцию, а там чтение сотен/тысяч мелких фйлов и запись сотен объектных файлов, тоже довольно мелких. И это при условии, что вообще запись будет выполняться, а не ограничится кэшированием Виндоус. Я же говорю, практически нет разницы во времени компиляции с убитого SSD с линейной скоростью чтения-записи чуть выше 30МБ/с по сравнению с новеньким SSD.
Про "здоровье" диска не знаю тогда, где лучше его смотреть, раз CrystalInfo не то показывает. Бенчмарк CrystalMark показывает почти паспортные данные (на 5-7МБ меньше, т.е. в пределах погрешности), несмотря на 16.5ТБ записи. PLEXTOR PX-128M5Pro, MLC память. "убитый" диск OCZ Vertex 3, тоже MLC.
alekseyHunter, А теперь перечитайте ещё раз то, что я писал. непрерывная линейная запись не нужна вообще почти никому, пусть там хоть 100 терабайт в секунду будет. Про нагрузку на компоненты я тоже написал (в скобках). Про надёжность и прочее - устаревший миф. У меня о сих пор работает SSD vertex3 на 60 гигабайт. Линейная скорость просела до 80МБ/сек, а случайная Лишь немногим ниже, чем была изначально. И это при том, что этот диск почти три года работал в ПК древнем ПК с винХП без подержки TRIM и, вообще, без какой либо поддержки SSD. ПК на первом Семпроне был, вобще чудо, что SSD работал корректно. На системном 120ГБ диске уже 16.5Терабайт записи и 12ТБ чтения и ни просадок скорости нет, ни других побочек. Думаю, последний CrystalDiskInfo врёт по поводу 100% здоровья диска, но никаких заметных проблем нет за 3526 часов наработки. На втором 500ГБ диске с 18925 часами наработки уже 99% здоровье, так что скоро диск помрёт. Лет через 10 такой работы...
20strannik08, На подержание работы карты памяти тоже энергии сколько-то тратится. Может чуточку, но тратится :)
Как я понимаю, возможность воткнуть в розетку нет? А что насчёт пауэрбанка?
armadillo-cld, лучше сразу писать правильно, чтобы не привыкать к потенциально опасному коду. В зависимости от выравнивания, между полями могут быть добавлены "пустые" байты, чтобы адрес следующего поля был выровнен по определённому адресу. Многие оптимизации требуют выравнивание по 16 байт, напрмиер, чтобы максимально эффективно всякие SSE использовать. 32 битные на 4 байта выравниваются, как минимум. Т.е. в твоём случае нет гарантии, что структура занимает ровно 56 байт. Поменяешь опции оптимизации или обновишь компилятор, сменишь х86 на х64, поменяешь настройки ивсё, будет сохраняться уже не 56 байт и все сохранённые файлы поломаются. Поэтому, если сохраняешь всю структуру как raw-bytes, то обязательно указывай pragma pack.
armadillo-cld, Ничего идеального. Структура имеет неопределённый размер в байтах. В зависимости от компилятора и его настроек размер структуры в байтах может поменяться и сломается запись/чтение. Если хочется всю структуру как бинарный дамп памяти сохранять/считывать, то при определении структуры надо задать выравнивание памяти. В данном случае, выравнивание на 1 или 4 байта задать. При условии, что int - 4 байта.
Кирилл Панов, В Адреналине выбери, что игра именно на дискретной запускаться должна. В принципе, может игра неправильно определяет, если производительность устраиват, то какая разница? Или не даёт качество текстурок включить?
hawkkiller, Не нужно создавать временный файл. Нужно переименовать существующий во временный. т.е. никакой some_file не нужен, нужно лишь имя.
path1.renameto("временный");
path2.renameTo(filepath1);
path1.renameto(filepath2);
move ещё два аргумента содержит с путём исходного и путём целевого файла. Странн, что без аргументов компилируется.
hawkkiller,
сперва проверить, что оба файла существуют. Если оба существуют, то p1 переименовывается в любое временное название, p2 переименовывается в название p1, потом временное название переименовывается в p2. Т.е. нельзя сразу переименовать p1 в p2, потмоу что p2 уже существует.
hawkkiller, val p2 это ошибка форматирования или двойная кавычка в конце имени и правда присутствует?
в приведённом коде p2 переименовывается в p1, соответственно и NOPE, что файла p2 не существует.
При условии, что используются массивы short'ов, либо в свойствах компиляции принудительно выставлено выравнивание на 1-2 байта. Иначе экономии занимаемой памяти не будет.
Вот так будет наиболее понятно, что происходит в С++: bool value1 = (new bool(true) != 0);
При этом, в С поведение программы зависело от того, как был определён тип BOOL. Пишу new, потому что не помню синтаксис malloc/free.
если BOOL = int, а sizeof(int) >= sizeof(void*), то: BOOL value1 = static_cast(new BOOL(TRUE));, т.е. все биты указателя сохранялись в целом числе. Потом можно было это целое число интерпретировать, как указатель и освободить память.
если BOOL = char, а sizeof(char) < sizeof(void*), то: BOOL value1 = static_cast(new BOOL(TRUE));, т.е. из указателя сохранился бы только младший байт, а старшие байты потерялись бы и освободить память уже не получилось бы.
Т.е. даже в С поведение программы зависело бы от очень многих факторов.
Если кратенько, то, при использовании выделения памяти, результат нужно записываь в указатель или в объект, инкапсулирующий указатель.