Приветствую, коллеги.

С недавнего(к своему стыду) времени начал интересоваться STL. До этого делал свои "велосипеды". Начал делать новый проект и тут же возник вопрос: стоит ли везде применять string? То есть если строка, к примеру, константа — стоит ее упаковывать в string? Не будет снижения производительности? Вопрос актуальный, потому что будет работать 1000+ потоков.

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

A>Не будет снижения производительности?

Сначала напиши как проще и понятней, потом выясни где тормозит. овер 9000 шанс что это будут не строки.

Здравствуйте, Brutalix, Вы писали:
B>Сначала напиши как проще и понятней, потом выясни где тормозит. овер 9000 шанс что это будут не строки.

Это понятно. Однако интересует сам вопрос как таковой. Зачем тратить время на ненужные операции.

A> Это понятно. Однако интересует сам вопрос как таковой. Зачем тратить время на ненужные операции.
Есть основания полагать, что синхронизация доступа между 1000+ потоков будет меньше влиять, чем представление строк?
Нужно знать, как минимум:
— строки изменяемые или нет
— количество строк
— средний размер строки
— количество читателей/писателей в эти строки

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

A>Приветствую, коллеги.

A>С недавнего(к своему стыду) времени начал интересоваться STL. До этого делал свои "велосипеды". Начал делать новый проект и тут же возник вопрос: стоит ли везде применять string? То есть если строка, к примеру, константа — стоит ее упаковывать в string? Не будет снижения производительности? Вопрос актуальный, потому что будет работать 1000+ потоков.

Ты хочешь сказать, что среди твоих велосипедов не было класса строки? И как ты все, strdup/strcat фигачил?

You will always get what you always got
  If you always do  what you always did

On 12.12.2012 13:42, asmerdev wrote:

> Начал делать новый проект и тут же возник
> вопрос: стоит ли везде применять string?
Не стоит. Надо смотреть по ситуации.

> То есть если строка, к примеру,
> константа — стоит ее упаковывать в string?
Не стоит. Надо смотреть по ситуации.

> Не будет снижения
> производительности?
Все зависит от тебя. Можно и с указателями все хорошо написать, можно и
со стрингами.

On 12.12.2012 13:51, Brutalix wrote:

> Сначала напиши как проще и понятней, потом выясни где тормозит. овер
> 9000 шанс что это будут не строки.
Ты самонадеян. А я один раз такой именно код и наблюдал — было ощущение,
что чел специально код замедлил в 100 раз, когда ему сказали, чтобы на
"голых" указателях код не писал.

P.S. Да, чел был не индус, а русский.

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

A>стоит ли везде применять string?

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

#pragma once

#include <algorithm>
#include <cstddef>
#include <functional>
#include <stdexcept>
#include <string>

class string_view {
public:
    // types:
    typedef std::char_traits<char> traits_type;
    typedef traits_type::char_type value_type;
    typedef std::size_t size_type;
    typedef value_type const& const_reference;
    typedef value_type const* const_iterator;

    static size_type const npos = static_cast<size_type>(-1);

    // construct:
    string_view()
    {}

    string_view(const_iterator const first, const_iterator const last)
        : first_ (first), last_ (last)
    {}

    // iterators:
    const_iterator begin() const
    {
        return first_;
    }

    const_iterator end() const
    {
        return last_;
    }

    // capacity:
    size_type size() const
    {
        return last_ - first_;
    }

    // element access:
    const_reference operator[](size_type const pos) const
    {
        using namespace std;
        if (pos < size())
            return *(first_ + pos);
        else
            throw out_of_range("string_view::operator[] const: out_of_range");
    }

    // modifiers:
    string_view& assign(const_iterator const first, const_iterator const last)
    {
        first_ = first;
        last_ = last;
        return *this;
    }

    // string operations:
    size_type find(value_type const c, size_type const pos = 0) const
    {
        using namespace std;
        if (pos < size()) {
            const_iterator const p (find_if(begin() + pos, end(), is_char(c)));
            return end() != p ? p - begin() : npos;
        }
        else
            return npos;
    }

    size_type find_first_not_of(value_type const c, size_type const pos = 0) const
    {
        using namespace std;
        if (pos < size()) {
            const_iterator const p (find_if(begin() + pos, end(), not1(is_char(c))));
            return end() != p ? p - begin() : npos;
        }
        else
            return npos;
    }

    string_view substr(size_type const pos = 0, size_type const n = npos) const
    {
        using namespace std;
        if (pos < size()) {
            const_iterator const first (begin() + pos);
            return string_view(first, npos == n || pos + n >= size() ? end() : first + n);
        }
        else
            throw out_of_range("string_view::substr: out_of_range");
    }

    int compare(string_view const& sv) const
    {
        using namespace std;
        int const result (traits_type::compare(begin(), sv.begin(), min(size(), sv.size())));
        return result != 0 ? result : size() - sv.size();
    }

private:
    class is_char : public std::unary_function<value_type, bool> {
    public:
        explicit is_char(value_type const c)
            : c_ (c)
        {}
        bool operator()(value_type const c) const
        {
            return traits_type::eq(c, c_);
        }
    private:
        is_char& operator=(is_char const&);
        value_type const c_;
    };

    const_iterator first_, last_;
};

// non-member functions:
inline bool operator<(string_view const& lhs, string_view const& rhs)
{
    return lhs.compare(rhs) < 0;
}

// conversion function:
inline std::string to_string(string_view const& sv)
{
    using namespace std;
    return string(sv.begin(), sv.end());
}

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

V>что чел специально код замедлил в 100 раз, когда ему сказали, чтобы на

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

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

A>С недавнего(к своему стыду) времени начал интересоваться STL. До этого делал свои "велосипеды". Начал делать новый проект и тут же возник вопрос: стоит ли везде применять string?

std::string к STL никакого отношения не имеет.

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

A>std::string к STL никакого отношения не имеет.

Ответ к вопросу никакого отношения не имеет.

On 12.12.2012 14:39, Brutalix wrote:

> Однако, как мне мой скромный опыт подсказывает — экономия на спичках —
> особенно в процессе написания чего-то более менее сложного как правило
> не окупается.
Конечно нет. Но у ТС был вопрос замедлится или нет. Я и привел пример,
когда замедлилась в сотни раз (правда сами string или char* были не причем).

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

A>>std::string к STL никакого отношения не имеет.

I>Ответ к вопросу никакого отношения не имеет.

ну и что? это форум, а не Q&A сайт

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

V>Конечно нет. Но у ТС был вопрос замедлится или нет. Я и привел пример,

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

On 12.12.2012 15:09, Brutalix wrote:

> стл довольно хорошо
> написан, и вполне может получится быстрее чем самописный чар*
Зависит от ручек пейсателя.

Лично я всегда по возможности использую string, но если где нельзя,
тогда char* приходится.

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

A>> Это понятно. Однако интересует сам вопрос как таковой. Зачем тратить время на ненужные операции.
DA>Есть основания полагать, что синхронизация доступа между 1000+ потоков будет меньше влиять, чем представление строк?

malloc() — очень медленная операция, даже если его зовут новомодным словом new[]

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

On 12.12.2012 15:32, Pzz wrote:

> Постоянное конструирование string'ов может дорого стоить.
То бишь для С строк память не выделяете?

> И вопрос о
> синхронизации там тоже возникнет, т.к. куча будет делиться между всеми
> потоками (даже если в ее реализации используются для ускорения
> попоточные пулы).
А с указателями вопрос синхронизации не возникнет?

Всем спасибо за ответы, кое что прояснилось. Дело в том, что у меня прямо таки маниакальная привычка делать все унифицировано. То есть если уж использовать string, то везде, чтобы везде все подходило. Поэтому и вопрос такой возник.

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

>> Постоянное конструирование string'ов может дорого стоить.
V>То бишь для С строк память не выделяете?

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

V>А с указателями вопрос синхронизации не возникнет?

Опять же, зависит от использования. А вот использование string, даже локального в потоке, с хорошей вероятностью приведет к необходимости синхронизации при обращении к куче.

On 12.12.2012 16:02, Pzz wrote:

> Ну, смотря откуда эти строки берутся. Можно ведь по-разному память
> выделять, и статически, и одним куском на совокупность данных, и т.д. и т.п.
Вот и подумай над конструированием стрингов в контексте, написанного тобой.

> V>А с указателями вопрос синхронизации не возникнет?
> Опять же, зависит от использования.
Понятно.