Разделение данных

[t2skler]

Написал функцию для парсинга Index'го элемента из строки с разделителем, но ф-я работает только первый раз. Я подозреваю, то что ф-я strtok как-то не так всё это делает.

string Delimiter(char* Text, int Index, const char* Delimiter) {
	if (Index == 0)
		return strtok(Text, Delimiter);
	char* Temp = "";
	int n = 0;
	strtok(Text, Delimiter);
	while (n < Index) {
		Temp = strtok('\0', Delimiter);
		if (!Temp) {
			return "";
		}
		n++;
	}
	return Temp;
}

Name = Delimiter(Str, 0, "|"); // Name заполняется
LastName = Delimiter(Str, 1, "|"); //LastName не заполняется
//если убрать Name = Delimiter(Str, 0, "|"), тогда LastName заполняется

[Пепел Феникса]

скорее вы не умеете применять strtok.
http://cplusplus.com/reference/clibrary/cstring/strtok/

[t2skler]

string Delimiter(string Text, int Index, const char* Delimiter) {
	int n = 0, find = 0;
	for (int i = 0; i <= Index; i++) {
		find = Text.find(Delimiter, n);
		if (i == Index) {
			return Text.substr(n, find - n);
		}
		n = find + 1;
	}
	return "";
}

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

[_Bers]

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

string Delimiter(string Text, int Index, const char* Delimiter) {
	int n = 0, find = 0;
	for (int i = 0; i <= Index; i++) {
		find = Text.find(Delimiter, n);
		if (i == Index) {  
			return Text.substr(n, find - n);
		}
		n = find + 1;
	}
	return "";
}

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

1. Не_рациональное падение производительности. Функция на входе получает тяжелый объект string Text по значению, что приведёт к запуску копирующего конструктора.


2. Не_рациональное падение производительности. Функция возвращает значение тяжелого объекта, что приведёт к запуску копирующего конструктора.

3. Не_рациональное падение производительности.
Условие внутри цикла:

if (i == Index) { ... }

Гарантированно будет истинным только для одной единственной итерации цикла, однако применено ко всем итерациям этого цикла.

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

Итого: можно оптимизировать.

[ElectroMent]

Кстати, оптимизацию надо проводить вроде такой:
( пример из жизни, комментарии ассоциативные )

... //какой-то код

CComboBox *pBox = &m_ComboTypeTask; /*работаем с указателем, так ||компактнее код... думаю при дальнейшей оптимизации следует заменить pBox на pB или вообще на b */

pBox->ResetContent();

if( !pBox ) { ASSERT( 0 ); return; } /*тестируем работу компилятора, вдруг напутает =))) */

... //продолжение кода.

[_Bers]

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

Кстати, оптимизацию надо проводить вроде такой:
( пример из жизни, комментарии ассоциативные )

... //какой-то код

CComboBox *pBox = &m_ComboTypeTask; /*работаем с указателем, так ||компактнее код... думаю при дальнейшей оптимизации следует заменить pBox на pB или вообще на b */

pBox->ResetContent();

if( !pBox ) { ASSERT( 0 ); return; } /*тестируем работу компилятора, вдруг напутает =))) */

... //продолжение кода.

1. Смысл тратить время на замену хорошо читаемых имен на плохо читаемые имена, в уже созданном отлаженном коде?
Замена хорошо читаемого имени переменной на плохо читаемое никакого отношения к "оптимизации" не имеет.

2. Запись вида:

CComboBox *pBox = &m_ComboTypeTask;

Предполагает, что pBox гарантированно должен смотреть на валидный объект.

А значит, проверка:

if( !pBox ) { ASSERT( 0 ); return; }

Защита от ошибок самого программиста, и не должна войти в релиз.

Следовательно, в макрос нужно обернуть весь блок условия, а не "последствия его истинности".

Проверка не должна войти в релиз. Любые грубые программные ошибки должны быть выловлены на этапе дебаг-версии.

[Пепел Феникса]

Предполагает, что pBox гарантированно должен смотреть на валидный объект.

pBox->ResetContent();

особенно это предполагает.
прикол в том что программа если дойдет до проверки то у нас гарантировано есть объект, иначе вывалиться ранее.

а вообще указатель никогда не будет null.
так как если m_ComboTypeTask это объект, то он ясное дело имеет адрес всегда.
а если ссылка то они не бывают null.

работаем с указателем, так ||компактнее код...

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

[t2skler]

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

1. Не_рациональное падение производительности. Функция на входе получает тяжелый объект string Text по значению, что приведёт к запуску копирующего конструктора.


2. Не_рациональное падение производительности. Функция возвращает значение тяжелого объекта, что приведёт к запуску копирующего конструктора.

3. Не_рациональное падение производительности.
Условие внутри цикла:

if (i == Index) { ... }

Гарантированно будет истинным только для одной единственной итерации цикла, однако применено ко всем итерациям этого цикла.

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

Итого: можно оптимизировать.

Спасибо, оптимизировал до такого кода:

string Delimiter(string Text, int Index, const char* Delimiter) {
	int n = 0, find = 0;
	find = Text.find(Delimiter, n);
	for (int i = 1; i <= Index; i++) {
		n = find + 1;
		find = Text.find(Delimiter, n);
	}
	return Text.substr(n, find - n);
}

На ссылку позже заменю.

[Пепел Феникса]

не все оптимизировали, принимайте ссылку на std::string.

2. Не_рациональное падение производительности. Функция возвращает значение тяжелого объекта, что приведёт к запуску копирующего конструктора.

вполне рационально.

[_Bers]

Сообщение от Пепел Феникса

не все оптимизировали, принимайте ссылку на std::string.
вполне рационально.

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