[Arlleex 131]

9 минут назад, jcxz сказал:

Чем он ближе к вашему - тем понятнее...

Может и так.

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

[jcxz 184]

14 минут назад, Arlleex сказал:

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

Так а зачем переписывать? Если работает - лучше не трогать. Ну а если не работает.... то тут уж лучше - нафиг всё переписать по-своему.  

Я вот знаю, что на прошлой работе, с которой я ушёл >5 лет назад, до сих пор мои исходники (моя часть в кода в серийных устройствах), до сих пор осталась почти без изменений. Хотя проекты эти там развиваются и модифицируются непрерывно. Как мне сказали "работает же, зачем трогать?"   

И именно что исходники используются, не просто лежат - там сейчас как раз пошёл массовый выпуск этих приборов, уже вроде даже речь идёт о нескольких миллионах проданных экземпляров.

[Arlleex 131]

21 минуту назад, jcxz сказал:

Ну а если не работает.... то тут уж лучше - нафиг всё переписать по-своему...

Если работало бы как нужно и проект был статичным (не развивался ибо не нужно) - то да, вопросов сопровождения и не стояло бы. Мне вот сейчас, например, подложили такую свинью, что я пока даже еще не знаю, сколько времени потребуется на переписывание и ре-имплементацию кода в устройства, которые уже давно стоят на объектах. Была некая "гонка героев" в конторе, потом эти "герои" знатно обос*ались, и теперь все это повисло на нас (на мне в том числе). А там были любители проприетарных закрытых стеков, "зашитых" в IDE, к слову... Причем технических сложностей я не вижу. А в последствиях - вижу (это 1) написать программу по "выпиливанию" их загрузчика, скормить ее их загрузчику, прошив теперь 2) свой собственный загрузчик (написав и его), 3) написать все то "боевое" ПО, которое должно было изначально в этом блоке жить: и все это должно быть отлажено, + разное технологическое ПО на ПК).

[Arlleex 131]

В C++ миллион способов инициализации объектов... А есть ли способ сказать компилятору не осуществлять дефолтную инициализацию члена класса нулем? Т.е. в классе, помимо других членов, есть массив, довольно большой. Я не хочу, чтобы стандартная библиотека инициализировала этот массив нулем, когда инстанцируется глобальный объект такого класса.

[Edit2007 3]

Если объект создается динамически (через new) то члены класса будут проинициализированы только конструктором.

Если объект создается статически, тогда опции pragma (или секция no_init для ARM). Все будет зависеть от компилятора (и линкера).

Как вариант массив внутри класса создавать динамически - тогда он тоже не будет инициализирован.

[jcxz 184]

4 минуты назад, Edit2007 сказал:

Как вариант массив внутри класса создавать динамически - тогда он тоже не будет инициализирован.

Вот только сама куча, из которой раздаётся дин.память, скорей всего уже инитится нулями при старте ПО. 

А цель Arlleex как я понял - сократить время старта ПО, убрав ненужное заполнение.

[Arlleex 131]

Под микроконтроллеры пишу, какая динамическая память? Это мракобесие
 

7 минут назад, Edit2007 сказал:

Если объект создается статически, тогда опции pragma (или секция no_init для ARM)...

В том и фишка, что не получится так, скорее всего. Здесь нужно что-то другое. Что - пока не соображу.

А не получится по причине того, что объект класса нельзя разместить в разных секциях (одни члены там, другие сям).
 

3 минуты назад, jcxz сказал:

А цель Arlleex как я понял - сократить время старта ПО, убрав ненужное заполнение.

Именно. У меня десяток кольцевых буферов, каждый объемом от 1 кБ. Им при старте ПО обнулять сами буферы не нужно.

[Edit2007 3]

сделать указатель на объект.

7 минут назад, jcxz сказал:

Вот только сама куча, из которой раздаётся дин.память, скорей всего уже инитится нулями при старте ПО. 

А цель Arlleex как я понял - сократить время старта ПО, убрав ненужное заполнение.

Ну тогда получается что вся область ОЗУ должна инициализироваться нулем.

Область глобальных переменных - инициализируется в обязательном порядке по стандарту. Область стека и куча - по усмотрению разработчиков (что в библиотеках начальной инициализации указано).

[one_eight_seven 3]

6 hours ago, Arlleex said:

Именно. У меня десяток кольцевых буферов, каждый объемом от 1 кБ. Им при старте ПО обнулять сами буферы не нужно

А если зафиксировать буфер в памяти, а в классе оставить только указатель на этот буфер. Минусы - ручная работа, по распределению буферов в памяти. но раз уж пошла гонка за байтами, это не так уж и плохо.
либо сделайте отдельный класс - пул буферов. И классы запрашивают у пула ресурсы при старте, пул раздаст указатели. Размер пула буферов в этом плане можно передавать при сборке проекта как параметр линкера. Пул буферов может ориентироваться на символ линкера.

Изменено 14 января, 2022 пользователем one_eight_seven

[Arlleex 131]

2 часа назад, one_eight_seven сказал:

А если зафиксировать буфер в памяти, а в классе оставить только указатель на этот буфер...

Это можно, разумеется... Просто не красиво. Думал, может чисто языковые средства есть.

[one_eight_seven 3]

4 minutes ago, Arlleex said:

Это можно, разумеется... Просто не красиво. Думал, может чисто языковые средства есть.

Ну, красиво/некрасиво, это из области программирования, анализа задач и выделения отдельных классов, а не из области языка как такового. Можно и это сделать красиво. Другое дело, если у вас уже всё заточено на то, что буфер - это часть какого-то класса, и теперь вычленение буферов уже уродует архитектуру.

Изменено 14 января, 2022 пользователем one_eight_seven

[Arlleex 131]

1 минуту назад, one_eight_seven сказал:

Другое дело, если у вас уже всё заточено на то, что буфер - это часть какого-то класса, и теперь вычленение буферов уже уродует архитектуру.

Класс кольцевого буфера (FIFO). Я, естественно, сам буфер (массив) сделал приватной частью этого класса. ИМХО, очень логично, поэтому да, уродует.

[Сергей Борщ 119]

3 часа назад, Arlleex сказал:

Думал, может чисто языковые средства есть.

std::aligned_storage не оно?

Цитата

Provides the nested type type, which is a trivial standard-layout type suitable for use as uninitialized storage for any object whose size is at most Len and whose alignment requirement is a divisor of Align.

правда в возможной реализации структура с обычным массивом. Выходит - массивы по-умолчанию не инициализируются.

[Arlleex 131]

10 часов назад, Сергей Борщ сказал:

std::aligned_storage не оно?

Судя по описанию, похоже оно, но не понятно, как оно внутри реализовано.

10 часов назад, Сергей Борщ сказал:

Выходит - массивы по-умолчанию не инициализируются.

Глобальный массив, например, int buf[100]; будет обнулен перед входом в main().

P.S. Сложилось впечатление, что под "uninitialized" они имеют ввиду то, что для объектов не будут существовать как таковые конструкторы.

[one_eight_seven 3]

40 minutes ago, Arlleex said:

P.S. Сложилось впечатление, что под "uninitialized" они имеют ввиду то, что для объектов не будут существовать как таковые конструкторы.

Конструкторы будут. aligned_storage - это класс, динамический объект, создаётся с помощью new, уничтожается delete'ом.

46 minutes ago, Arlleex said:

Судя по описанию, похоже оно, но не понятно, как оно внутри реализовано.

Это не декларируется стандартом. В стандарте дан тривильный пример реализации (https://en.cppreference.com/w/cpp/types/aligned_storage), в нём неинициализированность обеспечивается тем, что место для буфера выделяется на куче. Но вы раньше писали, что никаких динамических выделений памяти не приемлете, поэтому, тривиальная реализация не подойдёт, и нужно смотреть реализацию в конкретном компиляторе.