Search
Write a publication
Pull to refresh
3
0
Send message

Добрый день! По поводу примера 1 из раздела 5  - как то у Вас сложно получилось 😊. Вот так проще будет😊:

std::string convert1(const char buffer[15])
{
	std::array   positions{ 3, 5, 7, 9 };
	std::string  result{ buffer };
	for (auto pos : positions)
		result[pos] = '-';
	return result;
}

А по поводу: «Для данного примера нет алгоритмов, которые смогли бы решить данную задачу» - ну почему же, вполне можно😊:

std::string convert2(const char buffer[15])
{
	std::unordered_set  positions{ 3, 5, 7, 9 };
	std::string         result{ buffer };
	std::replace_if(result.begin(),
		            result.end(), 
		            [=, i = 0](auto elem) mutable {return positions.contains(i++);},
		            '-');
	return result;
}

Ну и соответственно для рэнжей решение можно написать гораздо проще😊:

std::string convert3(const char buffer[15])
{
	std::unordered_set  positions{ 3, 5, 7, 9 };
	std::string         result{ buffer };
	std::ranges::replace_if(result,
		                    [=, i = 0](auto elem) mutable {return positions.contains(i++); },
		                    '-');
	return result;
}

Добрый день! Большое спасибо за статью! Удачи Вашему фрэймворку! Не могли бы Вы уточнить несколько моментов:

1. Реализованный Вами подход, как я понимаю, отличается от Coroutine TS C++. Почему Вы не использовали разработки Lewiss Baker (follycoro) (потому что к моменту начала разработки Userver их ещё не было, или по какой-либо другой причине)? Планируете ли Вы в будущем дрейфовать в сторону стандарта (в смысле в части корутин) (или, наоборот, считаете, что стандарт должен дрейфовать в Вашу сторону ?). 

2. Есть ли где-то более или менее подробное описание Вашего подхода к  корутинам? Вынесены ли Ваши корутины в отдельную библиотеку (независимую от userver).

3. Есть ли где-то описание Вашего планировщика корутин? Вы использовали подходы, сходные с подходами Дмитрия Вьюкова (Go), или разработали что-то своё?

4. Не думали ли Вы над следующим вопросом: асинхронный сервер – это реально круто, статусно, но для большей раскрутки и востребованности проекта может имеет смысл попиариться и с точки зрения возможности делать асинхронные запросы к web-серверам (по типу pythonовского aiohttp) – чтобы привлечь на свою сторону пользователей, который запросы пишут, но которым не требуется сам web-сервер.

Всем доброго дня! Большое спасибо за статью и обсуждение! Но вообще вместо: «в общем случае RAII из C++ не позволяет делать то, что можно делать через with» корректнее сказать, что область применения with шире, чем RAII. Ваш пример про трансакцию не очень уместно рассматривать в контексте RAII – трансакция не является ресурсом (вот соединение да, ресурс). 

А автору статьи действительно стоит указать, что with позволяет изящно реализовать идиому RAII (в C++ ресурс освобождается в деструкторе, в Python из-за сборщика мусора аналогичным способом действовать не получится, но спасает блок finally, который «прячется» в with?) . 

И наверно не стоит так часто использовать термин «синтаксический сахар». Всё-таки with – это нечто большее, поскольку влияет на стиль мышления программиста, побуждая думать в логике контекста, что приводит к таким красивым обобщениям, как trio (и, соответственно, вдохновленный trio TaskGroup из asynсio).

Доброе утро! Огромное спасибо! Когда набивал заметку на Хабре, накосячил с отступами :) Поправил

Большое спасибо за замечания и за ссылку на ресурс! С форматированием – исправлюсь?

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

И ещё, подскажите, плиз, почему rigth join – плохой тон?

Information

Rating
Does not participate
Registered
Activity