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

L>А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

Ну strcat-то у тебя не отобрали

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

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

L>>А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

E>Ну strcat-то у тебя не отобрали

Ну-ну, попробуй strcat заюзать на Маке, я на тебя посмотрю

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

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

J>А мне вот удобно Что я делаю не так
Не знаю. Наверное мы не так что-то делаем. Ну может команда буста постепенно достигнет такого прогресса, что и мы поймём

J>Еще раз — буст ничем не отличается в этом плане от любой другой библиотеки.
ОТлиячается объемом зависимого кода. Одно дело, когда от стороненй библиотеи завист несколько классов-переходников, и совсем дургое, если зависит весь код всех проектов.

J>Я бы в таких условиях писал на чистом С.
Ты не понял. Остнованя разработка ведётся под Windows, и потом переносится под Linux и Mac OS.
Но, часто какие-то куски системы приходится переносить и на всякие экзотические платформы. Обычно мобильные или встраеваемые в какое-то устройство.
Но ИМХО такое качество кода, как "некритическая зависимоть от" исключений, сложных шаблонов, шаблонов, статических объектов и т. д. улучшает код, даже если переносит код на модильнве платформы не понадобится.
Улучшает в смысле стоимости разработки и поддержки. По нашему опыту.

J>Предлагаешь вернуться к тому нашему долгому обсуждению STL-way?
Нет, просто сам хочу понять что же не так в STL. Видимо система ценностей.
А абстрагировать алгоритмы -- так кто же против? Только абстрагировать надо очень мало алгоритмов. Ну типа на большой проект может процент наберётся кода, который абстрагированными алгоритмами стоит сделать. И просто в рамках шаблонов C++ можно абстрагировать. STL для этого ненужен. Для этого нужен высококвалифицированный специалист...

E>>Ну я же писал -- регишь критические ресурсы в запросе. При откате запроса их по списочку освобождаешь...
J>Тогда непонятно, причем тут твои рассуждения про аллокатор, когда тебе нужен типизированный (скорее всего) контейнер.
Не понял. Какой такой контейнер и зачем?
А ллокатор нужен для того, чтобы о памяти не парится, в случае если освобождение дорогое или если нет исключений.

J>>>

---

E>>А что, от принятия стандарта C++ изменится аппаратура? Или, может быть, ОС?
J>нет, появятся гарантии, что если ты написал какое-то выражение, то оно выполнится именно так, как ты написал, и ты сможешь это гарантировать безо всяких шаманских плясок, коими радует нас remark (я имею в виду его пост про double lock).

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

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

J>Так потому что на каждую задачу требуется свое решение.
J>Хотя, конечно, есть некоторые тормозные, но безотказные вещи (мьютексы), которые, как самое простое для понимания, вцементированы в некоторые языки в виде слов типа synchronized. Чем не единообразное решение
Ну вот в том-то и дело, что не стандарта нет, а универсального решения

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

RO>«Ну чесне слово — як діти». this->ptr = this->next->ptr; oldNext = this->next; this->next = this->next->next; delete oldNext. Заборы расставить по вкусу.

Угу.
1) Удалил не того
2) delete oldNext-то за что?

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

E> Конечно в конце концов её можно завернуть в шаблон класса и выставить наружу два итератора. Такой и сякой. И мы получим итераторы к тем же данным. То есть, ИМХО, эквивалентное решение. Если тебе удобно мыслить на языке итераторов, то оно тебе будет органично, а если на языке массивов, то нет. На этом различия заканчиваются...

Вот, золотые слова!
Я, собственно, о том же самом толкую всю дорогу.
Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.

RO>>Заметь, что этот подход позволяет выбирать разные контейнеры для разных задач, и для него автоматически становятся доступны все STL-way-алгоритмы.
E>Заметь, что в качестве примера "реальной задачи" ты привёл очень абстрактную математическую конструкцию. Да ещё и неудачно, ИМХО, реализованную (я бы хотел проверки отсутствия повторов в исходных последовательностях в _DEBUG версии программы)

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

E>маркер конца тягать за собой надо всё время.
Либо воспользоваться boost::range.
Причем есть соответствующее предложение по стандартизации оного:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2245.html
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2243.html

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

L>>А так — получается что либо мне нужно писать кучу кода каждый раз когда нужно слить 2 строки вместе — либо писАть свой велосипед.

E>Ну strcat-то у тебя не отобрали
strcat — это не обьединение строк. Мне ещё нужно посчитать длинну результирующей строки, выделить память, скопировать исходную строку в эту память, потом собственно strcat (в Symbian принято HBufC->Des().Append()), потом ещё не забыть поочищать буфера если нужно. Неслабо для операции которая встречается сплошь и рядом?

На самом деле вот примерный код:

HBufC* ConcatenateStringsLC(const TDesC& s1, const TDesC& s2) 
    {
    HBufC* ret = HBufC::NewLC(s1.Length() + s2.Length());
    ret->Des().Append(s1);
    ret->Des().Append(s2);
    return ret;
    }

// Пример использования функции:
_LIT(KStr1, "str1");
_LIT(KStr2, "str2");

HBufC* res = ConcatenateStringsLC(KStr1, KStr2);

// Делаем что-то со строкой.

CleanupStack::PopAndDestroy(); // Не забыть!!! Иначе - крэш. А если владение строкой мы куда-то отдали - то нужно вызывать не CleanupStack::PopAndDestroy а просто CleanupStack::Pop

Ну как — удобно выглядит?

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

J>Вот, золотые слова!
J>Я, собственно, о том же самом толкую всю дорогу.
J>Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
J>Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.
Ну вот я же всю дорогу толкую что бесплатных фич не бывает. ИМХО эта возможность ненужная, но дорогая.

J>Спорно. Это может привести к тому, что у тебя программа под дебагом будет работать месяц.
J>Скажем, если ты хочешь навесить обязательную проверку отсортированности контейнера для какого-нть binary_search, который у тебя зовется миллион раз за время работы программы.
Обрати внимание, что сортированность тут таки проверяется...
Мало того, сам этот алгоритм O( src1.Size() + src2.Size() ), и проверки сортированности и отсутсвия повторов той же сложности. Мало того проверка отсутвия повторов и проверка сортированности отличается только опреатором сравнения...

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

J>Ну-ну, попробуй strcat заюзать на Маке, я на тебя посмотрю
А в чём проблема? В паскалевских строчках? Ну так никто тебя не заставляет для "единственной в программе операции над строками" использовать паскалевские строчки

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

L>strcat — это не обьединение строк. Мне ещё нужно посчитать длинну результирующей строки, выделить память, скопировать исходную строку в эту память, потом собственно strcat (в Symbian принято HBufC->Des().Append()), потом ещё не забыть поочищать буфера если нужно. Неслабо для операции которая встречается сплошь и рядом?

Ну ты уж определись. Толи у тебя "одно объединение строк при старте программы", толи "частая операция"


L>Ну как — удобно выглядит?

Ну вполне себе pure C style библиотека. Скорее всего такую модель работы с данными родили ещё до С++.
В принципе ничто не мешате обернуть эти строчки "умными строчками", которые правильно занимаются владением, Detach там метод, Release в деструкторе и т. п., над которыми можно навернуть операторы и т. д.

Скорее всего такая библиотека вообще уже есть

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

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

J>>Вот, золотые слова!
J>>Я, собственно, о том же самом толкую всю дорогу.
J>>Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
J>>Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.
E>Ну вот я же всю дорогу толкую что бесплатных фич не бывает. ИМХО эта возможность ненужная, но дорогая.
имхо, если нечто висит в интерфейсе, но не используется, то это и есть бесплатно.
Более того, даже если фича и не бесплатная, согласись, это совсем не означает, что она дорогая.
Если у тебя итераторы могет сравниваться — дело пяти минут предоставить соответствующий интерфейс.
Даже если и не умеют, вообще говоря — тоже дело пяти минут, посмотри, как сделан, скажем, istream_iterator


E>Обрати внимание, что сортированность тут таки проверяется...
Я Пастернака не читал
Но если это и так делается — это да, можно и вставить ассерт.

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

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

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

J>>Ну-ну, попробуй strcat заюзать на Маке, я на тебя посмотрю
E>А в чём проблема? В паскалевских строчках? Ну так никто тебя не заставляет для "единственной в программе операции над строками" использовать паскалевские строчки

В них, в родимых
Я, наверное, пропустил про "единственную операцию". Да не суть.
Суть в том, что паскалевские строчки элементарно оборачиваются в basic_string, поскольку она не хранит внутри себя сишную строку, а хранит именно размер.
Стало быть, ты можешь взять прогу, которую ты написал для нормальной оси, в которой сишные строки везде (а написал ты ее на STL), и изменил только то место, где ты эти строчки рожаешь (а это место тебе и так придется менять, поскольку там идет общение с непереносимым местным API).

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

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

J>имхо, если нечто висит в интерфейсе, но не используется, то это и есть бесплатно.
Ну вот в этом и сеть наше разногласие. И с тобой и с командой буста
У меня к тебе просьба, когда ты таки поймёшь, что бесплатных фич не бывает, то напиши мне про это?

E>>Обрати внимание, что сортированность тут таки проверяется...
J>Я Пастернака не читал
Ну я вот просмотрел приведённый тобой код...
J>Но если это и так делается — это да, можно и вставить ассерт.
Там не assert, а какая-то другая конструёвина...

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

J>>имхо, если нечто висит в интерфейсе, но не используется, то это и есть бесплатно.
E>Ну вот в этом и сеть наше разногласие. И с тобой и с командой буста
E>У меня к тебе просьба, когда ты таки поймёшь, что бесплатных фич не бывает, то напиши мне про это?
У меня к тебе аналогичная по поводу стоимости использования стандартных и самописных решений

E>Ну я вот просмотрел приведённый тобой код...
Не мной
Или ты какой-то другой код имеешь в виду?

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

E>Ну ты уж определись. Толи у тебя "одно объединение строк при старте программы", толи "частая операция"
Никакого противоречия тут нет. Обьединение строк часто встречается в тексте программы. Но реально весь код обьединения всех строк работает 1% времени работы программы.

L>>Ну как — удобно выглядит?
E>Ну вполне себе pure C style библиотека. Скорее всего такую модель работы с данными родили ещё до С++.
Ничего подобного. Symbian изначально был писАн на С++. pure C там никогда не использовался.

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

_LIT(KStr1, "str1");
_LIT(KStr2, "str2");
auto_ptr<HBufC> str;
AppendStr(str, KStr1);
AppendStr(str, KStr2);

// Тут используем str

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

E>Скорее всего такая библиотека вообще уже есть
Нету По крайней мере я не находил ничего такого. У Симбиана вообще всё плохо с нормальными библиотеками — очень мало кто хочет с ним связываться.

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

E>>Ну я вот просмотрел приведённый тобой код...
J>Не мной
Упс!
Да, это был Roman Odaisky

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

L>

L>auto_ptr<HBufC> str;
L>

auto_ptr тут нехорошо, так как надо ещё Pop где-то делать!!!

L>...архитектор этой системы абсолютно зря получает свою архитекторскую зарплату.
L>Нету По крайней мере я не находил ничего такого. У Симбиана вообще всё плохо с нормальными библиотеками — очень мало кто хочет с ним связываться.

Странно. Вообще-то вроде бы популярная платформа...

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

E>0) .... А вот если в исходных последовательностях есть повторы, то поведение неопределено. Наверное предполагается, что в исходных последовательностях повторов нет, но это от чего-то не проверяется
Почему не определено?

Конечно, из 25.3.5.2 это напрямую не следует, но к примеру в MSDN.

When there are equivalent elements in both source ranges, the elements in the first range precede the elements from the second source range in the destination range. If the source ranges contain duplicates of an element, then the destination range will contain the maximum number of those elements that occur in both source ranges.

Судя по-всему эта функция работает так же.

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

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

E>>0) .... А вот если в исходных последовательностях есть повторы, то поведение неопределено. Наверное предполагается, что в исходных последовательностях повторов нет, но это от чего-то не проверяется
S>Почему не определено?

S>Конечно, из 25.3.5.2 это напрямую не следует, но к примеру в MSDN.
Зато явно следует из 25.3.5

[lib.alg.set.operations] 25.3.5 Set operations on sorted structures
This section defines all the basic set operations on sorted structures. They also work with multisets
(23.3.4) containing multiple copies of equivalent elements. The semantics of the set operations are general-
ized to multisets in a standard way by defining union() to contain the maximum number of occur-
rences of every element,intersection()to contain the minimum, and so on.

L>>

L>>auto_ptr<HBufC> str;
L>>

E>auto_ptr тут нехорошо, так как надо ещё Pop где-то делать!!!
auto_ptr тут самописный. Он сам Pop и делает.

E>Странно. Вообще-то вроде бы популярная платформа...
Это она среди пользователей популярная.

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

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

J>>Вот, золотые слова!
J>>Я, собственно, о том же самом толкую всю дорогу.
J>>Но, помимо эквивалентности, ты предоставляешь _стандартный_ интерфейс к своим контейнерам.
J>>Стало быть, все, что написано в расчете на этот стандартный интерфейс (включая стандартную библиотеку), заработает с твоими контейнерами автоматически.
E>Ну вот я же всю дорогу толкую что бесплатных фич не бывает. ИМХО эта возможность ненужная, но дорогая.

J>>Спорно. Это может привести к тому, что у тебя программа под дебагом будет работать месяц.
J>>Скажем, если ты хочешь навесить обязательную проверку отсортированности контейнера для какого-нть binary_search, который у тебя зовется миллион раз за время работы программы.
E>Обрати внимание, что сортированность тут таки проверяется...
E>Мало того, сам этот алгоритм O( src1.Size() + src2.Size() ), и проверки сортированности и отсутсвия повторов той же сложности. Мало того проверка отсутвия повторов и проверка сортированности отличается только опреатором сравнения...
Алгоритм set_union не требует отсутствия повторов. (т.е. работает на multi_set)