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

CC>будет как раз неправильным ответом
На самом деле тут есть некоторый контекст. НАсколько меня не подводит склероз, Роман считает, что вопрос про разворачивание строк надо задавать на собеседовании. И если дадут ответ не на STL, то вообще ругаться-ругаться. А если вспомнят про std::reverse, то чморрить кандидата, за то, что он понаписал тут O(n), вместо O(1)...
Правда, если бы мне предложли решение от Романа, я бы спросил: "Ну а развёрнутая строка-то где?"

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

E>Причем, если продукт не коробочный, а заказной, то он может быть даже поважнее такого критерия, как качество

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

Но безусловно есть огромный пласт ПО, которое нужно "быстро", а "медленно" не нужно просто, ни при каком уровне качества...
AFAIK для решения таких проблем нужен бэйсик, или нет, или жаба, но никак не STL, кстати. Но и в этом случае критерием качества останется то, что процесс разработки ставит поставленную задачу. Разрабатывает нужную программу в приемлемый срок и не слишком задорого...

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

Много поскипано. Спасибо за Ваш ответ, но дискуссия на эту тему, как я писал выше, мне не интересна. с++ интереснее

_>>Ладно, дальше развивать не интересно(лично мне), тк это явный оффтоп. Но Ваша позиция, мне не совсем понятна(очевидно из-за неопытности ).
E>Тебе виднее из-за чего. Мне кажется, что у меня очень простая позиция...
E>Я на всякий случай, напишу для тебя более корректную, по моему мнению версию того абзаца из сообщения
E>

У нас на фирме STL используется, но не на полную катушку. Слишком сложных конструкций всё-таки стараются избегать. Boost я пока что знаю плохо, зотя и пыьаюсь изучать. Правда этому мешает то, что у нас на фирме он запрещён к использованию. Используются, так же, и исключения, хотя известная мне версия RAII не используется. Я пока не понял как при таких условиях можно писать надёжные программы. Ну у более опытных коллег это пока получается. Буду бороться за модернизацию применяемых у нас на фирме средств разработки

Ну может я и ошибаюсь, но уверен, такой опытный человек как Вы, прекрасно понимает о чем идет речь Вот и наши коллеги ниже Вам написали, о чем идет речь. И я выше написал. Речь о том, что если один человек — это "человек проект", то я не сомневаюсь, что можно не используя auto/shared/weak ptr's и используя исключения, написать проект который успешно работает, и в нем да же нет утечек Я уверен опытный гуру, на это вполне способен. Только как только разработчиков становится несколько, и/или уходит этот разработчик, а приходит другой(ие) — то тут не получить утечку в таких условиях становится затруднительно. можно, конечно но это требует дополнительных усилий. Вы, вероятно скажете что нужны кодинг стандартс. Но из вышенаписанного легко сделать вывод, что они у нас не запрещают использование исключений(более того рекомендуют, и думаю правильно делают Но при этом, использовать RAII не только не обязывают, но да же не рекомендуют. Про него там ни слова.

E>Кстати, открой тайну, что оборзначает "RAII не используется"? Это значит, что нет умных указателей, или что нет аналога AFX::CFile / std::fstream или что?
Совершенно верно. это не запрещено, но рекомендаций использовать это- нигде нет. std::auto_ptr де факто нигде почти не используется, std:: потоки тоже. запись чтение их/в файлы производится с помощью CRT/ и/или API. никаких RAII оберток вокруг этого не делается. Надеюсь тайна открылась

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

E>Я имел в виду "программа, как коммерческий продукт"...
E>ИМХО, при коммерческом программировании это вообще единственный критерий оценки процесса разработки. ПО должно выполнять возложенные на него задачи, то есть "работать".
E>В случае коробочного софта, это обычно обозначает: выполнять нужную функциональность, быть поддерживаемым, развиваемым, и, в послдеднее время, ещё и легко переносимым на другие платформы...

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

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

E>>Причем, если продукт не коробочный, а заказной, то он может быть даже поважнее такого критерия, как качество

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

"К сожалению" я написал потому, что из знаменитой тройки "быстро, дешево, качественно" сейчас самым главным критерием, как мне кажется, является "быстро". Результатом чего является не только ухудшение качества, сколько объем работы -- "сначала быстренько делаем вот это, затем быстренько переделываем вот на это, затем еще раз быстренько вот на это..."

E>Но безусловно есть огромный пласт ПО, которое нужно "быстро", а "медленно" не нужно просто, ни при каком уровне качества...
E>AFAIK для решения таких проблем нужен бэйсик, или нет, или жаба, но никак не STL, кстати. Но и в этом случае критерием качества останется то, что процесс разработки ставит поставленную задачу. Разрабатывает нужную программу в приемлемый срок и не слишком задорого...

У меня сложилось впечатление, что русская пословица "быстро только кошки родятся" очень верна и для программирования. Так что я сомневаюсь, что на любом языке и на любой технологии качественную программу можно написать быстро. Поскольку качество зависит не столько от языка/платформы, сколько от тчательности проектирования и тестирования.

Но все это уже офтопик.

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

E>>В случае коробочного софта, это обычно обозначает: выполнять нужную функциональность, быть поддерживаемым, развиваемым, и, в послдеднее время, ещё и легко переносимым на другие платформы...

_>А как на счет поддержки ? или труд программистов выполняющих поддержку/доработку системы уже бесплатен? Ведь эти операции зачастую выполняются не "гуру разработчиками", а людьми новыми в проекте. но то же получающими зарплату

Было бы неплохо перед формулировкой ответа читать сообщения оппонента, хотя бы непосредственно то, на которое ты отвечешь...

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

_>Очень интересно мнение форумчан, насколько широко люди, программирующие на С++, используют boost & STL? Речь идет о самом широком срезе -- студенты, программисты, хобби-девелоперы...

голосование устрой, ответов и пользы больше

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

CC>>будет как раз неправильным ответом
E>На самом деле тут есть некоторый контекст. НАсколько меня не подводит склероз, Роман считает, что вопрос про разворачивание строк надо задавать на собеседовании. И если дадут ответ не на STL, то вообще ругаться-ругаться. А если вспомнят про std::reverse, то чморрить кандидата, за то, что он понаписал тут O(n), вместо O(1)...
E>Правда, если бы мне предложли решение от Романа, я бы спросил: "Ну а развёрнутая строка-то где?" :)

Так Джоэл считает. У него, впрочем, контекст тот, что собеседуемый должен сам осилить указательную/итераторную арифметику.

Наверное, я был неправ со словом «неправильный». Тот ответ тоже правильный. Просто нужно знать об обоих и выбрать нужный. Я не сотрудник отдела кадров, но мне кажется, что многие об одном или даже об обоих этих вариантах не знают.

P. S. Однажды дернул меня нечистый на Топкодере поучастовать. Там было задание — найти какое-то свойство строки, сжатой нехитрым вариантом RLE. Типа того, что a(2,a(3,ab)b)a = aaabababbaabababba. Я решил, что проще будет идти по строке с конца, поэтому передавал в функцию rbegin и rend. Оно-то было проще, но мой велосипедный конечный автомат всё время выпадал. Так я задачу и не сделал. Я потом понял, что reverse("a(bc)d") != "d(cb)a", а равняется оно "d)cb(a". Поэтому при отладке, когда я сразу вводил строку задом наперед (еще одна проблема reverse_iterator — поддержка со стороны IDE), работало, а когда я заменил begin/end на rbegin/rend, перестало. Не то, чтобы мне помогла std::reverse — для этой задачи было всё равно — это скорее свойство человеческого мышения такое, человек не компьютер.

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

_>>Кстати, почему так строку не развернуть? :) В инете этот вариант часто предлагают.

C>Так строку не развернуть, но по причинам, не имеющим почти никакого отношения к C++.

C>Проблема будет при попытке развернуть строку, содержащую многобайтный символ (который при этом вывернется наизнанку и станет невалидным). Или строку Unicode, содержащую суррогатные пары (которые тоже вывернутся наизнанку) или nonspacing диакритику в decomposed форме (которая уйдёт на соседнюю букву).

Кстати, да. Но такой проблемы не будет, если итераторы сделать правильно. Как-то так:

OctetStream utf8string;
Utf8Iterator const first = begin<Utf8>(utf8string);
Utf8Iterator const last = end<Utf8>(utf8string);

doSomething(first, last);
doSomething(std::reverse_iterator<Utf8Iterator>(last), std::reverse_iterator<Utf8Iterator>(first));

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

RO>Так Джоэл считает. У него, впрочем, контекст тот, что собеседуемый должен сам осилить указательную/итераторную арифметику.
Ну я так понял, что ты разделяешь его точку зрения?

RO>P. S....Я потом понял, что reverse("a(bc)d") != "d(cb)a", а равняется оно "d)cb(a". Поэтому при отладке, когда я сразу вводил строку задом наперед (...), работало, а когда я заменил begin/end на rbegin/rend, перестало. Не то, чтобы мне помогла std::reverse — для этой задачи было всё равно — это скорее свойство человеческого мышения такое, человек не компьютер.

Я согласен что свойство. И у него есть такое вот банальное следствие: "чем более абстрактен код, тем сложнее его писать корректно и тем труднее его отлаживать и тестировать"...
ИМХО твой пример с заменой итератора это ярко демонстрирует...
Мало того, если бы ты "отступил на один шаг" в абстрактности своего кода и не заменяд бы итераторы в отлаженном коде, а написал бы по простому std::revarse, то ты бы просто и незатейлево увидел в отладчике что происходит. И скорее всего бы отладился...

При этом всём мне кажется, что ты довольно таки квалифицированный инженер, во всяком случае "выше среднего уровня", и то у тебя происходят проблемы из-за излишней абстрактности STL-way кода...
Может хотя бы твой собственный пример тебя в чём-то убедит?

---

p. s.
Да, не приведёшь задачку? Интересно просто...

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

RO>>Так Джоэл считает. У него, впрочем, контекст тот, что собеседуемый должен сам осилить указательную/итераторную арифметику.
E>Ну я так понял, что ты разделяешь его точку зрения? :)

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

RO>>P. S....Я потом понял, что reverse("a(bc)d") != "d(cb)a", а равняется оно "d)cb(a". Поэтому при отладке, когда я сразу вводил строку задом наперед (...), работало, а когда я заменил begin/end на rbegin/rend, перестало. Не то, чтобы мне помогла std::reverse — для этой задачи было всё равно — это скорее свойство человеческого мышения такое, человек не компьютер.

E>Я согласен что свойство. И у него есть такое вот банальное следствие: "чем более абстрактен код, тем сложнее его писать корректно и тем труднее его отлаживать и тестировать"...
E>ИМХО твой пример с заменой итератора это ярко демонстрирует...
E>Мало того, если бы ты "отступил на один шаг" в абстрактности своего кода и не заменяд бы итераторы в отлаженном коде, а написал бы по простому std::revarse, то ты бы просто и незатейлево увидел в отладчике что происходит. И скорее всего бы отладился...

Есть такая проблема, но это уже проблема IDE. С тем же успехом IDE не покажет значение выражения «a + b», если оператор переопределен. Или ты о другом?

E>При этом всём мне кажется, что ты довольно таки квалифицированный инженер, во всяком случае "выше среднего уровня", и то у тебя происходят проблемы из-за излишней абстрактности STL-way кода...

В данном случае не из-за этого.

Открою великую тайну — в настоящее время я выискиваю глюки в программах, написанных на позорном PHP, а не пишу мегамногопоточные серверы реального времени на C++… :-( ;-)

E>Может хотя бы твой собственный пример тебя в чём-то убедит?

Минздрав предупреждает: злоупотребление STL и, особенно, Boost вредно для здоровья.
E>

---

p. s.
E>Да, не приведёшь задачку? Интересно просто...

http://www.topcoder.com/stat?c=problem_statement&pm=6381&rd=10881&rm=265978&cr=21981096

Посчитать количество блоков в строке, где блок — последовательность подряд идущих одинаковых букв. Букв всего две, A и B. Например, solve("(2,A(3,AB))") = solve("AABABABAABABAB") = 12.

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

RO>Есть такая проблема, но это уже проблема IDE. С тем же успехом IDE не покажет значение выражения «a + b», если оператор переопределен. Или ты о другом?

Я о том, что если бы ты использовал std::reverse, то скорее всего бы отладился, а так не отладился... Прямым тектстом вроде написал

RO>Минздрав предупреждает: злоупотребление STL и, особенно, Boost вредно для здоровья.
Угу. С этим я совершенно согласен
E>>

---

p. s.
RO>http://www.topcoder.com/stat?c=problem_statement&pm=6381&rd=10881&rm=265978&cr=21981096

RO>Посчитать количество блоков в строке, где блок — последовательность подряд идущих одинаковых букв. Букв всего две, A и B. Например, solve("(2,A(3,AB))") = solve("AABABABAABABAB") = 12.

Прикольно А зачем понадобилось разворачивать?
Кроме того, я так понимаю, что круто это решать не разжимая строку. Типа научиться считать по подстроке сколько там блоков и что на концах, потом два таких можно складывать, ну и так далее, не забыть частный случай, когда блок один, ну и так далее...

Типа

struct SubstringDesc {
    char First;
    char Last;
    int BlockCounnt;

    SubstringDesc& operator+=( const SubstringDesc& other )
    {
        BlockCount += other.BlockCount;
        if( Last == other.First )
            BlockCount--;
        Last = other.Last;
        return *this;
    }

    SubstringDesc& operator *= ( int factor )
    {
        assert( BlockCount > 0 && factor > 0 );
        int correction = Last == First ? factor - 1 : 0;
        BlockCount = BlockCount * factor - correction;
        return *this;
    }
};

Ну и теперь разбираем запакованное представление строки и накапливаем себе постепенно результат... И где тут должен появиться обратный итератор?

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

RO>Можно так:
RO>

RO>std::vector<unsigned char> buffer;
RO>buffer.reserve(54308428790203478762340052723346983453487023489987231275412390872348475);
RO>getData(std::back_inserter(buffer));

RO>std::reverse(buffer.begin(), buffer.end());

RO>process(buffer.begin(), buffer.end());
RO>

Круто! Я тоже хочу себе пятьдесят четыре довигинтиллиона триста восемь унвигинтиллионов четыреста двадцать восемь вигинтиллионов семьсот девяносто новемдециллионов двести три октодециллиона четыреста семьдесят восемь септендециллионов семьсот шестьдесят два сексдециллиона триста сорок квиндециллионов пятьдесят два кваттуордециллиона семьсот двадцать три тредециллиона триста сорок шесть дуодециллионов девятьсот восемьдесят три ундециллиона четыреста пятьдесят три дециллиона четыреста восемьдесят семь нониллионов двадцать три октиллиона четыреста восемьдесят девять септиллионов девятьсот восемьдесят семь секстиллионов двести тридцать один квинтиллион двести семьдесят пять квадриллионов четыреста двенадцать триллионов триста девяносто миллиардов восемьсот семьдесят два миллиона триста сорок восемь тысяч четыреста семьдесят пять байтов оперативы

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

C>>Проблема будет при попытке развернуть строку, содержащую многобайтный символ (который при этом вывернется наизнанку и станет невалидным). Или строку Unicode, содержащую суррогатные пары (которые тоже вывернутся наизнанку) или nonspacing диакритику в decomposed форме (которая уйдёт на соседнюю букву).

RO>Кстати, да. Но такой проблемы не будет, если итераторы сделать правильно. Как-то так:
RO>

RO>OctetStream utf8string;
RO>Utf8Iterator const first = begin<Utf8>(utf8string);
RO>Utf8Iterator const last = end<Utf8>(utf8string);

RO>doSomething(first, last);
RO>doSomething(std::reverse_iterator<Utf8Iterator>(last), std::reverse_iterator<Utf8Iterator>(first));
RO>

Да. Вот только в этом коде некий гипотетический тип Utf8 должен быть опять-таки строчкой байт либо достаточно широким символьным типом. А если добавить ещё и обработку диакритики (и соответственно типы Grapheme и GraphemeIterator), то реализация станет сложной, а оптимизация — трудной. Ни о каком произвольном доступе к графемам за O(1), конечно, не стоит и мечтать — разве что индексировать строку при первом использовании…

Кстати, в свете юникода стоит отметить ещё одну проблему со строками вообще и со строками в C++ в частности. Строки иногда очень хочется сделать ключом map’а или ещё как-нибудь отсортировать. При этом нужен предикат порядка над строками. А он — surprise! — разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению (как это предполагает std::char_traits). Кто здесь когда последний раз инстанцировал std::map<std::wstring, T, std::locale>?

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


C>Кстати, в свете юникода стоит отметить ещё одну проблему со строками вообще и со строками в C++ в частности. Строки иногда очень хочется сделать ключом map’а или ещё как-нибудь отсортировать. При этом нужен предикат порядка над строками. А он — surprise! — разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению (как это предполагает std::char_traits). Кто здесь когда последний раз инстанцировал std::map<std::wstring, T, std::locale>?

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

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

E>У меня сложилось впечатление, что русская пословица "быстро только кошки родятся" очень верна и для программирования. Так что я сомневаюсь, что на любом языке и на любой технологии качественную программу можно написать быстро. Поскольку качество зависит не столько от языка/платформы, сколько от тчательности проектирования и тестирования.

Фишка в том, что часто нужно не качественно, а быстро. Рынок такого сорта софта довольно велик AFAIK...

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

E>Фишка в том, что часто нужно не качественно, а быстро.

Вот это-то и не нравится.

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

E>>Фишка в том, что часто нужно не качественно, а быстро.
E>Вот это-то и не нравится.
Хоти и поставил +1, но... такова жизнь

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

_>Очень интересно мнение форумчан, насколько широко люди, программирующие на С++, используют boost & STL? Речь идет о самом широком срезе -- студенты, программисты, хобби-девелоперы...

Имхо: каждый C++-разработчик обязан знать STL. Равно как и определённое подмножество Boost'а.
Из STL позволительно не знать всякие mem_fun, bind1st, etc, так как это есть в Boost'е.

Насколько широко? Даже не знаю, как точно ответить на этот вопрос. Например, boost::shared_ptr употребляется в моём коде не реже, чем цикл while  Если такое сравнение вообще может служить критерием.

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

_>Дайте пожалуйста ссылку, на ресурс где это можно прочесть интересует разный для разных человеческих языков и в общем случае не сводится к поэлементному сравнению
unicode.org какой же еще может быть ресурс

А если точнее то "человеческую" сортировку делает Collation Algorithm.