const char* const - Путаница - C/C++

"const char* const" в функции GetName() надо чтоб зажитит m_name, т.е. чтоб не изменить его значение?

class Device
{
...
private:    
    char m_name[20];
public:
...
    const char* const GetName() const;
}

Но вот таким образом у меня получается изменить значение m_name с "name1" на "name2"

Device d("name1");
strcpy((char*)d.GetName(),"name2");

Или я не правильно понял "const char* const". Поясниете плиз.

Спасибо.

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

TA>Но вот таким образом у меня получается изменить значение m_name с "name1" на "name2"
TA>

TA>Device d("name1");
TA>strcpy((char*)d.GetName(),"name2");
TA>

TA>Или я не правильно понял "const char* const". Поясниете плиз.

Очевидно, ты не правильно понял смысл (char*). Именно этим ты нарушил существующие правила для контроля типов в С++, сделав принудительное приведение типа. Следовательно все последствия налицо.

TA>Спасибо.

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

TA>"const char* const" в функции GetName() надо чтоб зажитит m_name, т.е. чтоб не изменить его значение?
Все правильно, он и защищает — ты не сможешь ничего туда записать без явного хака.

TA>Но вот таким образом у меня получается изменить значение m_name с "name1" на "name2"
Ну правильно, потому что ты используешь явный хак, который тебе пришлось руками написать и который хорошо виден.

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

TA>"const char* const" в функции GetName() надо чтоб зажитит m_name, т.е. чтоб не изменить его значение?

Функция GetName возвращает константный указатель на константную строку. В принципе первый const избыточен, а вот второй как раз защищает возвращаемый объект (строку) от модификаций.

TA>Но вот таким образом у меня получается изменить значение m_name с "name1" на "name2"
TA>

TA>Device d("name1");
TA>strcpy((char*)d.GetName(),"name2");
TA>

Против лома нет приема — ты своими руками снял константность с результата GetName — компилятор после этого умывает руки

TA>Или я не правильно понял "const char* const". Поясниете плиз.
Достаточно возвращать из функции char const*, ну и не использовать лом там, где не нужно

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

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

TA>>"const char* const" в функции GetName() надо чтоб зажитит m_name, т.е. чтоб не изменить его значение?

B>Функция GetName возвращает константный указатель на константную строку. В принципе первый const избыточен, а вот второй как раз защищает возвращаемый объект (строку) от модификаций.

"О сколько их упало в эту бездну..."

http://duramecho.com/ComputerInformation/WhyHowCppConst.html

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

TA>>>"const char* const" в функции GetName() надо чтоб зажитит m_name, т.е. чтоб не изменить его значение?

B>>Функция GetName возвращает константный указатель на константную строку. В принципе первый const избыточен, а вот второй как раз защищает возвращаемый объект (строку) от модификаций.

CS>"О сколько их упало в эту бездну..."

Второй (самый правый) const конечно же.

В свое оправдание могу сказать, что финальный ответ все-таки верный

Достаточно возвращать из функции char const*...

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

B>Здравствуйте, c-smile, Вы писали:

TA>>>>"const char* const" в функции GetName() надо чтоб зажитит m_name, т.е. чтоб не изменить его значение?

не совсем в тему, но предлагаю перейти на "классовые" строки типа QString — проблем будет меньше

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

X>не совсем в тему, но предлагаю перейти на "классовые" строки типа QString — проблем будет меньше

Это совсем не в тему.

Слепое использование QString или std::string в тех местах где можно обойтись просто const wchar_t* или slice<wchar_t>
может привести к одной но зело неприятной проблеме — перерасход и/или фрагментация heap.

Если понятие const char* вызывает проблемы то имхо следует уже переходить на .NET/Java. Там во всяком случае не будет фрагментации.

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

B>Достаточно возвращать из функции char const*

Кстати по поводу избыточного const. Вот два объявления:

const char* const GetName();
const int GetNumber();

В первом избыточный const находится справа в имени типа, в втором — слева. Альтернативная форма позиции const более последовательна:

char const* const GetName();
int const GetNumber();

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

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

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

X>>не совсем в тему, но предлагаю перейти на "классовые" строки типа QString — проблем будет меньше

CS>Это совсем не в тему.

CS>Слепое использование QString или std::string в тех местах где можно обойтись просто const wchar_t* или slice<wchar_t>
CS>может привести к одной но зело неприятной проблеме — перерасход и/или фрагментация heap.

можно пример, приводящей к такой фрагментации и как это решается без фрагментации средствами char* ?

также "классовые" строки предоставляют удобные средства по их обработке внутри класса, и есть вспомогательные, например qregexp

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

I>Означает совершенно то же самое, но избыточный const находится справа в обоих случаях, что позволяет сформулировать простое правило: "const непосредственно перед именем функции избыточен".

Это еще почему?

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

X>можно пример, приводящей к такой фрагментации и как это решается без фрагментации средствами char* ?

Хмм... грешным делом думал это очевидно.

Вот тебе пример: http://www.codeproject.com/KB/recipes/HTML_XML_Scanner.aspx

Этот xml scanner и приведенная в статье тестовая программа в процессе
работы не аллоцируют памяти. В смысле вообще. Какого бы размера входной файл не был.

X>также "классовые" строки предоставляют удобные средства по их обработке внутри класса, и есть вспомогательные, например qregexp

Да, в C++ можно объявить классы и у них описать методы. Ты этот факт имел ввиду?
Или что-то конкретное? Как-то std::string и "удобные средства по их обработке внутри класса" слабо вяжутся.

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

CS>Это еще почему?

Это потому. У тебя есть контрпример?

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

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

X>>можно пример, приводящей к такой фрагментации и как это решается без фрагментации средствами char* ?
CS>Хмм... грешным делом думал это очевидно.
CS>Вот тебе пример: http://www.codeproject.com/KB/recipes/HTML_XML_Scanner.aspx
CS>Этот xml scanner и приведенная в статье тестовая программа в процессе
CS>работы не аллоцируют памяти. В смысле вообще. Какого бы размера входной файл не был.

хотелось бы увидеть пример когда использование QString | std::string приводило бы к неприятной фрагментации памяти , а char* нет

указанный пример (http://www.codeproject.com/KB/recipes/HTML_XML_Scanner/xh_scanner_demo.zip) не работает, если, например, в main в si добавить русскую букву в UTF8 (не у всех же венда стоит с однобайтовой кодировкой) — это из-за "ползанья" по строке с помощью p++
вот и глюк нашелся

X>>также "классовые" строки предоставляют удобные средства по их обработке внутри класса, и есть вспомогательные, например qregexp

CS>Да, в C++ можно объявить классы и у них описать методы. Ты этот факт имел ввиду?
CS>Или что-то конкретное? Как-то std::string и "удобные средства по их обработке внутри класса" слабо вяжутся.

конкретно QString

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

X>хотелось бы увидеть пример когда использование QString | std::string приводило бы к неприятной фрагментации памяти , а char* нет

Вот тебе живой пример:
http://pavlovdotnet.wordpress.com/2007/11/10/memory-fragmentation/

Это реальная проблема и не важно что именно ты используешь QString или nsString

X>указанный пример (http://www.codeproject.com/KB/recipes/HTML_XML_Scanner/xh_scanner_demo.zip) не работает, если, например, в main в si добавить русскую букву в UTF8 (не у всех же венда стоит с однобайтовой кодировкой) — это из-за "ползанья" по строке с помощью p++
X>вот и глюк нашелся

Программеры спеки/доки не читают, да. Даже если текста там всего ничего.

The given scanner does not address any input stream encoding problems.

X>конкретно QString

Конекретно QString аллоцирует две версии строки в виде char* и wchar* в одном instance QString что делает проблему фрагментации серьёзнее ровно в два раза. В server side и 24/7 системах такое использовать не надо.

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

I>Здравствуйте, c-smile, Вы писали:

CS>>Это еще почему?

I>Это потому. У тебя есть контрпример?

Ты считаешь что const в

const T function();

всегда избыточен. Я правильно тебя понял?

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

CS>Ты считаешь что const в

CS>

CS>const T function();
CS>

CS>всегда избыточен. Я правильно тебя понял?

Вообще — то изначально было так:

Альтернативная форма позиции const более последовательна:
char const* const GetName();
int const GetNumber();
Означает совершенно то же самое, но избыточный const находится справа в обоих случаях, что позволяет сформулировать простое правило: "const непосредственно перед именем функции избыточен".

Таким образом, если твою запись переделеть так:

T const function();

то я склонен согласиться с igna.

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

B>Таким образом, если твою запись переделеть так:
B>

B>T const function();
B>

B>то я склонен согласиться с igna.

Бррр.... всё, я совсем запутался.

Вот две эквивалентные формы описания возвращаемого значения:

T const function();
const T function();

я правильно понял что общественность настаивает на том что const у возвращаемого значения избыточен?

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

CS>Здравствуйте, x905, Вы писали:
X>>хотелось бы увидеть пример когда использование QString | std::string приводило бы к неприятной фрагментации памяти , а char* нет
CS>Вот тебе живой пример:
CS>http://pavlovdotnet.wordpress.com/2007/11/10/memory-fragmentation/

ок, позже почитаю повнимательнее

касательно char* строк: лично я их стараюсь избегать (как и адресной арифметике) — для меня от них проблем больше чем преимуществ, и наоборот используя QString я получаю больше преимуществ, чем недостатков
о чем и предложил топикастеру, немного отойдя от темы )

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

X>касательно char* строк: лично я их стараюсь избегать (как и адресной арифметике) — для меня от них проблем больше чем преимуществ, и наоборот используя QString я получаю больше преимуществ, чем недостатков
X>о чем и предложил топикастеру, немного отойдя от темы )

1) Ножик, он хоть и острый, но вельми полезный бывает.
2) Советы не использовать ножики в быту надо сопровождать чеками на соответсвующие суммы позволяющие нанять людей которые будут для тебя точить твои карандаши пока ты творишь.

Ну детский сад какой-то право слово. Тебе даден инструмент ты или им пользуйся профессионально или займись уже .NETом каким что-ли.
В C/C++ без указателей никак.

	От:	TheAteist
	Дата:	12.12.09 20:58
	Оценка:

	От:	wander
	Дата:	12.12.09 21:01
	Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	13.12.09 03:54
Оценка:	6 (1)

	От:	Bell
	Дата:	14.12.09 02:52
	Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	14.12.09 04:10
Оценка:	1 (1)

	От:	x905
	Дата:	15.12.09 05:49
	Оценка:

	От:	x905
	Дата:	15.12.09 07:12
	Оценка: