Arduino.ru

Интересны методы других людей.

А если искать, то что после ">" но не "<"? И каковы пределы изменения искомого?

Имхо, самый простой алгоритмически вариант - это тупо

char* ptr = strstr_P(buffer,(const char*) F("<h3>"));
if(ptr)
{
 ptr += 4;
 String result;
 while(*ptr && *ptr != '/')
  result += *ptr++;
}

Всё.

1-2 cимвола

"/24" постоянно присутствует?

да

Т.е. просмотреть сотню-другую байтов при тактовой 16 МГц - это слишком медленно?

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

char* ptr = strstr_P(buffer,(const char*) F("<h3>"));
if(ptr)
{
 ptr += 4;
 String result;
 while(*ptr && *ptr != '/')
  result += *ptr++;
}

Предлагаете делением пополам искать? Овчинка выделки не стоит при таких объёмах входящих данных. Потом - всё зависит от реализации strstr - если она (а это, скорее всего, так) написана грамотно - то работает быстрее некуда и так уже.

char* ptr = strstr_P(buffer,(const char*) F("<h3>"));
if(ptr)
{
 ptr += 4;
 String result;
 while(*ptr && *ptr != '/')
  result += *ptr++;
}

Если не трудно, переведите \ откомменнтируйте плиз этот код, как слабо знающий С нифига не понял

Бег указателем по буферу, пока не встретится '\0' или '/' с одновременным добавлением текущего символа к строке.

Правда, не понял зачем +4... это только для текущего примера с тэгом из четырех букв.

char* ptr = strstr_P(buffer,(const char*) F("<h3>")); // ищем первое вхождение подстроки в строку
if(ptr) // если найдено
{
 ptr += 4; // переходим за подстроку (тут тупо хардкод, но легко переписывается на strlen)
 String result; // сюда будем добавлять результат
 while(*ptr && *ptr != '/') // пока байт, на который указывает указатель, не равен 0 (символ окончания строки) и не равен '/' (по условиям парсинга)
  result += *ptr++; // складываем этот символ в промежуточный буфер, заодно инкрементируя указатель, чтобы он указывал на следующий символ. Постфиксный инкремент имеет меньший приоритет, чем разыменование, поэтому сперва получим символ, потом - подвинем указатель на следующий символ.
}

Откомментировал.

Ещё вариант, в виде функции, возвращающей число, и без использования всяких String:

bool findNumber(const char* haystack, const char* needle, int& result)
{
	if(!haystack || !needle)
		return false;
		
	char* ptr = strstr(haystack,needle);
	
	if(!ptr)
		return false;

	result = 0;
	
	ptr += strlen(needle);
	
	bool first = true;
	int8_t sign = 1;
	
	while(true)
	{
		char ch = *ptr++;
		if(!ch || !( (ch >= '0' && ch <= '9') || (first && ch == '-') ))
			break;
		
		if(first && ch == '-')
			sign = -1;
		else
		{
			result *= 10;
			result += (ch - '0');
		}
		
		
		first = false;
	}
	
	result *= sign;

	return true;
}


int result;
if(findNumber(buffer,"<h3>",result))
{
	Serial.println(result);
}

Писал навскидку, с учётом знака, только целые числа после нужной подстроки. Могут быть апшипки.

Если не писать чушь и посмотреть тип данных, в котором ищется, то сразу станет понятно, что char* ОБЯЗАНА заканчиваться нулём - это так принято в C/C++, поскольку нет встроенного типа данных "строка".

Для того, чтобы это понять - достаточно посмотреть прототип strstr, и тогда желание писать глупости - поубавится ;)

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

есть еще функция trim, которой можно обрезать ненужные строки 

нахрена??? поставить указатель на начало поиска зная указатель конца буфера можно простым вычитанием длины данных, здесь это значение равно 39, то-есть указатель начала блока данных равен указатель конца буфера минус 39

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

Во только как определить, что он закончился, и пора начинать искать, собственно, данные?

"Конца буфера" или "конца заполлненной части буфера"?

Если первое - откуда уверенность, что искомое находится не дельше 39 символа от него. А если второе - сколько операций нужно сделать, чтобы найти конец заполненной части буфера? А то ведь можеь оказаться, что вместо того, чтобы найти искомое в районе, скажем 80-го символа, мы сначала просматриваем буфер до 120 символа и только потом отнимаем 39. Т.е. вместо 80 операций делаем 120.

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

К сожалению, я не знаю, как следует реагировать на утверждение "всегда должен быть", т.к. не понял, Вы все-таки говорите о конце буфера либо о его начале.

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

Ещё раз для упоротых: посмотри прототип strstr и уже успокойся - она работает с указателем на массив символов (char*), который ОБЯЗАН заканчиваться нулевым байтом. Если не заканчивается - программист, который передал в strstr чушь - такой же, как и ты: выскочка и недоучка, который ищет проблемы там, где их нет.

Товарищи-инжинеры. Я сделал костыль который даст мне большие приемущества упростив всем жизнь. Я просто написал скрипт на php который будет возвращать в сокет данные без всего. Только информация. Ибо добавить 1 файлик в сайт будет более оптимально с точки зрения нагрузки. Увеличит плавность подсветки.

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

Да обе ситуации нормальны и имееют право на жизнь: та, в которой функция сама проверяет входные параметры и та, в которой она доверяет передающей функции. Первый способ безопасней, второй быстрее. Я где-то читал разбор кода линуксового ядра - там все на доверии построено, потому как контроль всех возможных ситуаций - это жуткий оверхед. 

На мой взгляд, весма сомнительное утверждение.

Если бы оно было справедливо, Линукс бы валился от любого чиха неопытного программиста, не говоря уже о вирусах, написанных малограмотными школярами. Правильная программа должна корректно работать при любых входных данных, в том числе и некорректных (т.е. должна отслеживать корректность данных и в случае обнаружения некорректности обходить ее наименее разрушительным способом).

Речь не о программе, а о функции. 

Или что, в линупсе strlen , к примеру, защиты имеет какие-то?

Ну, насколько мне известно, существуют и ее варианты с защитми (Си - не мой родной язык, так что напамять не воспроизведу).

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

вспоминается мне большая "дыра" с этими strlen,strstr,strcmp когда передавали указатель на хитрую последовательность байт которая валила стек и получала управление в нужном месте.

но это было давно. 

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

соглашусь 100% !!! Но студентов наших, усилиями коих пилятся сейчас все бюджетные деньги этому не учат, а вот в зарубежных фирмах разработков ПО это азбучная истина

вот, жуткая полемика возымела действие, обработка перенесена на сторону сервера )))

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

Достойно спроектированная же ОС не падает от проблем записи в userspace, а в kernel ring не допускает никого левого. Поделки же людей, которые заводят указатель неизвестно на что и пишут потом туда херню, шлепаются за милую душу. Но никто и не думает в связи с этим устраивать трагедию и анально огораживать все внутри маленького memmove, потому что смысла в этом нет.

Винда вон пускала в ранних версиях дрова в Ring 0 и что мы видели - постоянные синие экраны, как только юзер накатил странный драйвер. И ничего, разработчики винды не перестали пользоваться на нижнем уровне небезопасными функциями языка программирования, просто пересмотрели архитектуру.

Ой млять, совсем у тебя с головой не алё, видимо. Бывает.

Ты только хомячкам местным малограмотным это не объясняй - бесполезно, эти тела всё с ног на голову поставят ;) Мало того, что не знают и не понимают простейших вещей, типа того - что такое псевдокод. Так и дальше - сморозит хуйню, и сидит с умным лицом, мол, смотрите какой я пушистый :)

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

Понимаешь масштаб бедствия у поколения ЕГЭ?

Тогда возникают следующие уточняющие вопросы:

1. Кому он известен?

2. Откуда он известен?

Аргументируйте.

Во-первых, вне зависимости от RISC/SISC на компьютерах с фон-неймановской архитектурой области программ и данных пересекаются по определению. Даже не просто пересекаются, а это - одна и та же область.

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

Опять срач на ровном месте?

Ваше первое предложение есть верный ответ на приведенную вашу же цитату.

Помнится, в году так 1990-м, участвовал в славном городе Севастополь на коференции по оптимизации ПО и разработке библиотек нижнего уровня (типа strstr). Помнится там велись жаркие дискуссии на предмет должна ли библиотечная функция контролировать и перепроверять все свои входные параметры .. помнится сильным аргументом стало что-то на предмет снижения общей производительности при вкладывании такой функции в цикл и особенно многократно. Там чуть ли не квадратичная зависимость потери производительности от количества проверяемых параметров, вариантов проверок и уровня вкладывания.

.. собственно после этого, наше поколение для идиотов придумало модель MVC .. дабы ВСЕ проверки выносились как можно выше и раньше.

Терпеть не могу когда мусорного кода для проверок ошибок в либах составляет половину библиотеки.

Аналогично. Вопрос обхода ошибки не может решаться силами библиотечных функций. Это задача вызывающего кода подавать правильные данные = правильно использовать библиотеку, а не "безмозгло".

ИМХО, это главная причина того, что многие тут в свое время не смогли пользовать тот самый arhat.h :)

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

Автору виднее.

Нет, мое представление о прекрасном тоже не совпадает с представлением автора arhat.h. Ну так я даже и не пытался использовать его библиотеку целиком: просмотрел, надергал полезных (с моей точки зрения) фрагментов, исправил места, где автор наделал откровенных (с моей точки зрения) ляпов, и с благодарностью к автору пользуюсь надерганным и исправленным.