DevMan, У меня компиляция 16 ядер сжирает и не давится. Это геймерам больше 6 ядер незачем (на сегодняшний день), а для работы хоть 32 ядра загрузить не проблема.
Тимур Якубов, Может исправления уязвимостей что-то сильно поломали в старом коде... Тут всё покрыто мраком. Надеюсь, проблема была в этом и больше не появится, потому что сообщать об ошибках в MS не особо эффективно. Они уже более 6 лет не могут починить редактор ресурсов, который без причины перестаёт работать... Вся надежда только на себя и сообщество :)
SillWeb, Если вам не дали прав для каких-то ействий под вашей учёткой, то вам запрещено делать эти действия. Или просите у админа повышения ваших привилегий, либо просите "другого пользователя" войти под своей учёткой и внести необходмые вам изменения. Если каким-либо образом получите пароль другого человека и от его имени что-то будете делать, это как бы уголовно наказуемое преступление и не надо так делать.
TheCalligrapher, Никогда не пытался написать такую дичь, поэтому не считаю нужным продолжать разговор. Если я не прав и в Си была статическая типизация, то признаю свою неправоту.
TheCalligrapher, Что можно в функцию вместо double передать указатель на структуру и компилятор даже не пикнет. По крайней мере в старых версиях, может уже стандарт обновили, давно Си не пользуюсь.
Евгений Шатунов, Поэтому я и написал typedef BOOL/TRUE/FALSE и описал возможные ситуации происходящего в зависимости от реализации typedef. Теоретически, кто-то мог наговнокодить преобразование BOOL в указатель и обратно и именно этот говнокод ТС и видел когда-то. Учитывая, что С вообще типы не проверяет, там хоть что написать можно было :)
Денис Загаевский,
Вот так будет наиболее понятно, что происходит в С++: 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, На подержание работы карты памяти тоже энергии сколько-то тратится. Может чуточку, но тратится :)
Как я понимаю, возможность воткнуть в розетку нет? А что насчёт пауэрбанка?
