- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
#include <iostream>
#include <string>
using namespace std;
/*
*/
int change_word(const int begin_pos, string &words, int k, char c)
{
int pos = begin_pos;
int char_count = 0;
bool replaced = false;
while(pos < words.length() && isalpha(words[pos]))
{
char_count++;
if(char_count == k && !replaced)
{
words[pos] = c;
replaced = true;
}
pos++;
}
return pos;
}
void change_words(string &words, int k, char c)
{
int i = 0;
while(i < words.length())
{
if(isalpha(words[i]))
{
i = change_word(i, words, k, c);
}
else
{
i++;
}
}
}
int main()
{
char c = '>';
int k = 0;
string words = "Length of the substring to be copied";
cout << "enter number:";
cin >> k;
change_words(words, k, c);
cout << "changed text: " << words << endl;
return 0;
}
Follow us!
Какое это имеет значение?
...
i = change_word(i, words, k, c);
Господи, я уж подумал она рекурсивная
lol
И какое же дефолтное значение должно быть у двух указателей?
2) откуда уверенность, что прямо таки всегда должно быть begin, end? почему не rbegin, rend? или не begin + 1, end - 1
3) единственный недостаток передачи пары итераторов - возможность передачи a.begin(), b.end(), но даже это решается нормальной реализацией оператора ==
4) как ни крути, но без передачи самого контейнера в функцию функция не узнает вообще, от чего собственно ей делать begin и end - особенно, если туда действительно надо передать начальный и конечный указатель
думаем, думаем...
Но порядок аргументов и значения по умолчанию тут вообще не при чём.
кстати, по личному опыту, range использовал только в крайне вынужденных случаях, так что насчет стандарта это показательно
ну а mpl - это совсем другая тема
Ну так правильно, зачем кардинально менять то, что неплохо работает. Я сам range ни разу не использовал, ковырял как-то ради интереса после прочтения книжки по MPL. Меня вполне удовлетворяет подход STL.
Почему? Потому что в огромном проценте случаев, эта функция нужна когда у нас уже есть контейнер и нам нужно просмотреть его целиком, а получение итераторов - тупая механическая работа. Кроме того, очень часто случается, что у нас уже есть индексы откуда и до какого места нужно просмотреть. Конвертирование этих индексов в итераторы - опять же, механическая работа засоряющая код.
Т.е. сделано по принципу не чтобы пользователям было удобно, а чтобы разработчику было удобно.
сложнейшая механическая работа, имея vec[x], vec[y], получить итераторы &vec[x], &vec[y], даа
насчет дополнительных шаблонов - таких функций в стл не три, и даже не тридцать
Та хоть три тыщи триста триццать три - какая разница мне, как пользователю? Вам жалко писателей СТЛ? Мне нет, пущай пишут.
А оставшимся процентам нужно пройтись по подстроке, которую надо предварительно найти; пройтись от начала отсортированного вектора до выполнения некоторого условия; найти что-то в словаре и, если это нашлось, то перед удалением элемента выполнить некоторую логику. Прикажете под каждый случай писать свой алгоритм? Их будет тогда действительно over9000 и это будет ад не только для разработчиков, но и для пользователей, которым придется всё это запоминать.
>>Конвертирование этих индексов в итераторы - опять же, механическая работа
Мне кажется, или это можно сделать один раз, а потом работать только с итераторами? Исходя из моего скромного опыта, код, основанный на использовании итераторов несколько более громоздкий, но... более красивый, что ли?
Ну просто Степанов хорошо подумал и нашёл универсальный интерфейс, разделил "перпендикулярные" сущности - последовательности и алгоритмы над ними, единственность представления последовательности в виде пары итераторов позволяет композицию алгоритмов большим числом способов. Если тебе уж очень нужно - напиши свой шаблон, делов на 5 секунд. Поганить хорошую концепцию тонной оверлодов - глупо.
Да так, быстрее, но я делал акцент на вычислении в одну строку)
Тёмная сторона такая тёмная...
И я просто хотел показать еще вариант. Ну т.е. в дополнение к вашему. :)
эта жа задача во всех возможных вариациях) Даже брейнфак есть)
А тут как раз бы char* всех зарешал, особенно с авторским change_word. Без богомерзких копирований строки, без богомерзких length.
Ну где еще Царствуют? :)
Это как раз с++, с char* да, все было бы даже проще. Хотя, моя цель более менее освоить STL, а там объекты нада юзать.
Я сначала подумал, что в change_word какая-то тяжёлая наркомания (цикломания) - какие-то переменные, условия... Но котом понял, что если оставлять один цикл, переменная нужна, а на два может и компилятор разделит, оптимизируя, и уберёт лишнее.
А в руби нет какого-нибудь each у строки, чтобы не городить этот .length.times?
спешу просто
Что бы строку возвращал, а не массив
А в руби все подряд мутабельное и по ссылке передается? Даже строки, даже числа, даже аллах?
Лично мне сам руби показался сильно путанным,хотя кому как.
Язык для диабетиков ;)
! - метод меняет обьект. ? - предикат. очень удобно, кстати. Только непривычно, что методы не в CamelCase именуются
fixed