deleted

Здравствуйте, rean, Вы писали:

R>Полный текст сообщения не является конекстом. Контекст — это время, люди, авторский случай, обсуждение, ответы на данный момент времени.

Вот поэтому я и удивился, когда в контексте моего общения с топикстартером увидел это невежество:

http://rsdn.org/forum/cpp/7070363.1

Автор: rean
Дата: 03.03.18

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

Если ты не заметил, это ты вклинился в разговор и сделал это не очень удачно, мягко говоря.

Из требования, что определение инлайн функции должно присутствовать в каждой единице трансляции, где эта функция используется, вовсе не следует вот это утверждение: "поэтому найтись инлайн из одного cpp в другом не может никак".

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

deleted

Здравствуйте, rean, Вы писали:

R>Во-первых, не надо тыкать.

Вот когда откроешь свой сайт, тогда и будешь устанавливать свои правила.

R>Во-вторых, не надо врать. Я был первым, кто написал автору, первым, кто проверил его код и запостил результаты моей проверки.

Ты молодец, возьми с полки пирожок. Только та ветка, куда ты вклинился, начинается моим сообщением: http://rsdn.org/forum/cpp/7070208.1

Автор: rg45
Дата: 02.03.18

. Так что свои стоны оставь при себе.

deleted

Здравствуйте, rean, Вы писали:

R>Вот когда откроете свой сайт, тогда и будете считать ту ветку своей.
R>Так что свои попытки отобрать право других писать на форуме оставьте себе

А я где-то отбирал у тебя права что ли? Это ж ты тут заявляешь свою монополию на контекст. Глупости не нужно говорить ни в каком контексте.

deleted

Здравствуйте, rean, Вы писали:

R>1. “Если ты не заметил, это ты вклинился в разговор и сделал это не очень удачно, мягко говоря.”
R>2. “Только та ветка, куда ты вклинился, начинается моим сообщением”.

R>Сказано так, будто мне нельзя было там писать.

Это тобой это воспринято ТАК. А сказано это было в ответ на твои наезды по поводу подмены контеста. Я просто обратил твое внимание, что контекст той ветки, не был твоим изначально.

deleted

Здравствуйте, rean, Вы писали:

R>>Я просто обратил твое внимание, что контекст той ветки, не был твоим изначально.

R>Контекст нельзя сделать своим в смысле собственности. Это абстрактное понятие.

Ну и тем более не понятно тогда, чего ты здесь так пенился: http://rsdn.org/forum/cpp/7071189.1

Автор: rean
Дата: 04.03.18

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

deleted

Здравствуйте, rean, Вы писали:

R>>Ну и тем более не понятно тогда, чего ты здесь так пенился: http://rsdn.org/forum/cpp/7071189.1

Автор: rean
Дата: 04.03.18

.

R>Из-за раздражения.

Раздражение — у младенца на попке. А то, что продемонстрировал ты — это неумение контролировать свои эмоции.

Здравствуйте, rean, Вы писали:
Я преклоняюсь перед такими талантливыми людьми: Вы равно хорошо разбираетесь как в С++, так и в психологии.

R>>Я вот еще о чем подумал. Вполне возможно, что ты еще путаешь

R>Да все просто. Я являюсь вашим оппонентом. Вам это не нравится и вы выискиваете какие-нибудь доводы доказать свою правоту. И начинаете придумывать побочные смыслы, в которых ваш оппонент по вашему плохо разбирается.
R>Это всего-лишь способ вашей самозащиты.

R>Уже четвертое сообщение подряд уводите разговоры в сторону, игнорируя то о чем я писал автору этой темы. Ковыряясь в терминах, выискивая, как бы где отыскать малейший изъян.

Здравствуйте, rg45, Вы писали:

R>Конечно же, в первом случае возникает ошибка линковки, потому, ты ключевые слова inline убрал вообще. А вот если бы ты сделал так, как я говорю, то все было бы в порядке:


Ну вы, братцы, нафлудили (я про верхнюю ветку). Уж боюсь продолжать спрашивать, чтобы не подлить масла в огонь

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

//header.h
template<>
class C<char> {
public:
    void memberFunction();
    void charSpecificMemberFunction();
};

Как и в прошлый раз, определяем эти методы в одном из модулей:

//class_implementation.cpp
#include<header.h>

template<>
void C<char>::memberFunction() {
}

template<>
void C<char>::charSpecificMemberFunction() {
}

Ну и далее начинаем добавлять спецификатор inline в объявление и/или определение.

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

Здравствуйте, ezdoctor, Вы писали:

E>Ну и далее начинаем добавлять спецификатор inline в объявление и/или определение.
E>Полная специализация -- это уже не темплейт, а обычный класс, то есть фактически можно не заморачиваться специализацией, а то же самое произвести с обычным классом. Результат -- ничего не линкуется, если только не сделать грязный хак с вызовом их из функции this_function_is_not_used_anywhere в модуле, где эти инлайны определяются.
E>А потому хочу не поднимая волну (как вышло в прошлый раз) выяснить ответ на конкретный вопрос: в чем разница объявления метода как inline для случая, когда класс обычный и когда он шаблонный?

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

//Some.h

class A { void foo(); }

inline void A::foo() { } // inline is required

template <typename T>
class X { void foo() };

template <typename T>
void X<T>::foo() { } // inline is NOT required

template <>
inline void X<int>::foo() { } // inline is required again

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

Определить общедоступную функцию в cpp файле и сделать функцию inline — это два противоположных устремления. У меня складывается впечатление, что ты пытаешься совместить несовместимое.

Здравствуйте, ezdoctor, Вы писали:

E>А потому хочу не поднимая волну (как вышло в прошлый раз) выяснить ответ на конкретный вопрос...

Не нужно бояться никаких волн, спрашивай совершенно свободно. Показывай прямо фрагменты кода, с которыми возникают затруднения. Это вовсе не те проблемы, которые не имеют решения.

Здравствуйте, ezdoctor, Вы писали:

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

E>//header.h
E>template<>
E>class C<char> {
E>public:
E>    void memberFunction();
E>    void charSpecificMemberFunction();
E>};
E>

E>Как и в прошлый раз, определяем эти методы в одном из модулей:
E>

E>//class_implementation.cpp
E>#include<header.h>

E>template<>
E>void C<char>::memberFunction() {
E>}

E>template<>
E>void C<char>::charSpecificMemberFunction() {
E>}
E>

Для определения методов полной специализации шаблона класса используется иной синтаксис:

void C<char>::memberFunction() {
}

void C<char>::charSpecificMemberFunction() {
}

Приведенный Вами синтаксис используется для определения полных специализаций методов шаблонного класса.

Здравствуйте, rg45, Вы писали:

R>Разницы никакой нет. Ну или почти нет — при определении функций-членов в заголовке, ключевое слово inline может быть опущено в определениях фунций-членов шаблонного класса, тогда как для обычных классов и/или полных специализаций оно является обязательным:

На данный момент интерес скорее академический. За тем, чтобы функции были именно inline, я не гонюсь, но, поскольку на грабли уже наступлено (см. мой начальный пост), хочется понять четко весь механизм, чтобы уметь предсказывать без научного тыка.
По поводу фразы "тогда как для обычных классов и/или полных специализаций оно является обязательным": что именно имеется в виду? Что обязательно и для чего обязательно?

Здравствуйте, ezdoctor, Вы писали:

R>>Разницы никакой нет. Ну или почти нет — при определении функций-членов в заголовке, ключевое слово inline может быть опущено в определениях фунций-членов шаблонного класса, тогда как для обычных классов и/или полных специализаций оно является обязательным:

E>На данный момент интерес скорее академический. За тем, чтобы функции были именно inline, я не гонюсь, но, поскольку на грабли уже наступлено (см. мой начальный пост), хочется понять четко весь механизм, чтобы уметь предсказывать без научного тыка.

Общий принцип такой: функция с внешним связыванием, объявленная inline, должна быть видна как inline во всех единицах трансляции, в которых она используется. Кроме того, определение этой функции также должно содержаться во всех единицах трансляции, в которых она используется и эти определения должны быть идентичными (даже после обработки препроцессором). Самый прямой способ удовлетворить эти требования, не создавая самому себе проблем — это разместить определения функций в заголовочном файле и пометить их как inline. Здесь важно понимать, что единицей трансляции называется исходный текст программы, прощедший соответсвующие фазы трансляции, включая препроцессор и не стоит путать единицу трансляции с объектным файлом, который получается на выходе компилятора. Далее следует отметить, что функции, объявленные как inline, в точке использования могут подставляться, а могут вызываться, как обычные функции. Решение о том, какой из этих сценариев будет использован в том или ином случае, принимается компилятором. В тех случаях, когда генерируется вызвов вместо встраивания, линкер подставляет вместо имени функции ее адрес, и этот адрес будет одинаковым во всех точках программы. Таким образом, несмотря на наличие дубликатов определения функции в исходном тексте программы, в конечном исполняемом файле остается только один экземпляр объектного кода для каждой функции. Отбрасывание дубликатов — одна из обязанностей ликера.

E>По поводу фразы "тогда как для обычных классов и/или полных специализаций оно является обязательным": что именно имеется в виду? Что обязательно и для чего обязательно?

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

Здравствуйте, rg45, Вы писали:

R>Общий принцип такой: функция с внешним связыванием, объявленная inline, должна быть видна как inline во всех единицах трансляции, в которых она используется. Кроме того, определение этой функции также должно содержаться во всех единицах трансляции, в которых она используется и эти определения должны быть идентичными (даже после обработки препроцессором). Самый прямой способ удовлетворить эти требования, не создавая самому себе проблем — это разместить определения функций в заголовочном файле и пометить их как inline. Здесь важно понимать, что единицей трансляции называется исходный текст программы, прощедший соответсвующие фазы трансляции, включая препроцессор и не стоит путать единицу трансляции с объектным файлом, который получается на выходе компилятора. Далее следует отметить, что функции, объявленные как inline, в точке использования могут подставляться, а могут вызываться, как обычные функции. Решение о том, какой из этих сценариев будет использован в том или ином случае, принимается компилятором. В тех случаях, когда генерируется вызвов вместо встраивания, линкер подставляет вместо имени функции ее адрес, и этот адрес будет одинаковым во всех точках программы. Таким образом, несмотря на наличие дубликатов определения функции в исходном тексте программы, в конечном исполняемом файле остается только один экземпляр объектного кода для каждой функции. Отбрасывание дубликатов — одна из обязанностей ликера.

E>>По поводу фразы "тогда как для обычных классов и/или полных специализаций оно является обязательным": что именно имеется в виду? Что обязательно и для чего обязательно?

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

Мой изначальный пример не доказывает ли обратное?