LINUX.ORG.RU

[c++] [шаблоны ] не компилируется


0

0

Здравствуйте! Такой вот код. Никак не могу понять в чем дело. Может общественность укажет?

template<class T> class CArr
{
	T* mas;
	long size; // размер массива
	long count; // количество элементов в массиве 
public:
	//CArr(void);
	CArr(long);
	CArr(const CArr<T>&T);
	
	//void realloc(long n);
	~CArr(void)
	{
		if(mas != (T*)0)
			delete[] mas;
	}
};

#include "Arr.h"
#include <iostream>

template<class T>
CArr<T>::CArr(long s = 10):
	count(0),size(s)
{
		mas = new T[size];
		if(!mas)
			std::cout<<"Ошибка выделения памяти под массив!"<<std::endl;
}
template< class T>
CArr<T>::CArr(const CArr<T>&T)
{

}
int main()
{
	CArr<char> buf;
return 0;
}

Вот такая ошибка

main.obj : error LNK2019: unresolved external symbol "public: __thiscall CArr<char>::CArr<char>(long)" (??0?$CArr@D@@QAE@J@Z) referenced in function _main
Помогите пожалуйста увидеть что здесь не так.


Если кстати определение конструктора и деструктора внести в объявление, то все компилируется и работает. Я скорее всего по не опытности допустил где-то ошибку.

jeep ()
Ответ на: комментарий от antony986

а все прочитали сообщение об ошибке? которое ниже функции майн? можете даже не учитывать ничего кроме конструктора и деструктора. Остальное все нормально.

jeep ()
Ответ на: комментарий от jeep

Чем больше пользуюсь с++шным параметрическим полиморфизмом тем больше вижу что это какашка.

Это не параметрический полиморфизм, это всего лишь метапрограммирование.

Miguel ★★★★★ ()
Ответ на: комментарий от jeep

Чем больше пользуюсь с++шным параметрическим полиморфизмом тем больше вижу что это какашка.

очень смелое заявление для человека написавшего:

CArr(const CArr<T>&T);

ИМХО, научись не лажать сначала

shty ★★★★★ ()
Ответ на: комментарий от jeep

Это была опечатка. Думал это очевидно.

очевидно - это опечатка и, очевидно, так работать не будет

учитесь писать без опечаток и работать будет

shty ★★★★★ ()
Ответ на: комментарий от jeep

это опечатка - это очевидно. А еще очевидно то, что ошибку вызвала не опечатка. учитесь читать вопрос.

С++ не терпит опечаток и непонимания, да и вообще и само программирование не располагает

у меня всё заработало вот так и это, с точки зрения определения сигнатур, правильно:

CArr(long s = 10); 

и лучше писать не

   T* mas; 

а

   T* arr; 
shty ★★★★★ ()
Ответ на: комментарий от Sergey

> извините , а почему mass хуже arr?

потому-что на транслите пишут только мудаки

captcha: salaries help

anonymous ()
Ответ на: комментарий от Sergey

извините , а почему mass хуже arr?

потому что mass - это масса, а array - это массив

ЗЫ спросите у гугля, если не верите :)

shty ★★★★★ ()
Ответ на: комментарий от shty

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

Sergey ()
Ответ на: комментарий от Sergey

Я не просто так спросил. дело в том, что все мы говорим по разному и имена придумываем исходя из своих предпочтений. И почему нам обязательно использовать английский?

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

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

Вам же не понравилось бы читать комментарии на китайском языке (или любом другом языке который Вы не знаете)? :)

shty ★★★★★ ()
Ответ на: комментарий от antony986

тогда уж m_arr

я обычно пишу так:

template< typename _Ty > 
class CArr {
private:
    _Ty *_array;
}

буква «m» имхо явно лишняя, зачем тратить время на её набивание? :)

shty ★★★★★ ()
Ответ на: комментарий от shty

Если вы пишете open source для европ то да. Но это уже дополнительные требования, выходящие за рамки данной задачи. А например язык 1С и русский и английский одновременно. Писать там по-английски у нас просто неразумно, но при желании можно. Мне кажется что так правильно. - пусть сама задача ставит свои требования и ограничения.

Sergey ()
Ответ на: комментарий от shty

я обычно пишу так

за такое следует отрывать три и более конечностей. идентификаторы, начинающиеся с подчёркивания (равно как и содержащие двойное подчёркивание), зарезервированы для служебного использования в реализации; ISO/IEC 14882:2003, 17.4.3.2.1

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

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

Sergey ()
Ответ на: комментарий от Sergey

Если вы пишете open source для европ то да.

не обязательно что Вы прям пишете для Европ сразу, но коль Вы пишете open source то имхо(!), честнее писать так чтобы большая часть потенциальной аудитории всё же смогла прочитать что Вы там имели в виду :)

и да, имена переменных - это индикатор определённой школы программирования или её отсутствия

А например язык 1С и русский и английский одновременно. Писать там по-английски у нас просто неразумно, но при желании можно.

с 1С всё понятно, там даже лучше наоборот всё по-русски писать ибо вероятность того что код будут читать и поддерживать не русскоговорящие люди - около 0

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

всё так, всё так, золотые слова :)

shty ★★★★★ ()
Ответ на: комментарий от jtootf

за такое следует отрывать три и более конечностей. идентификаторы, начинающиеся с подчёркивания (равно как и содержащие двойное подчёркивание), зарезервированы для служебного использования в реализации; ISO/IEC 14882:2003, 17.4.3.2.1

во-первых за пафос и наезд не по делу оторвите себе 1 штрафную конечность

во-вторых в указанном документе такого пункта нет - оторвите себе +1 конечность

во-третьих, по всей видимости, Вы имели в виду пункт 17.4.3.1.2, но невнимательно его прочитали ибо там разговор идёт об именах глобальных переменным, что, конечно простите, но под данный случай ну вот нифига не подходит - оторвите себе +1 конечность (или будете спорить?)

мораль: прежде чем громко выпускать газ убедитесь в отсутствии открытого огня в эпсилон-окрестности

shty ★★★★★ ()
Ответ на: комментарий от shty

[quote][b]цитата[/b] не обязательно что Вы прям пишете для Европ сразу, но коль Вы пишете open source то имхо(!), честнее писать так чтобы большая часть потенциальной аудитории всё же смогла прочитать что Вы там имели в виду :)

и да, имена переменных - это индикатор определённой школы программирования или её отсутствия [/quote]

Для начала не будем путать школу и манеру. Они всё-же и различается и взаимодействуют как качество и количество. Затем требование под названием «open source» это и есть то дополнительное требование которое в данном вопросе выбора не оставляет. Но разве кто-то такое условие ставил? И вообще. Если вы работаете в приличном предприятии где этот процесс поставлен, то все эти требования вам объявят в первый день в виде стандартов предприятия. И это будет для вас законом даже если заставят писать по-испански. И это никак не повлияет ни на вашу квалификацию ни на школу и пр. В чём-же принципиальность использования именно английского языка в не зарезервированных словах? Зачем например тем-же китайцам специально изучать возможно весьма для них чужой язык чтобы писать программы? Какой интерес китайцу в том, чтобы его тексты мог легко смотреть американец? Японцы например даже не все английские слова произнести правильно могут. Я был свидетелем таких казусов, когда вместо election они пишут или говорят erection. Знаете, если тех-же китайцев всех заставить говорить только по-английски в аэропортах и самолётах, то скорее всего они станут чаще летать на своих китайских самолётах. Так-же и здесь, если выставлять много дополнительных требований под маркой «open source» то возможно что появятся национальные «open source» или или ещё какие-то другие его фракции. Мне кажется что хорошие дела насильно делать нельзя, нельзя к ним принуждать. Вы вот к этому сами пришли и хорошо, так дайте и остальным самим понять что есть хорошо.

Sergey ()
Ответ на: комментарий от shty

Вы имели в виду пункт 17.4.3.1.2

да, опечатался

но невнимательно его прочитали

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

jtootf ★★★★★ ()
Ответ на: комментарий от Sergey

цитата не обязательно что Вы прям пишете для Европ сразу, но коль Вы пишете open source то имхо(!), честнее писать так чтобы большая часть потенциальной аудитории всё же смогла прочитать что Вы там имели в виду :)

и да, имена переменных - это индикатор определённой школы программирования или её отсутствия

Для начала не будем путать школу и манеру. Они всё-же и различается и взаимодействуют как качество и количество.

эм? манера определяется школой и практика написания «self documenting code» - это признак хорошей школы программирования

Затем требование под названием «open source» это и есть то дополнительное требование которое в данном вопросе выбора не оставляет. Но разве кто-то такое условие ставил?

а это вовсе и не требование :) я просто приводил примеры когда может понадобится умение «думать» вменяемо по-английски

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

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

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

Зачем например тем-же китайцам специально изучать возможно весьма для них чужой язык чтобы писать программы?

и правда, давно бы уже написали КНЯП (китайский национальный язык программирования) :)

а если серьёзно, Вы таки отрицаете полезность обмена информацией и то что направление развития по области задают СШП?

Вы вот к этому сами пришли и хорошо, так дайте и остальным самим понять что есть хорошо.

дык я ж не командую, я озвучиваю свои размышления на тему :)

shty ★★★★★ ()
Ответ на: комментарий от shty

Мы скоро дойдём до философии если не остановимся. Вы говорите что не командуете, но кажется вы и начали с того что поменяли корректное с точки зрения стандартов и компиляторов имя переменной на англоязычное. Я ведь только поэтому и стал спрашивать. А тут и ещё кто-то влез со своим категоричным мнением. Вот меня и заинтересовала причина этой категоричности. Никакй речи об «open source» или обмене совсем миром не шло. Я понимаю, что возможно так и лучше , но вопрос-то был не об этом.

Недавно мне пришлось работать с людьми которые английского не знают вообще и сами догадываетесь какие у них названия. Но софт и прибор работают. Сама продукция с внутреннего рынка скорее всего не уйдёт никогда и зачем их учить чужому языку? Уж лучше им поставить CM и version control больше пользы будет.

Sergey ()
Ответ на: комментарий от Sergey

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

заметьте, Вы противопоставляете «корректное с точки зрения стандарта (-ов? каких?) и компиляторов» и «английское» имя переменной, сравниваете зелёное с квадратным, не кажется ли Вам такое сравнение некорректным?

да я начал с того привёл пример в котором изменил название переменной, но помните ли Вы комментарий которым я сопроводил этот кусок кода? там были какие то директивы?

Я понимаю, что возможно так и лучше , но вопрос-то был не об этом.

так задайте Ваш вопрос, возможно он ускользнул из поля зрения во время диалога

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

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

если честно, я вообще не понимаю людей которые программируют и не знают английского языка, то есть слова new, for, for_each, copy, swap, map, iterator +100500 других слов для них тарабарщина которую они заучили прилежно наизусть? это очень плохо

поймите, код должен быть так написан, в идеале, чтобы для него не нужно было бы комментариев, например, не пишите Вы mas, а напишите, хотя бы, massiv уже понятнее в 100 раз будет (хоть, на мой взгляд, и коряво :))

Но софт и прибор работают. Сама продукция с внутреннего рынка скорее всего не уйдёт никогда и зачем их учить чужому языку?

мозг развивает

Уж лучше им поставить CM и version control больше пользы будет.

Вы опять зелёное и квадратное мешаете, причём тут vcs когда мы разговариваем о code style?

shty ★★★★★ ()
Ответ на: комментарий от shty

Мне вообще пох** как написано. В стандарте не прописано как переменные
лучше называть. Если кого-то волнует мое знание английского, то оно
достаточно для чтения тех литературы и задатьвопрос, объяснить проблему могу. А это тупые придирки. Можете учить малышей в детском саду как правильно
писать. А у меня рабочая задача и как я уже писал до таких тупых придирок мне пох**.
И прошу вас не засоряйте тему вашими бесполезными комментариями.
ПС:
Отдельно благодарю
jtootf antony986
за то что ответили оперативно и конструктивно. Ну и за полезную ссылку благодарю. Тему считаю закрытой. Все кто хочет дальше на пустом месте языком чесать добро пожаловть создать новую тему

jeep ()
Ответ на: комментарий от jeep

Мне вообще пох** как написано.

хмы, ну Ваше право

В стандарте не прописано как переменные лучше называть.

может Вам в стандарте ещё определить как кнопки на клавиатуре жмакать?

А у меня рабочая задача и как я уже писал до таких тупых придирок мне пох**.

придирки, говорите? тяжко же Вам будет на нормальной работе :)

shty ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.