Моя первая реализация String - C/C++

Здравствуйте, Нахлобуч, Вы писали:

_>>>>Оцените пожалуйста, интересны все мои ошибки, особенно в реализации операторов !!!
_>>>>// Заголовок
Н>>>

Н>>>class nvString
Н>>>{
Н>>>public:

Н>>>    // Return the length of the string in bytes
Н>>>    // Это кэшировать надо
Н>>>    inline int Length() const
Н>>>    { return m_nLength; }

Н>>>private:
Н>>>    int m_nLength;            // Может mutable ?
Н>>>};
Н>>>

Н>А смысл? Там же нет константных функций, которые чего-то с длиной делают.

При любом изменении объекта m_nLength должно меняться. Например, написав

   str[5] = 0;

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

   m_nLength = -1;

а метод Length переписать так:

   int Length() const
   {
      if( m_nLength==-1 )
         m_nLength = strlen( ... );
      return m_nLength;
   }

Вот в этом случае mutable и потребуется.

Здравствуйте, Вадим Никулин, Вы писали:

ВН>При любом изменении объекта m_nLength должно меняться. Например, написав
ВН>

ВН>   str[5] = 0;
ВН>

ВН>у нас длина будет изменена. Но в операторе мы еще не знаем, как изменится длина, поэтому там мы можем написать
ВН>

ВН>   m_nLength = -1;
ВН>

ВН>а метод Length переписать так:
ВН>

ВН>   int Length() const
ВН>   {
ВН>      if( m_nLength==-1 )
ВН>         m_nLength = strlen( ... );
ВН>      return m_nLength;
ВН>   }
ВН>

ВН>Вот в этом случае mutable и потребуется.

Тода лучше ввести operator [] который смог бы отличить чтение (константный) от записи (неконстантный оператор) и изменять m_nLength (если требуется) в последнем.

Здравствуйте, Нахлобуч, Вы писали:

Н>Тода лучше ввести operator [] который смог бы отличить чтение (константный) от записи (неконстантный оператор) и изменять m_nLength (если требуется) в последнем.

Я про это и говорю. Какой у тебя синтаксис operator [] ? Если char &operator [] ( int k ), то надо перечитать мой предыдущий пост. Если ты хочешь прокси-объект возвращать, то действительно можно обойтись без mutable. Только в этом случае на каждый чих ты будешь пересчитывать длину строки. А если она тебе никогда не понадобится?

Здравствуйте, Вадим Никулин, Вы писали:

ВН>Здравствуйте, Нахлобуч, Вы писали:

Н>>Тода лучше ввести operator [] который смог бы отличить чтение (константный) от записи (неконстантный оператор) и изменять m_nLength (если требуется) в последнем.

ВН>Я про это и говорю. Какой у тебя синтаксис operator [] ? Если char &operator [] ( int k ), то надо перечитать мой предыдущий пост. Если ты хочешь прокси-объект возвращать, то действительно можно обойтись без mutable. Только в этом случае на каждый чих ты будешь пересчитывать длину строки. А если она тебе никогда не понадобится?

Ну я про прокси-класс и писал. А пересчет (если он вообще потребуется) займет всего-то ничего:

class string
{
    // ...
    char& operator [] (size_t n)
    {
        
    }
    
};

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

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

__>>>Можно писать и так :
__>>>

__>>>delete p;
__>>>p=NULL;
__>>>

_>>При таком варианте приходится полагатся, на разработчиков компиляторов,а также на разработчиков библиотек.

SM>ну вы даете!
SM>1. причем тут компилятор?
SM>2. неужели могут быть сомнения, что при реализации delete разработчики допустят такую ошибку?

Дело не в ошибке. Стандартом не определяется что delete на 0 не реагирует. Каждый реализует по своему разумению. Просто в последнее время стало считатся хорошим тоном проверять в операторе delete на 0. В более ранних версиях компиляторов проверки небыло.

SM>что значит устарело? так вроде всегда было!
Было, будет и нужно так делать. Просто теперь можно проверку не ставить (правда предворительно проверив свой компилятор)

Здравствуйте, Нахлобуч, Вы писали:

ВН>>Я про это и говорю. Какой у тебя синтаксис operator [] ? Если char &operator [] ( int k ), то надо перечитать мой предыдущий пост. Если ты хочешь прокси-объект возвращать, то действительно можно обойтись без mutable. Только в этом случае на каждый чих ты будешь пересчитывать длину строки. А если она тебе никогда не понадобится?

Н>Ну я про прокси-класс и писал. А пересчет (если он вообще потребуется) займет всего-то ничего:
1. Где прокси-класс? В примере не прокси-класс.
2. Все-равно пересчет — лишние инструкции для процессора. +Затраты на прокси.
Н>

Н>class string
Н>{
Н>    // ...
Н>    char& operator [] (size_t n)
Н>    {
Н>    }
    
Н>};
Н>

Здравствуйте, Вадим Никулин, Вы писали:

ВН>Здравствуйте, Нахлобуч, Вы писали:

ВН>>>Я про это и говорю. Какой у тебя синтаксис operator [] ? Если char &operator [] ( int k ), то надо перечитать мой предыдущий пост. Если ты хочешь прокси-объект возвращать, то действительно можно обойтись без mutable. Только в этом случае на каждый чих ты будешь пересчитывать длину строки. А если она тебе никогда не понадобится?

Н>>Ну я про прокси-класс и писал. А пересчет (если он вообще потребуется) займет всего-то ничего:
ВН> 1. Где прокси-класс? В примере не прокси-класс.
Я писал, что можно использовать прокси-класс.

ВН> 2. Все-равно пересчет — лишние инструкции для процессора. +Затраты на прокси.
Это да.

Здравствуйте, Аноним, Вы писали:

А>Дело не в ошибке. Стандартом не определяется что delete на 0 не реагирует. Каждый реализует по своему разумению. Просто в последнее время стало считатся хорошим тоном проверять в операторе delete на 0. В более ранних версиях компиляторов проверки небыло.

5.3.5.2
.... if the value of the operand of delete is the null pointer the operation has no effect

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

LIS>>>>

LIS>>>>#define DELETE_P if (p) { delete p; p = NULL; }
LIS>>>>

_>>Так надежней. Хотя и устарело...
__>Что имеется вииду под словом "надежней" ?

Вопрос переносимости.

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

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

LIS>>>>>

LIS>>>>>#define DELETE_P if (p) { delete p; p = NULL; }
LIS>>>>>

_>>>Так надежней. Хотя и устарело...
__>>Что имеется вииду под словом "надежней" ?

_>Вопрос переносимости.
В чем имено проблема с переносимостью ?

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

I>Здравствуйте, Аноним, Вы писали:

А>>Дело не в ошибке. Стандартом не определяется что delete на 0 не реагирует. Каждый реализует по своему разумению. Просто в последнее время стало считатся хорошим тоном проверять в операторе delete на 0. В более ранних версиях компиляторов проверки небыло.

I>5.3.5.2
I>.... if the value of the operand of delete is the null pointer the operation has no effect

Не все компиляторы подерживают стандарт. Стандарт в окончательной редакции был вупущен в начале 1998г + пару лет на доработку компиляторов.

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

А>>>Дело не в ошибке. Стандартом не определяется что delete на 0 не реагирует. Каждый реализует по своему разумению. Просто в последнее время стало считатся хорошим тоном проверять в операторе delete на 0. В более ранних версиях компиляторов проверки небыло.

I>>5.3.5.2
I>>.... if the value of the operand of delete is the null pointer the operation has no effect

_>Не все компиляторы подерживают стандарт. Стандарт в окончательной редакции был вупущен в начале 1998г + пару лет на доработку компиляторов.

ну сейчас уже слава богу 2004
и даже vc6 с этим справляется

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

_AK>>

_AK>>nvString a,b,c;
_AK>>a+b=c;
_AK>>

L_L>Предлагаю попробовать такое
L_L>

L_L>std::string a, b, c;
L_L>a + c = b;
L_L>

_>>>Моя первая реализация String

_AK>>Лучше чтобы она была бы ещё и последней.

L_L>Зачем так? Человек попросил указать ошибки, а ему — такие гадости.

не гадости, а намёк: std::string...

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

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

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

LIS>>>>>>

LIS>>>>>>#define DELETE_P LIS>>>>>>

_>>>>Так надежней. Хотя и устарело...
__>>>Что имеется вииду под словом "надежней" ?

_>>Вопрос переносимости.
__>В чем имено проблема с переносимостью ?

Kaa>Не все компиляторы подерживают стандарт. Стандарт в окончательной редакции был вупущен в начале 1998г.
С высокой долей вероятности можно утверждать что на компиляторе выпущеном до 1998г, проверки на 0 может не оказаться.
Также никто не может гарантировать, что на N компиляторе N версии выпущеном позднее, будет проверяться указатель (всегда есть вероятность обратного).

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

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

_AK>>>

_AK>>>nvString a,b,c;
_AK>>>a+b=c;
_AK>>>

L_L>>Предлагаю попробовать такое
L_L>>

L_L>>std::string a, b, c;
L_L>>a + c = b;
L_L>>

_>>>>Моя первая реализация String

_AK>>>Лучше чтобы она была бы ещё и последней.

L_L>>Зачем так? Человек попросил указать ошибки, а ему — такие гадости.

_AK>не гадости, а намёк: std::string...

Надо сначала свои шишки набить. имхо.

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

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

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

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

LIS>>>>>>>

LIS>>>>>>>#define DELETE_P LIS>>>>>>

_>>>>>Так надежней. Хотя и устарело...
__>>>>Что имеется вииду под словом "надежней" ?

_>>>Вопрос переносимости.
__>>В чем имено проблема с переносимостью ?

Kaa>>Не все компиляторы подерживают стандарт. Стандарт в окончательной редакции был вупущен в начале 1998г.
_>С высокой долей вероятности можно утверждать что на компиляторе выпущеном до 1998г, проверки на 0 может не оказаться.
_>Также никто не может гарантировать, что на N компиляторе N версии выпущеном позднее, будет проверяться указатель (всегда есть вероятность обратного).
Полностью согласен, так как реализация не всегда соответсвует стандарту, однако вероятность того что неправильно будет отработанно delete 0 в компиляторе позже 1998 очень мала.

P.S.
На всякий случай можно проверить поведение delete 0 на конкретном компиляторе.
Или пользоватся макросом :

#if // нету соответствия со стандартом
#define DELETE_IF(x) \
 if(x) { delete x; x=0; }
#else // соответствие со стандартом
#define DELETE_IF(x) \
 { delete x; x=0; }
#endif

IMHO смысл в подобных извращениях я не вижу.

P.P.S.
Думаю стоит эту тему закрыть.

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

_>Оцените пожалуйста, интересны все мои ошибки, особенно в реализации операторов !!!
[]

Когда определяешь функции внутри определения класса, то можно не писать inline, они являются inline по умолчанию.

Здравствуйте, <Аноним>, Вы писали:

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

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

__>>>>Можно писать и так :
__>>>>

__>>>>delete p;
__>>>>p=NULL;
__>>>>

_>>>При таком варианте приходится полагатся, на разработчиков компиляторов,а также на разработчиков библиотек.

SM>>ну вы даете!
SM>>1. причем тут компилятор?
SM>>2. неужели могут быть сомнения, что при реализации delete разработчики допустят такую ошибку?

А>Дело не в ошибке. Стандартом не определяется что delete на 0 не реагирует.

Неправда.

А>Каждый реализует по своему разумению. Просто в последнее время стало считатся хорошим тоном проверять в операторе delete на 0. В более ранних версиях компиляторов проверки небыло.

Неправда.

SM>>что значит устарело? так вроде всегда было!
А>Было, будет и нужно так делать. Просто теперь можно проверку не ставить (правда предворительно проверив свой компилятор)

... << RSDN@Home 1.1.0 stable >>

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

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

I>>Здравствуйте, Аноним, Вы писали:

А>>>Дело не в ошибке. Стандартом не определяется что delete на 0 не реагирует. Каждый реализует по своему разумению. Просто в последнее время стало считатся хорошим тоном проверять в операторе delete на 0. В более ранних версиях компиляторов проверки небыло.

I>>5.3.5.2
I>>.... if the value of the operand of delete is the null pointer the operation has no effect

_>Не все компиляторы подерживают стандарт. Стандарт в окончательной редакции был вупущен в начале 1998г + пару лет на доработку компиляторов.

Это тоже неправда. Текущий стандарт -- это третья версия языка. Сам язык существует уже очень давно. С самого начала delete не делал ничего с нулевыми указателями.

... << RSDN@Home 1.1.0 stable >>

От:	Вадим Никулин	Здесь
Дата:	08.07.04 14:51
Оценка:

От:	Нахлобуч	https://hglabhq.com
Дата:	08.07.04 15:04
Оценка:

От:	Вадим Никулин	Здесь
Дата:	08.07.04 15:18
Оценка:

От:	Нахлобуч	https://hglabhq.com
Дата:	08.07.04 15:25
Оценка:

	От:	Аноним
	Дата:	08.07.04 15:28
	Оценка:	-1

	От:	Шахтер
	Дата:	10.07.04 00:41
	Оценка:

	От:	Шахтер
	Дата:	10.07.04 01:01
	Оценка: