c++, призрачные функции

[Mayor]

c++, призрачные функции

в файле

Код:

#include <iostream>
using std::cout;

char* strcat(const char* s1,const char* s2) {
  ...
}

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

Код:

char *c=strcat(a,b);
cout<<c;
delete[] c;

почему это происходит?

[Алексей++]

а где ты выделил c через new, чтобы потом его delete ? )

Это не код призрачный, а разработчики

если уж пользуют std , там вроде std::string есть, пусть не парятся с буферами для строк

[Вад]

Происходит потому, что "c" указывает на область в чужом буфере, который не для него выделялось - не ему и освобождать.

[Антон (LogRus)]

Mayor1, RTFM бы хоть раз.
http://www.cplusplus.com/reference/clibrary/cstring/strcat.html

Return Value
destination is returned.

[Mayor]

Mayor1, RTFM бы хоть раз.
http://www.cplusplus.com/reference/clibrary/cstring/strcat.html

Return Value
destination is returned.

это то тут причем?
еще раз прочитай первый пост:
1 я не включаю <cstring>
2 я не вношу std::strcat в глобальное пространство имен
3 раз я вызвал delete[] значит моя strcat использует возвращает указатель на new[]

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


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

[Вад]

Mayor1,  ну и правильно. Делал бы ты каст в const char* для 1го параметра - тогда твоя функция ещё на что-то претендовала бы.

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

[Mayor]

Mayor1,  ну и правильно. Делал бы ты каст в const char* для 1го параметра - тогда твоя функция ещё на что-то претендовала бы.

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

да да знаю, new использовать только в конструкторах, из функций вместо char* возвращать auto_ptr, для строк написать свой класс если по оптимизации std::string неприемлим - но это в принципе некчему в студенческих задачках

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

[Антон (LogRus)]

:: вначале поставь или помести в отдельный namespace

[Вад]

Mayor1,

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

Тогда не надо использовать using namespace std;

[Mayor]

Mayor1,

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

Тогда не надо использовать using namespace std;

тоже посмотри в первый пост

я не использую using namespace std;
там есть только строчка
using std::cout;

тем не менее после
#include <iostream>
в глобальном пространстве имен появились
strlen,strcat,strcpy и еще черт знает что

зы отдельный namespace тоже не срабатывает:
после
using otnm::strlen
 компилятору без разницы что вызывать
::strlen или otnm::strlen

[Вад]

<iostream> включил? А там по цепочке и cstring включается, и string.h, и всё это в глобальный неймспейс (насчёт using был неправ - там и правда просто c-функции в глобальный идут).

А вот код

Код:

namespace MyNameSpace{
	char* strcat(const char* s1,const char* s2) {
		// ...
	}
}

int main()
{
	// ...
	char *c=MyNameSpace::strcat(a,b);
	cout<<c;
	return 0;
}

вызывает себе спокойно переопределённую версию. Зачем using-то?

[Антон (LogRus)]

после
using otnm::strlen
 компилятору без разницы что вызывать

так нефиг using писать

[Mayor]

отписался в тех поддержку, оказалось это:

дубликат багов 38531 и 6257 g++

с версии g++ 4.2 iostream перестает инклудить cstring, но тем не менее все равно cstring продолжает инжектить глобальный namespace даже в версии 4.3

[Вад]

Mayor1, а ты какой namespace хотел? Обратная совместимость
У MS инклудит за милую душу, если что. В 2008м Express в т.ч.

[Антон (LogRus)]

Mayor1, 

[Mayor]

Mayor1, а ты какой namespace хотел? Обратная совместимость
У MS инклудит за милую душу, если что. В 2008м Express в т.ч.

ну типа глобальный namespace я полностью чистым хотел

с msvs уже полгода наверное не работал инклудит то пусть инклудит, а вот инжект это уже вата

да почитал про 6257, заявили об нем в 2002 году, года 3 обсуждали является ли g++ стандартом и является ли это багом, потом решили все работы по этому багу или особенности реализации подвесить до решения экспертной комиссии, в итого раза 2-3 в год кто-нить по незнанию снова его находит и как следствие цепочка дубликатов 6257  из года в год растет