Почему нельзя разбивать на отдельные файлы шаблонные функции и классы?

[pu4koff]

Сообщение от Loji

Скомпилируй этот код:

public ref class a{
public:
	template<class T> void my(int a){; };
};
//Попробуй так и получишь ошибку 
a^zxc= gcnew a();
zxc->my(3);

//А теперь так 
zxc->my<int>(3);

А все потому что ты пишешь только на в 1 среде С++ Builder - концептуально правильно писать, как я написал, чтобы не было путаницы, и другие компиляторы выбрасывают ошибки.

Блин. А я то всё думаю в какой среде я пишу... Ярлык называется Visual Studio, заголовок окошка Visual Studio, а это оказывается Билдер. Китайский какой-то наверно подсунули.
А если написать всё же как я написал в примере:

template<class T> void my(T a){; };

думаю, скомпилируется. Не такой уж, надеюсь, С++ CLR ущербный.

Сообщение от Loji

Напиши этот код в C++ CLR и увидишь что компилятор не ругается.

Надо будет потратить 10 минут и проверить, а то что-то не верится.

Сообщение от Loji

Читай про интерфейсы и абстрактные классы
http://ru.wikipedia.org/wiki/%D0%98%...D0%B8%D0%B5%29

Приведу цитату с википедии: "Можно заметить, что интерфейс, с точки зрения реализации — это просто чистый абстрактный класс";

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

Сообщение от Loji

Это вы описали похоже 2 программиста полных дурня? Которые сроду не писали ничего и используют первый раз интерфейсы. Обычно люди ЗНАЮТ это , и если пишется один класс- реализация, то только осел будет использовать стандартные методы (их скорее всего оставят для общих действий).

Какие стандартные методы?
И вот есть у нас интерфейсы: ICollection<Кирпич> и ICollection<Пеноблок>. Методы у обоих одноименные.
И есть у нас класс самосвал, который может одновременно перевозить и кирпичи и пеноблок:

class Truck: ICollection<Кирпич>, ICollection<Пеноблок>
{
...
}

Как в этом случае разруливать конфликты имён? Мне нужно, чтобы класс Truc из свойства Count Возвращал общее количество кирпичей и пеноблока, ну а при работе с классом через соответствующий интерфейс - только количество кирпичей/пеноблока.
Пример искусственный, потому немного глуповат, но суть проблемы отражает. Как гики программирования это будут разруливать?

Сообщение от Loji

Когда каждый пишет реализацию ,здесь как раз идентификатор partial C#, очень кстати.

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

Сообщение от Loji

Поверь мне, если человек разбирается, я признаю это.

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

Сообщение от Loji

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

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

Сообщение от Loji

Похоже вы решили как говорится "съехать с темы". ТО, что считается с точки зрения программирования и то КАК оно реализуется внутри это совсем разные вещи. Мы считаем так как нам удобно понимать, для простоты. А то, что абстрактный класс создается как обычный с директивой на запрет создания объектов ( внутри ) то до этого нет никакого дела.

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

ЗЫ. Я тоже жду с нетерпением Вашего ответа. Что же будет дальше? Даже на работе сосредоточиться не могу. Давненько меня никто так не радовал

[Loji]

Сообщение от ozo

class any{
public slots   :
   olo();
public signals :
   oli();
private        :
   int i;
}

Только сейчас, в C++ есть слоты и сигналы.
И да, ваше слово abstract, что может быть :
#define abstract что-угодно
мне ни о чем не говорит, как и моему компилятору.
На какой спецификации языка вы пишите - ваши половые трудности

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

Сообщение от ozo

Что ж вы за меня всё решаете ? )
А вы, а вы - не знаете сколько будет 5^3 Я для вас немного приоткрою завесу мрака : 5^3 == 5*5*5, а сколько это, вы наверное догадаетесь )
А я писал по теме
Другим это не сильно мешает

Правильней было бы не так 5^3 == 5*5*5, а вот так 5^3 = 5*5*5.

[Stilet]

Даже на работе сосредоточиться не могу.

Читаем внимательно первые два слова в посте №4.