Перейти к содержанию
    

Плавный переход C -> C++ под МК

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

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

Может и так.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 hours ago, Arlleex said:

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

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

Изменено пользователем one_eight_seven

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 minutes ago, Arlleex said:

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

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

Изменено пользователем one_eight_seven

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

std::aligned_storage не оно?

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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), в нём неинициализированность обеспечивается тем, что место для буфера выделяется на куче. Но вы раньше писали, что никаких динамических выделений памяти не приемлете, поэтому, тривиальная реализация не подойдёт, и нужно смотреть реализацию в конкретном компиляторе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...