Сообщение Re: Линковка - как понять C#-овскими мозгами (на примере)? от 05.01.2023 12:01
Изменено 05.01.2023 12:16 rg45
Re: Линковка - как понять C#-овскими мозгами (на примере)?
Здравствуйте, Shmj, Вы писали:
S>Вот пример, чтобы не быть голословным: https://github.com/linuxdeepin/dde-file-manager/blob/master/src/dde-file-manager/singleapplication.h
S>
S>Здесь есть include а есть просто декларация class QLocalServer. А ведь можно сделать и #include <QLocalServer> и тоже будет работать.
S>В чем разница и как лучше — включать или просто объявлять?
Можно не значит нужно. Общий принцип такой, что не следует подключать заголовок с полным определением класса там, где можно обойтись предварительным объявлением. Минимизация включения заголовочных файлов нужна не только для уменьшения времени компиляции, но и для уменьшения связности кода и предотвращения зацикленности включений. Подробнее можно почитать здесь: http://programming-lang.com/ru/comp_programming/satter/0/j39.html.
S>Для классов не применимо extern а для функций, к примеру, применимо. Эта запись class QLocalServer; — эквивалент extern-а для функций?
Тут нужно бы начать с того, что немного разобраться с понятиями: есть объявления (declarations), а есть определения (definitions). Очень часто объявление одновременно является и определением. extern же — это разновидность спецификации связывания (linkage). Эта спецификация применима к любым именам, просто фунцкции и классы, объявленные в пространствах имен, по умолчанию имеют внешнее связывание (external linkage), поэтому от явной спецификации мало пользы и ее обычно опускают.
S>Вот пример, чтобы не быть голословным: https://github.com/linuxdeepin/dde-file-manager/blob/master/src/dde-file-manager/singleapplication.h
S>
S>#include <QtGlobal>
S>#include <DApplication>
S>#include <durl.h>
S>QT_BEGIN_NAMESPACE
S>class QLocalServer;
S>class QLocalSocket;
S>QT_END_NAMESPACE
S>
S>Здесь есть include а есть просто декларация class QLocalServer. А ведь можно сделать и #include <QLocalServer> и тоже будет работать.
S>В чем разница и как лучше — включать или просто объявлять?
Можно не значит нужно. Общий принцип такой, что не следует подключать заголовок с полным определением класса там, где можно обойтись предварительным объявлением. Минимизация включения заголовочных файлов нужна не только для уменьшения времени компиляции, но и для уменьшения связности кода и предотвращения зацикленности включений. Подробнее можно почитать здесь: http://programming-lang.com/ru/comp_programming/satter/0/j39.html.
S>Для классов не применимо extern а для функций, к примеру, применимо. Эта запись class QLocalServer; — эквивалент extern-а для функций?
Тут нужно бы начать с того, что немного разобраться с понятиями: есть объявления (declarations), а есть определения (definitions). Очень часто объявление одновременно является и определением. extern же — это разновидность спецификации связывания (linkage). Эта спецификация применима к любым именам, просто фунцкции и классы, объявленные в пространствах имен, по умолчанию имеют внешнее связывание (external linkage), поэтому от явной спецификации мало пользы и ее обычно опускают.
Re: Линковка - как понять C#-овскими мозгами (на примере)?
Здравствуйте, Shmj, Вы писали:
S>Вот пример, чтобы не быть голословным: https://github.com/linuxdeepin/dde-file-manager/blob/master/src/dde-file-manager/singleapplication.h
S>
S>Здесь есть include а есть просто декларация class QLocalServer. А ведь можно сделать и #include <QLocalServer> и тоже будет работать.
S>В чем разница и как лучше — включать или просто объявлять?
Можно не значит нужно. Общий принцип такой, что не следует подключать заголовок с полным определением класса там, где можно обойтись предварительным объявлением. Минимизация включения заголовочных файлов нужна не только для уменьшения времени компиляции, но и для уменьшения связности кода и предотвращения зацикленности включений. Подробнее можно почитать здесь: http://programming-lang.com/ru/comp_programming/satter/0/j39.html.
S>Для классов не применимо extern а для функций, к примеру, применимо. Эта запись class QLocalServer; — эквивалент extern-а для функций?
Тут нужно бы начать с того, что немного разобраться с понятиями: есть объявления (declarations), а есть определения (definitions). Очень часто объявление одновременно является и определением. extern же — это разновидность спецификации связывания (linkage). Cпецификации связывания применимы к разным именам, просто фунцкции, объявленные в области видимости пространств имен, по умолчанию имеют внешнее связывание (external linkage), поэтому от явной спецификации мало пользы и ее чаще всего опускают.
S>Вот пример, чтобы не быть голословным: https://github.com/linuxdeepin/dde-file-manager/blob/master/src/dde-file-manager/singleapplication.h
S>
S>#include <QtGlobal>
S>#include <DApplication>
S>#include <durl.h>
S>QT_BEGIN_NAMESPACE
S>class QLocalServer;
S>class QLocalSocket;
S>QT_END_NAMESPACE
S>
S>Здесь есть include а есть просто декларация class QLocalServer. А ведь можно сделать и #include <QLocalServer> и тоже будет работать.
S>В чем разница и как лучше — включать или просто объявлять?
Можно не значит нужно. Общий принцип такой, что не следует подключать заголовок с полным определением класса там, где можно обойтись предварительным объявлением. Минимизация включения заголовочных файлов нужна не только для уменьшения времени компиляции, но и для уменьшения связности кода и предотвращения зацикленности включений. Подробнее можно почитать здесь: http://programming-lang.com/ru/comp_programming/satter/0/j39.html.
S>Для классов не применимо extern а для функций, к примеру, применимо. Эта запись class QLocalServer; — эквивалент extern-а для функций?
Тут нужно бы начать с того, что немного разобраться с понятиями: есть объявления (declarations), а есть определения (definitions). Очень часто объявление одновременно является и определением. extern же — это разновидность спецификации связывания (linkage). Cпецификации связывания применимы к разным именам, просто фунцкции, объявленные в области видимости пространств имен, по умолчанию имеют внешнее связывание (external linkage), поэтому от явной спецификации мало пользы и ее чаще всего опускают.