С++ vs Java

[pal]

Да доступна она,
доступна.
Только через #include.
Потому их всегда и объявляют в h файлах,
хотя стандартом это не определено.

когда я говорил "доступна", речь шла о стадии линковки
при чем тут заголовки ?

Но я уверен, что мало найдется компиляторов,
которые вздумают генерировать ее как внешнюю.

вы сами с собой разговариваете ?
с чего функцию, которая не статик генерить как не статик ?
не знаю. наверное потому, что она не статик

Бред это.

согласен

А в каком месте, извините,
если она будет включена в несколько файлов?
Это же будет дупликат, линковка опять не пройдет.

внимание, вопрос. если есть функция
inline int f ( ) {
static int counter = 0;
return ++ counter;
}
то где генерить этот counter и будет ли каждый файл считать его отдельно от других?
(spoiler warning: ответ: у всех адекватных линкеров есть некоторое понятие о common sections и они совмещаются при линковке )

[pal]

в общем, чего тут спорить
смотрим стандарт
7.1.2.6
---------------
An inline function with external linkage
shall have the same address in all translation units. A static local variable in an extern inline function always
refers to the same object
-----------------
что такое external linkage и во что выливается shall have the same address in all translation units, объяснять или самми разберетесь ?

[pal]

а так же
7.1.2.2
A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline specifier indicates to the implementation that inline substitution of the function body at the point of call is to be preferred to the
usual function call mechanism. An implementation is not required to perform this inline substitution at the point of
call; however, even if this inline substitution is omitted, the other rules for inline functions defined by 7.1.2 shall still be
respected.

[lexar]

An inline function with external linkage

Ход мыслей правильный, но вывод не верный
Речь идет о функциях с внешней линковкой,
которые так и описываются, как
extern inline,
что я собственно и утверждал:
компилятор не будет гнать пургу без дополнительного указания (extern).

Скажем, что бы мой пример приведенный выше заработал,
я должен был в файле 1 написать:
extern inline void f() {cout << "aaa"<<endl;}
а в файле 2:
extern inline void f();
void z()
{
f();
}

Другими словами, вы пытаетесь доказать более общее утверждение частным примером (вы утверждали, что компилятор сам решает, что лепить в инлайн, и при этом еще и сам реализует для инлайн внешнюю
линковку). На деле же, все иначе. Для внешней линковки нужно
специальное объявление.

Кстати, вы продемонстрировали еще один
семантический недостаток языка С++:
он позволяет описать inline-функию так,
что она явно будет не inline.

[pal]

An inline function with external linkage

Ход мыслей правильный, но вывод не верный
Речь идет о функциях с внешней линковкой,
которые так и описываются, как
extern inline,
что я собственно и утверждал:
компилятор не будет гнать пургу без дополнительного указания (extern).
Скажем, что бы мой пример приведенный выше заработал,
я должен был в файле 1 написать:
extern inline void f() {cout << "aaa"<<endl;}
а в файле 2:
extern inline void f();
void z()
{
f();
}

двойка
все функции extern, если явно не указано, что они static.
чтобы пример заработал, я вам сказал использовать функцию в том файле, иначе компилятор ее генерить не будет; а указывание ей избыточного спецификатора ничего не изменит.

Другими словами, вы пытаетесь доказать более общее утверждение частным примером (вы утверждали, что компилятор сам решает, что лепить в инлайн

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

, и при этом еще и сам реализует для инлайн внешнюю
линковку)

сам он этого не делает, инлайн и линковка - независимые понятия.

На деле же, все иначе. Для внешней линковки нужно
специальное объявление.

в каком пту вас научили, что inline значит static ? хватит демонстрировать свою безграмотность, подучите предмет.

Кстати, вы продемонстрировали еще один
семантический недостаток языка С++:
он позволяет описать inline-функию так,
что она явно будет не inline.

я не понимаю, для кого я цитировал стандарт. inline это совет(hint), что желательно(но необязательно!) функцию подставлять. какое отношение этот совет имеет к семантике ?
язык с++ позволяет собирать отладочные версии быстрее и так что их потом легче отлаживать - это не только не семантический, но и не недостаток вообще

[lexar]

двойка
все функции extern, если явно не указано, что они static.
чтобы пример заработал, я вам сказал использовать функцию в том файле, иначе компилятор ее генерить не будет; а указывание ей избыточного спецификатора ничего не изменит.

Блин,
да возмите компилятор и проверьте,
чем отличается

inline
от
extern inline

Перед тем как вам отвечать я не поленился перечитать стандарт
и все проверить на примере в проекте.

Чего и вам желаю.

[pal]

смотрим, что пишут в стандарте

7.1.1
The specifiers that can be used in a declaration are
decl-specifier:
storage-class-specifier
type-specifier
function-specifier
friend
typedef

storage-class-specifier и function-specifier - разные вещи

7.1.2.1
Function-specifiers can be used only in function declarations.
function-specifier:
inline
virtual
explicit

inline это function-specifier

7.1.1.1
The storage class specifiers are
storage-class-specifier:
auto
register
static
extern
mutable

static i extern это storage-class-specifier

7.1.1.6
A name declared in a namespace scope without a storage-class-specifier has external linkage unless it has internal
linkage because of a previous declaration and provided it is not declared const. Objects declared const and not
explicitly declared extern have internal linkage.

и так, по умолчанию, in a namespace scope все что не const, ролучает external linkage

7.1.1.7
The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each
declaration declaring the same object name or the same overloading of a function name shall imply the same linkage.
Each function in a given set of overloaded functions can have a different linkage, however. [ Example:
static char * f (); / / f() has internal linkage
char * f () / / f() still has internal linkage
{ /∗ . . . ∗/ }

char * g (); / / g() has external linkage
static char * g () / / error: inconsistent linkage
{ /∗ . . . ∗/ }

void h ();
inline void h (); / / external linkage

inline void l ();
void l (); / / external linkage

inline void m ();
extern void m (); / / external linkage

static void n ();
inline void n (); / / internal linkage

как бы вы объяснили / / external linkage напротив инлайн функций h, l и m ?

вы какой-то не тот стандарт читаете

c компилятором я проверил еще на первом примере
static inline отличается от inline, а extern inline - не отличается
у вас не только стандарт странный, но и компилятор. может, это стандарт вашего компилятора ?

[lexar]

Согласен, ваши цитаты можно интерпретировать так:
inline всегда имеет extern linkage

Я тестируют на MS студии 2005

В принципе, то что по умолчанию inline вообще не имеет linkage,
очевидно - она подставляется.

Если бы было иначе - то инклюд файла с инлайн-функцией
в нескольких сpp файлах приводил бы к дупликату внешних ссылок
и ошибокам линковки.
Сам при прграммировании сталкивался с этим не раз,
когда случайно пропускал объявление inline.

Ваши возражения? Как избегаются дупликаты?

[pal]

я уже говорил, как они избегаются
так же как и дубликаты статических переменных внутри инлайн функций
стандарт не говорит о том, какой должен быть линкер, он говорит только о том, чего надо добиться, а как это сделать - забота разработчиков
в частности, если стандарт говорит, что инлайн функция во всех модулях должна иметь один и тот же адрес, то натуральное решение - привлечь на помощь линкер, т.к. именно он и назначает адреса. соответственно, функция помещается в специальную секцию, в которой при линковке все символы с одним именем из разных модулей совмещаются
естественно, если адрес функции в модуле не используется, то и не надо добиваться его идентичности с адресами из других модулей, в частности поэтому gcc не генерирует тело функции если не было его вызова, или если вызов был, но оптимизатор заметил, что функция пустая и ее можно и не вызывать
простой способ добиться 100% использования адреса:
inline void f ( ) { }
typedef void ( * vfp ) ( );
vfp g ( ) {
return f;
}
однако, это все имеет мало отношения к изначальному вопросу о том, могут ли компиляторы (не)подставлять функции по своему усмотрению ( в том числе и при использовании соответсвующих параметров компилятора, регулирующих уровень оптимизации )

[lexar]

Согласен, что такая реализация линкера возможна,
хотя я и не сталкивался.
Впрочем, все это наверняка должно управляться.
С точки зрения оптимизации по памяти не нормально
делать подстановку и одновременно генерировать тело фукции для внешней ссылки,
если в этом нет необходимости.

[pal]

С точки зрения оптимизации по памяти не нормально
делать подстановку и одновременно генерировать тело фукции для внешней ссылки

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

[homo ludens]

на bash.org нашел:
У каждого языка есть свои плюсы - но у С++ их целых 2!
;-)

[THRESHE]

на bash.org нашел:
У каждого языка есть свои плюсы - но у С++ их целых 2!
;-)

Это точно

[pavlentus]

Вы все еще стираете на Си++? Мы к Вам прийдем и покажем как надо стирать качественным стиральным языком Медвед.

[lexar]

на bash.org нашел:
У каждого языка есть свои плюсы - но у С++ их целых 2!
;-)

Исходя из такой мнемоники C# - это C в тюремной камере

[pavlentus]

Исходя из такой мнемоники C# - это C в тюремной камере

Бедняга, на хлебу и воде

[pal]

"The C Programming Language -- A language which combines the
flexibility of assembly language with the power of assembly language."

[pal]

о пользе garbage collector'ов
не то, чтобы с++ не мог их использовать, но тут, по крайней мере, есть выбор
я только что узнал причину одного из неисправимых преимуществ программ на яве - регулярных свопометов
если программа сознательно что-то кеширует в памяти или если просто хранит много данных, только маленькая часть из которых используется часто, то современные операционные системы вытесняют неиспользуемые данные в своп и там они никому не мешают
но не тут-то было: сборщик мусора будет с упорством, достойным лучшего применения, их сканировать, вытесняя реально полезную память других программ
другими словами, использование сборщиков мусора иначе, как вредительством, и не назовешь

[traveller]

о пользе garbage collector'ов
не то, чтобы с++ не мог и использовать, но тут, по крайней мере, есть выбор
я только что узнал причину одного из неисправимых преимуществ программ на яве - регулярных свопометов
если программа сознательно что-то кеширует в памяти или если просто хранит много данных, только маленькая часть из которых используется часто, то современные операционные системы вытесняют неиспользуемые данные в своп и там они никому не мешают
но не тут-то было: сборщик мусора будет с упорством, достойным лучшего применения, их сканировать, вытесняя реально полезную память других программ
другими словами, использование сборщиков мусора иначе, как вредительством, и не назовешь

а ссылка есть? надо сильно

[homo ludens]

Наиболее часто используемый сборщик мусора для С и С++ - gc
http://directory.fsf.org/boehm_garbage_collector.html
Не то, чтобы он мне хоть когда-то реально пригодился...

Давно понял, хочешь быстрый комп - отключай своп навсегда. ;-)
Что со сборщиком, что без сборщика...