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

С недавнего(к своему стыду) времени начал интересоваться 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>А с указателями вопрос синхронизации не возникнет?
> Опять же, зависит от использования.
Понятно.

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

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

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

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

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

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


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

Если руки кривые, то никакой stl не поможет...

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


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

Оч. зависит от того, что за код. У тебя, например, может быть автоматический буфер, в котором ты работаешь...

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

DA>Осталось узнать, будет ли у ТС конструирование строк.

Как ты себе представляешь использование st::string без их конструирования?

DA>>Осталось узнать, будет ли у ТС конструирование строк.

E>Как ты себе представляешь использование st::string без их конструирования?
Никак
Вопрос в том, как часто и сколько.

Как ты себе представляешь использование char* — без конструирования?
Божьим проведением они аллоцируются?
Или всё настолько просто, что можно всё сделать в compile-time?
Так и со стрингами тогда не вижу особых проблем.
const string& — не очень-то большой оверхед даст.

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


DA>Как ты себе представляешь использование char* — без конструирования?
Например, с буффере на стеке

Автор: Erop
Дата: 27.02.07

...

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

string позволяет преобразовывать себя в char*. да и на низком уровне можно просто взять &s[0] и работать с ним, если прямо сильно зачешется. но я не думаю, что проблема вообще будет в этом

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

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

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


Попахивает преждевременной оптимизацией.....

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

DA>Как ты себе представляешь использование char* — без конструирования?
DA>Божьим проведением они аллоцируются?

Нередко память под строки уже выделена, например в (другой) string, и нужно получить подстроку. Если подстрока будет не string, а char*, дополнительного выделения памяти можно избежать.

On 12.12.2012 20:42, Erop wrote:

> V>А с указателями вопрос синхронизации не возникнет?
И ты туда же. Т.е. вопроса синхронизации у тебя тоже не возникает?
То-бишь, как я понимаю, по ответам, большинство на вопросы синхронизации
уже давно забили. Написали указатель, выдели память и пишут и читают
туда и оттуда из разных потоков кто во что горазд???

On 13.12.2012 14:06, igna wrote:

> Нередко память под строки уже выделена, например в (другой) string, и
> нужно получить подстроку. Если подстрока будет не string, а char*,
> дополнительного выделения памяти можно избежать.
Как мы рады, что ты до этого додумался. Но можешь подумать еще чуть-чуть
и написать класс-оболочку, который будет работать с такими указателями.

On 12.12.2012 20:38, Erop wrote:

> Если руки кривые, то никакой stl не поможет...
Если руки кривые, то ничего не поможет, кроме хирурга.

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

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

Часто каждый поток работает толкьо со своими данными...
Особенно, если это сроки

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

V>Как мы рады, что ты до этого додумался. Но можешь подумать еще чуть-чуть
V>и написать класс-оболочку, который будет работать с такими указателями.

1) Не хами, быдлом будешь.
2) Уже написал же здесь

Автор: igna
Дата: 12.12.12

.

On 13.12.2012 18:11, Erop wrote:

> Часто каждый поток работает толкьо со своими данными...
> Особенно, если это сроки
И в чем разница здесь между std::string и char*? Ну кроме того, что с
голым указателем могут память не освободить, освободить несколько раз
или освободить не тем.
Типичный код, который я не раз видет
...x = new...
free(x)

On 13.12.2012 18:16, igna wrote:

> 1) Не хами
Извини разозлили. Буйные фантазии и споры с ними самих же фантазеров
иногда напрягают. Хочется все-таки видеть побольше конструктива на этом
форуме.

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

>> Часто каждый поток работает толкьо со своими данными...
>> Особенно, если это сроки
V>И в чем разница здесь между std::string и char*? Ну кроме того, что с

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

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

>> Часто каждый поток работает толкьо со своими данными...
>> Особенно, если это сроки
V>И в чем разница здесь между std::string и char*?

Поправте меня если я ошибаюсь, но теоретически, две строки типа std::string могут внутри себя хранить указатель на одну и ту же память до момента изменения одной из этих строк, так что если передать одну из строк в другой поток, то возможна коллизия, которую не так-то просто заметить.

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


V>Типичный код, который я не раз видет
V>...x = new...
V>free(x)

В new и free сидит синхронизация, которая, возможно, занафиг не нужна....

Я, в целом, всё уже сказал, но ты не хочешь слышать.
Впрочем ты и не ТС, тебе и не надо, ты просто так споришь, IMHO...

Здравствуйте, asmerdev, Вы писали:
A> Не будет снижения производительности? Вопрос актуальный, потому что будет работать 1000+ потоков.
Это гораздо скорее будет причиной снижения производительности.

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

Вопрос актуальный, потому что будет работать 1000+ потоков.

это что же за железо там, что позволяет эффективно это все переключать?

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

__>string позволяет преобразовывать себя в char*.
Вы хотели сказать "в const char*" ?
__>да и на низком уровне можно просто взять &s[0] и работать с ним
разве std::string гарантирует непрерывную последовательность символов?

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

BFE>Поправте меня если я ошибаюсь, но теоретически, две строки типа std::string могут внутри себя хранить указатель на одну и ту же память до момента изменения одной из этих строк

1) подход COW показал свою несостоятельность и был реализован лишь в древних версиях gcc (ну я только об этом в курсе)
2) новый стандарт гарантирует базовые гарантии при многопоточном использовании, а именно, если есть два объекта, то их можно использовать (читать\менять) в разных потоках без проблем
3) новый стандарт также накладывает доп. ограничения (по сложности некоторых методов) на std::string таким образом, что COW и еще какие-то "ленивые" реализации никак не применимы

RW>Вопрос актуальный, потому что будет работать 1000+ потоков.

RW>это что же за железо там, что позволяет эффективно это все переключать?

А чё, 64 проца по 8 ядер — уже половина потоков будет реально параллельно работать.
Такие системы давно уже не редкость, даже тестовые.

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

RW>>это что же за железо там, что позволяет эффективно это все переключать?

DA>А чё, 64 проца по 8 ядер — уже половина потоков будет реально параллельно работать.
DA>Такие системы давно уже не редкость, даже тестовые.


да не то что удивило, просто что именно требует такого количества

On 14.12.2012 1:06, Erop wrote:

> Впрочем ты и не ТС, тебе и не надо, ты просто так споришь, IMHO...
В этом ты прав. Скучно мне, вот и развлекаюсь. ТС же ответили уже много раз.

Здравствуйте, Abyx, Вы писали:
__>>да и на низком уровне можно просто взять &s[0] и работать с ним
A>разве std::string гарантирует непрерывную последовательность символов?
не гарантирует, но по факту все реализации имеют

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

__>не гарантирует, но по факту все реализации имеют

свежий стандарт гарантирует

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

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

Я видел проект с велосипедным strdup (который везде фигачился), реализованным как член класса

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

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

A>То есть если строка, к примеру, константа — стоит ее упаковывать в string?
Да, если предполагается брать от неё подстроку или сравнивать с чем-то, или искать в ней что-то — в общем то, что есть в std::string.

A>Не будет снижения производительности? Вопрос актуальный, потому что будет работать 1000+ потоков.
Если это константа, то объект будет создан всего один раз, если только не делать от него копии.
Также в некоторых версиях STL есть константные строки (одну из реализаций которых гугл предлагает для следующей версии C++).
Если не стоит вопрос о кроссплатформенности (или кросс-библиотечности), то можно использовать их. Если стоит — тогда написать/вписать свой аналог.

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

EP>Я видел проект с велосипедным strdup (который везде фигачился), реализованным как член класса

а что в этом плохого ? если он реализован как статическая функция... то это всего лишь неймспейс для функций работающих со стороками... в .NET вообще все так зафигачено... и я бы не сказал что неудобно...

да и вообще это такой бред парится стоит ли юзать std::string или взять ли char * руководствуясь перформансом... нужно использовать что удобно... интересно на какой ренальной программе std::string привел к тормозам и его пришлось заменить на char * ... что то кажется мне это бабушкины сказки...

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

EP>>Я видел проект с велосипедным strdup (который везде фигачился), реализованным как член класса
J>а что в этом плохого ? если он реализован как статическая функция...

нет, не статическая

J>то это всего лишь неймспейс для функций работающих со стороками...

1. Для работы со строками, в том классе был только strdup.
2. Зачем использовать класс "типа как" namespace, когда есть namespace?

J>в .NET вообще все так зафигачено... и я бы не сказал что неудобно...

То что non-member functions не завезли в C# или Java — не означает что их не нужно использовать в C++

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

A>разве std::string гарантирует непрерывную последовательность символов?

Забей уже на С++03 и более ранние, пользуйся С++11, в котором это гарантируется.

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

J>>то это всего лишь неймспейс для функций работающих со стороками...

EP>1. Для работы со строками, в том классе был только strdup.
EP>2. Зачем использовать класс "типа как" namespace, когда есть namespace?

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

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

J>>>то это всего лишь неймспейс для функций работающих со стороками...
EP>>1. Для работы со строками, в том классе был только strdup.
EP>>2. Зачем использовать класс "типа как" namespace, когда есть namespace?
J>ну неймспейс это более общее понятие чем класс



J>все же поэтому логично мне кажется не вытаскивать функции для строк в неймспейс а сделать их статическими функциями строкового класса...

Простой пример: есть такой шаблон класса std::complex.

std::complex<double> c(0.0,0.0);

Как минимум, что удобней:

std::cout << cos(c);

или

std::cout << std::complex<double>::cos(c);

или вообще

std::cout << c.cos();

?

J>по вашему выходит помимо строкового класса который мне уже дает закрытый неймспейс для статическихз функций для строк мне надо завести еще и неймспейс для остальных функций для строк ? или вытащить их в какой то общий неймспейс ?

Non-member функции связанные с классом, по возможности, должны быть в namespace с этим классом — ибо ADL.
Это на каждом заборе написано

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

EP>2. Зачем использовать класс "типа как" namespace, когда есть namespace?

Например, потому, что в С++ нет параметризованных пространств имён, и нет вложенных в классы, кстати...

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

EP>Простой пример: есть такой шаблон класса std::complex.
EP>

EP>std::complex<double> c(0.0,0.0);
EP>

EP>Как минимум, что удобней:
EP>

EP>std::cout << cos(c);
EP>

EP>или
EP>

EP>std::cout << std::complex<double>::cos(c);
EP>

EP>или вообще
EP>

EP>std::cout << c.cos();
EP>

EP>?

ну да для шаблонных классов геморно согласен

EP>Non-member функции связанные с классом, по возможности, должны быть в namespace с этим классом — ибо ADL.
EP>Это на каждом заборе написано

надо запомнить...

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

EP>>2. Зачем использовать класс "типа как" namespace, когда есть namespace?
E>Например, потому, что в С++ нет параметризованных пространств имён, и нет вложенных в классы, кстати...

Я про ситуации, в которых использование namespace возможно технически.

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

J>ну да для шаблонных классов геморно согласен

Ну был бы он не шаблонным:

math::dcomplex value(0.0,0.0);

Что удобней

std::cout << cos(value);

или

std::cout << math::dcomplex::cos(value);

?

И что важнее, при использовании non-member functions вместо статических (да и вместо не статических тоже) — есть синтаксическое единообразие.
value может быть как double, так и dcomplex, синтаксис не меняется: cos(value) , а значит можно легко писать шаблонный код.
Яркий пример — .begin() и .end() в STL контейнерах — к обычному массиву .begin() и .end() не переделаешь, зато можно non-member function.
В итоге в C++11 появились std::begin(..) и std::end(..), которые работают как с "контейнерами" так и с массивами.

EP>>Non-member функции связанные с классом, по возможности, должны быть в namespace с этим классом — ибо ADL.
EP>>Это на каждом заборе написано
J>надо запомнить...

Я серьёзно, про приоритет non-member функций говорят Степанов, Страуструп, Александреску, Саттер, Майерс.

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

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

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

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

Вы как то кидаетесь из крайности в крайность. Если микрооптимизации это зло то это не значит что мы сейчас начнём писать как попало а потом пригонять толстые тулзы и всё мерить.

Очевидно что в местах где преобразования строки из const char* в string можно избежать — лучше избежать. Поэтому к примеру у нас интерфейсы часто дублируются: для const string& и для const char* — как раз по ситуации топикстартера.

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

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

RW>Вопрос актуальный, потому что будет работать 1000+ потоков.

Да кстате, по поводу 1000 потоков: в строках проседание перформанца всегда упирается в memory allocator. Надеюсь ваш аллокатор истинно многопоточный, не один на всех с центральным локом (как стандартный malloc)?

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

J>Очевидно что в местах где преобразования строки из const char* в string можно избежать — лучше избежать. Поэтому к примеру у нас интерфейсы часто дублируются: для const string& и для const char* — как раз по ситуации топикстартера.

Вообще-то этого недостаточно, дублировать нужно для 1) const Range& с range_value char и для 2) const char*. Ну или по крайней мере для 1) const string&, 2) const char* и для 3) const char* с дополнительным аргументом задающим длину строки.

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

EP>Ну был бы он не шаблонным:
EP>

EP>math::dcomplex value(0.0,0.0);
EP>

EP>Что удобней
EP>

EP>std::cout << cos(value);
EP>

EP>или
EP>

EP>std::cout << math::dcomplex::cos(value);
EP>

EP>?

ну math::dcomplex::cos как то логичней меньше конфликтов возможных...

EP>И что важнее, при использовании non-member functions вместо статических (да и вместо не статических тоже) — есть синтаксическое единообразие.
EP>value может быть как double, так и dcomplex, синтаксис не меняется: cos(value) , а значит можно легко писать шаблонный код.
EP>Яркий пример — .begin() и .end() в STL контейнерах — к обычному массиву .begin() и .end() не переделаешь, зато можно non-member function.
EP>В итоге в C++11 появились std::begin(..) и std::end(..), которые работают как с "контейнерами" так и с массивами.


ничего не понял ..)))


EP>Я серьёзно, про приоритет non-member функций говорят Степанов, Страуструп, Александреску, Саттер, Майерс.

увы и ах читаю в последнее время мало...

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

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

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

Посмотрите, например, класс String с CodeProject, который сделан в дополнение к CString и std::string.
Фишка в том, что он бинарно совместим с wchar_t*, т.е. его можно передавать в WinAPI-функции. При этом это нормальная строка с динамически выделяемой памятью и кучей встроенных ф-ций.

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

J>да и вообще это такой бред парится стоит ли юзать std::string или взять ли char * руководствуясь перформансом... нужно использовать что удобно... интересно на какой ренальной программе std::string привел к тормозам и его пришлось заменить на char * ... что то кажется мне это бабушкины сказки...

Я работаю в основном с текстом и наблюдал увеличение времени работы (конкретного места) программы в десытки раз при замене char[N] на std::string при определении локальной переменной. А если не с текстом, а к примеру "автоматизировать бухгалтерию", то возможно и сказки.

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

I>Я работаю в основном с текстом и наблюдал увеличение времени работы (конкретного места) программы в десытки раз при замене char[N] на std::string при определении локальной переменной. А если не с текстом, а к примеру "автоматизировать бухгалтерию", то возможно и сказки.

возможно но это программа должна только текст обрабатывать что бы заметить разницу а для обычного софта 96.99% разницы никакой зато сколько неудобств от char[] после комфортных string ...

я не призываю совсем отказаться от char[] но это такие костыли что стоит 10 раз подумать надо ли оно тебе
я вот вообще обленился и уже пишу на C++/CLI там вообще часто на delete можно просто забить... я от этого кайфую...

A>Вопрос актуальный, потому что будет работать 1000+ потоков.
А какой смысл в 1000+ потоков, если нету 1000+ ядер???

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

A>>Вопрос актуальный, потому что будет работать 1000+ потоков.
V>А какой смысл в 1000+ потоков, если нету 1000+ ядер???

блокирующий сетевой ввод вывод ?

Типично снижение производительности с std:(w)string по сравнению с char */wchar_t * бывает в двух случаях

1) когда потомков basic_string юзают совместно с char */wchar_t *. Надо понимать что:

void foo()
{
std::wstring str_hello_wold = "hellow world"; 
}

— это частный случай такой ситуации

2) когда передают в функции строки по значению, тогда как можно было применить константные ссылки. Бываю впрочем реализации STL, где это пофиг.

Если это учитывать, то результирующий код может даже получится быстрее того, что было с указателями — за счет отсутствия [str/wcs]len

J>блокирующий сетевой ввод вывод ?

Не нужно использовать блокирующий ввод-вывод на серверах х)

Когда я слышу про большее количество потоков или не кратное без affinity — у меня возникает стойкое желание взять топор в руки и отрубить их кому-то х) Или клещи, вырвать язык, что бы не несли ереси х)