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

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

Что там поддерживать?
Вот лежит себе буст, никого не парит.
Есть четкие указания, что из него можно использовать А, Б и В, остальное либо нельзя либо после предварительных консультаций.
В чем проблема-то?

E>Ну это значит "и поддерживать". Я уже не говорю о том, что если ты разрабатываешь библиотеку под линукс, то тебе надо ещё и с хостом одной версией буста пользоваться
не понял, сорри

E>>>Тут, как и везде в инженерной деятельности, нужен разумный компромис
J>>Либо правильно, либо разумный компромисс
E>Нет. В инженерной деятельности всегда и только компромисс. "Правильно" просто не бывает
Не, ты меня не понял. Ты сказал "Правильно" на директиву "код не трогать, ибо приносит деньги". Вот здесь нет ни компромисса, ни разума. Ибо если следовать этому правилу, то после первого коммерческого релиза код проекта фиксируется и все, никакого рефакторинга или чего-то подобного. Ну а остальное — твои домыслы, возникшие из этого непонимания.

E>>>Ну это обычно портит экономическую эффективность. Ну либо на самом деле всё хорошо.
J>>Экономическую эффективность программера, знаешь ли, довольно трудно подсчитать.
E>Ну одного конкретного программера да, может быть, а вот процесса разработки -- запросто. И если у людей без буста получилось экономически эффективно разработать чего-то, то таки не нужен им буст, однако
Да им вообще ничего не нужно. Напишут они все на голом С, на указателях на void, и если релиз прошел — все, экономически эффективно. А то, что потом поддержка превращается в кошмар — это уже неэффективность поддерживающей команды, а у изначальной все хорошо, релиз же прошел.

E>Мало того, я вот лично время от времени слышал от людей жалобы на то, что они де не могут вот написать, скажем, алгоритм поиска частей картинки на целой потому что не используется буст там или STL. На самом деле проблема была в том, что им не хотелось решать эту задачу, а не в инструментах.
Согласен.
E>В работе группы, продвигающей буст я ничего плохого не вижу. Мне не нравятся бескомпромиссные фанаты этой библиотеки.
Мне они тоже не нравятся.

J>>А в реальности бывает, что те, кто писал изначально, давно уволились, а из вновь пришедших никто ничего в архитектуре этой библиотеки не понимает. И вся дальнейшая разработка превращается в тупой баг-фикс и копи-пейст.
E>Ты не знаешь продуктов, которые пережили более 5 версий?
E>Может ты просто в нормальных конторах не работал?
"в реальности бывает" не означает "везде", а означает "бывает". Я описанную ситуацию наблюдал многократно, и не только в фирмах, где я работал.

E>Про то, что ты не видишь других альтернатив я поскипал, извнини, но я их просто использовал на практике
Нет уж, ты расскажи!

E>>>Обращаю внимание, что так можно восстановиться и при помощи исключения, и при помощи глобального goto...
J>>какого еще глобального goto? у тебя весь код в одной функции, что ли?
E>Обычно есть возможность прихранить состояние стека, и потом вернуться туда же, но на другую метку. Если его нет сразу (хотя обычно есть), нет проблем реализовать на асме...
О-о-о...

E>>>>>

---

E>Я тебе так скажу. Я думаю, что пстандартизация в этих вопросах не прибавит переносимости
Прибавит. Потому что в языке появятся механизмы защиты от излишней низкоуровневой активности.

E>Ну пока что на многопоточных платформах как-то обходятся
Ну да, помолясь, без каких-либо гарантий, что на следующей версии компилятора, ядра ОС и т.п. все продолжит работать

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

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

J>>Еще раз повторю — если у тебя на примете есть библиотека, достойная быть принятой в Стандарт — закинь ее в Буст, в чем проблема?

E>Я тут вот о чем подумал по дороге домой: ну вот станет boost::regex частью стандарта. Ну и все, feature freeze на ближайшие N лет. А разные Greta и PCRE продолжат развиваться и улучшаться.

Ну так и boost::regex продолжит развиваться и улучшаться, никуда не денется.

Ну а у std::regex все зафиксируется, на то он и стандарт. Издержки стандартизации, никуда ты от этого не денешься.
С тем же успехом можно было бы принять в стандарт Greta или PCRE, и тогда все эти твои слова были бы напрямую применимы и к ним.
Из чего следует, что ты вообще против понятия "стандартная библиотека"
типа пусть, как сейчас, будет огромные лес абсолютно несовместимых между собой библиотек, потому что у каждой свой интерфейс, свои контейнеры и строки и т.п.


Ну и реализации тоже открыты для развития, вон посмотри хотя бы, какой прогресс в плане реализации делает STLPort с тыщу лет назад фиксированным интерфейсом STL.

E>А на счет закидывать -- у меня на свои OpenSource проекты здоровья уже не хватает. А здесь столько гораздо более умных C++ников и бустоводов сидит и хоть бы кто, например, сделал для буста аналог RubyGems.
Ну так а bcp чем не устраивает? Или это совсем не то?
Кстати, вполне возможно, что кто-то и делает.

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

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


V>>...Если, к примеру, я поступлю к вам на работу — изучу кучу ваших велосипедов, а потом как они мне пригодятся?
E>Ну тебе всё равно много прийдётся изучит специфического для конторы и задачи. Как это тебе пригодиться? Всё-таки STL не так уж много сервисов предлагает. Ну несколько контейнеров. Ну ненужные обычно алгоритмы. Ну запомнишь ты какие у нас контейнеры и как там sort или merge звать. Ну что тут такого сложного?

Не в именах сложность, имена бог с ними. В любом случае контейнеры будут typedef-ица, ListSomeObj там ContainerSomeObj.. другое дело, что будете пользоваться разработанными концепциями. STL предлогает не только контейнеры, но хорошую поддержку этих контейнеров как в алгоритмах, так в адаптации собственных. А ты говориш sort, merge... Мне просто адцки любопытно было бы посмотреть весь ваш фреймворк, который заменяет собой хотябы тот же STL и часть буста (а не сугубо специфические библиотеки) в сравнении ними же. Вообщем.. ниже.

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

V>>Может ваш программист-идеолог уволиться, придет другой и скажет "другой велосипед!".
E>Да нет никакого программиста-идеолога. Есть много продуманных решений и большой опыт преемственности и разработок...
Всегда есть Свои лидеры есть везде.. Я вот тут подумал, а почему бы вам не разработать свой язык и не написать свой компилятор?

E>>>Ну а буст -- это вообще эксперементальная, бурно развивающаяся платформа. ИМХО от него зависеть немного страшновато...
V>>А ты прям предлогаешь либо вообще без буста, либо ВЕСЬ буст со всеми причиндалами — выжать из него все что только можно. Хотя второй вариант принесет вам дополнительные выгоды. Сказать какие? Прославитесь!
E>Ну брать библиотеки "по частям", особенно если они нифига не сегментированы на них, или писать свои -- работа, ИМХО, примерно олинаковая. Только во втором случае ты менешь зависишь от неконтролируемых факторов...
А что ты считаешь контроллируемым фактором? Как раз таки стандартные средства более контролируемый фактор. Их используют все. Поэтому они меньше подвержены флуктуациям.

Вы случайно не велосипеды выпускаете?

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

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

E>>>Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...
J>>typedef спасет отца русской демократии
C>Не спасет.

C>Во-первых, statefull-аллокаторы в STL нормально работать не будут.
Почему же не будут? Просто состояние должно быть разделено между всеми аллокаторами этого типа.

C>Во-вторых, можно нарваться на засады с методом swap(), если аллокаторы будут иметь несовпадающий тип.
Это да
C>В-третьих, в STL аллокаторы не могут возвращать умные указатели (в Стандарте гвоздями прибиты простые указатели).
И это да

C>Я в итоге свою либу написал
Разумно

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

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

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

E>>>Ну много проблем разных. Главная в том, что STL не имеет никаких средств для манипуляции аллокаторами памяти. Надо тогда везде векторы специально специфицировать, это где-то забудут...

J>>typedef спасет отца русской демократии

E>Прости, какой typedef?

typedef std::vector< int, my_allocator<int> > MyIntVector;

E>А если в программе есть объекты разных типов? В том числе и массивы таких объектов?
тогда template typedef, которого в природе пока что нет
а есть пока только такое:

template<class T>
struct MyVector
{
  typedef std::vector< T, MyAllocator<T> > type;
};

Соответственно, везде придется писать MyVector<int>::type, ничего не поделаешь
Кривизна, конечно (кто там говорил, что сахар не нужен?), но зато можно в эту структуру всякие другие вещи засунуть, к ним ко всем будет обращение через MyVector<int>. Например, MyVector<int>::iterator.

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

jazzer wrote:
> C>Во-первых, statefull-аллокаторы в STL нормально работать не будут.
> Почему же не будут? Просто состояние должно быть разделено между всеми
> аллокаторами этого типа.
Это и есть statless — у каждого конкретного аллокатора нет своего состояния.

> C>Я в итоге свою либу написал
> Разумно
Кстати, еще в аллокаторах не хватает метода realloc

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

>> C>Я в итоге свою либу написал
>> Разумно
C>Кстати, еще в аллокаторах не хватает метода realloc
У МС есть еще возможность узнать будет ли при realloc перемещение и на сколько можжно расширить без перемещения
поэтому велосипеды рулят

template<class T>
  class Vector
{  public:
   int size;     T* p;
   protected: int cap; public:
   Vector(){size=cap=0;p=0;}
   T& operator[](int i)
   {  if(unsigned(size)<=unsigned(i))
      {  __asm int 03;
      }
      return p[i]; 
   }
   Vector& set_cap(int cp) 
   {  if(cp )
        p=(T*)realloc(p,cp*sizeof(T));
      else
        free(p),p=0;
      cap=cp;
      return *this; 
   }
   Vector& grow_cap(int cp) 
   { if(cap<cp)
       set_cap(cp);
      return *this; 
   }
   Vector& set_sz(int sz) 
   { if(cap<sz)
       grow_cap(sz);
     if(size<sz)
        memset(p+size,0,sizeof(T)*(sz-size));
     size=sz; 
     return *this; 
   }
   T& operator++()
   { set_sz(size+1);      
     return p[size-1]; 
   }
   void operator--()
   { set_sz(size-1);      
     return p[size-1]; 
   }
   ~Vector()
   {  if(p)
       free(p); 
      p=0;
   }
   T& last()
   {  if(size<=0)
      {  __asm int 03;
      }
      return p[size-1]; 
   }
   void remov(int a,int n=1)
   {  int ns=size-n;
      for(;a+n<size;a++)
        p[a]=p[a+n];
      size=ns;
   }
};

и пусть ктото мне обьяснит можно ли такой код переписать на СТЛ и будет ли он при этом работать для 64 бит?

Vector<int> a,b;

int size_dif=xz?-1:+1;
if(a.size-b.size>size_dif)
 ++a=99;

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

WH>>Я вот знаю одну библиотеку написанную на С++ с шаблонами и исключениями при том имеющею Сшный интерфейс...
WH>>Прекрасно живет в so'шках и dll'ках...
E>Да? А если ты хочешь чтобы она разделяла рантайм с основным приложением. Скажем из соображений общей кучи? Это что касается DLL

Тот же boost::shared_ptr хранит указатель на ту стену, о которую должен убиться. Да и ::new/::delete можно переопределять.

E>А что касается SO, то ты просто не пробовал взять эту SO и хост, собранный с другим STL. Попробуй -- узнаешь много нового :)

А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

Programador wrote:
> C>Кстати, еще в аллокаторах не хватает метода realloc
> У МС есть еще возможность узнать будет ли при realloc перемещение и на
> сколько можжно расширить без перемещения
> поэтому велосипеды рулят
Собственно так и сделал — в своих контейнерах я указываю возможность
использования try_realloc'а в политиках.

Кстати, вместо realloc'а нужно использовать _expand — так как в общем
случае нельзя перемещать объекты копированием.

> и пусть ктото мне обьяснит можно ли такой код переписать на СТЛ и будет
> ли он при этом работать для 64 бит?
Код точно некорректный в общем случае, memset нельзя использовать для
очистки объектов.

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

>> и пусть ктото мне обьяснит можно ли такой код переписать на СТЛ и будет
>> ли он при этом работать для 64 бит?
Я про

Vector<int> a,b;

int size_dif=xz?-1:+1;
if(a.size-b.size>size_dif)
 ++a=99

У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?

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

P>Я про

P>Vector<int> a,b;
P>int size_dif=xz?-1:+1;
P>if(a.size-b.size>size_dif)
P> ++a=99
P>

P>У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?
Нормально — никак. А что ты, собственно, ожидал?

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

P>У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?

size_t s1, s2;
size_t d1 = 0, d2 = 0;

(xtozna ? d1 : d2) = 1;

if(s1 + d1 > s2 + d2)
{
    . . .
}

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

RO>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

Хм. Необязательно уж голый C то. Экспорт чисто виртуальных интерфейсов (завернутых в безопасный smart ptr) очень даже безопасен. Самое главное держать под контролем владение ресурсами и НЕ БРОСАТЬ исключений через границы модуля.

RO>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

AA>Хм. Необязательно уж голый C то. Экспорт чисто виртуальных интерфейсов (завернутых в безопасный smart ptr) очень даже безопасен. Самое главное держать под контролем владение ресурсами и НЕ БРОСАТЬ исключений через границы модуля.

Что-то то мне это до боли напоминает А, понял — COM

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

P>>У меня size знаковое. Поясню вопрос — есть знаковое адекванной длинны. Вопрос как его сравнить с a.std::container<>::size()-a.std::container<>::size() ?

RO>

RO>size_t s1, s2;
RO>size_t d1 = 0, d2 = 0;

RO>(xtozna ? d1 : d2) = 1;

RO>if(s1 + d1 > s2 + d2)
RO>{
RO>    . . .
RO>}
RO>

что тут сказать...
Аксиоматические основы математики Вы знаете. Введем отрицательные числа как фактормножество на отношении ... и т.д. выходит беззнаковых достаточно

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

RO>>>А кто экспортирует объекты C++ из динамических библиотек, тот ССЗБ. Хорошие so/dll экспортируют только обертки на C, и тогда неважно, чем компилировали внутренности.

AA>>Хм. Необязательно уж голый C то. Экспорт чисто виртуальных интерфейсов (завернутых в безопасный smart ptr) очень даже безопасен. Самое главное держать под контролем владение ресурсами и НЕ БРОСАТЬ исключений через границы модуля.

L>Что-то то мне это до боли напоминает А, понял — COM

Разумеется. vtbl — самый надежный гарант бинарной совместимости. Только функции в интерфейсах на всякий случай не стоит перегружать — ибо MSVC перегруженные функции кладет в обратном порядке в vtbl, а другие компиляторы — в прямом.

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

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


>>> S>Вообще-то есть такая фишка: http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html
>>> S>Когда я про нее не знал (а может ее тогда просто не было), то написал свой гибрид shared+intrusive ptr. У который рефкаунт болтался в памяти отдельно от основного объекта, как у shared_ptr, что позволяло делать слабые указатели, но был доступен через сам объект (а не через обертку) как у intrusive_ptr, что позволяло многократно конструировать умный указатель из указателя на объект. Здесь та же фигня, но уже в библиотеке.
>>> Да не таже фигня, нельзя слабый указатель в бусте сделать из простого указателя на объект.

S>>Можно. У weak_ptr есть конструктор, принимающий shared_ptr, shared_ptr можно получить из указателя.
P>Конечно можно, но только 1 раз Если повторить этот процесс то создастся вторая копия счётчика ссылок

"Вы просто не умеете их готовить"

#include <string>
#include <boost/shared_ptr.hpp>
#include <boost/enable_shared_from_this.hpp>
#include <iostream>

using namespace std; using namespace boost;

struct A : enable_shared_from_this<A>
{
    int q;
    A() : q(2) {}
    void foo()
    {
        q = q * q;
        cout << "A::foo " << q << endl;
    }
    ~A()
    {
        cout << "A::~A " << q << endl;
    }
};

int main(int argc, char* argv[])
{
    A *p = new A;
    shared_ptr<A> s1(p);
    weak_ptr<A> w1;
    {
        shared_ptr<A> s2(p->shared_from_this());
        weak_ptr<A> w2(s2);
        w1 = w2;
    }
    {
        shared_ptr<A> s3(w1);
        s3->foo();
    }
    s1->foo();

    return 0;
}

>>> Крометого можно не аллокировать счётчик до тех пор пока слабые не понадобятся

S>>Не нужны слабые указатели — пользуйся intrusive_ptr.
P>Просто так один тип, чтоб не думать.

Умно . Если не думать, то о необходимости слабых ссылок удастся узнать только когда программа начнет течь — и потом придется долго разбираться, что куда зациклилось.

>>> Еще засунуть enable_shared_from_this в виртуальный базовый класс и все есть, два плюса перед стандартным. Правда делитера нет, для грязных хаков

S>>Думаешь, виртуальные базовые классы бесплатные?
P>не бесплатные конечно, но иногда нужные. Можно и не виртуально наследовать если у обьекты только одного типа

А по-русски то же самое слабо написать?

L>>Что-то то мне это до боли напоминает А, понял — COM

AA>Разумеется. vtbl — самый надежный гарант бинарной совместимости. Только функции в интерфейсах на всякий случай не стоит перегружать — ибо MSVC перегруженные функции кладет в обратном порядке в vtbl, а другие компиляторы — в прямом.

Ну, COM это не только vtbl — это ещё с 3 десятка правил организаций внешнего интерфейса... Кстати, имхо, не самых неудачных — поэтому если платформы ограничены Win32/WinCE — то выбор COM для разбиения программы на модули оправдывает себя в 99% случаев. А вот если код делается переносимым — вот тут уж начинаются пляски с бубном. Кстати, никто не пробовал с минимальными изменениями портировать код COM/ATL компонент под Linux/Unix и иже с ними?

E>Я посмотрел эту статью. Я так понял, что это надстройка над средствами ОС для работы со строками...
Не совсем так. Это и есть, собственно средства OS для работы со строками. Строки одинаковы и в OS, и в пользовательских программах.

E>Ну привинтили эффективные строчки на автоматических буферах и на буферах аллокированых как-то специально в ОС. Я так понял, что конструкция _LIT( KText, "XXX" ) как-то размещает статический объект непосредственно в ПЗУ устройства?
Не обязательно в ПЗУ Это просто статическая аллокация строки. Разместить статические данные программы в ПЗУ — это уже насколько я понимаю отдельная песня, и делается (опять же — насколько я понимаю) каким-то постпроцессингом после сборки бинарников ядра ОС и системных программ. Для пользовательских программ строки всё равно в ПЗУ не лягут.

E>Собственно люди хотели все статические строки иметь один раз и сразу в ПЗУ. ИМХО вполне понятное желание для этой ОС...
Да чёрт с ними со статическими строчками . Не в них главная проблема — хотя обьявлять отдельно каждый кусок строки тоже довольно неудобно. Главное же неудобство (по моему мнению) лежит в следующей области: 90% работы со строками расположено в тех местах программы, которые некритичны ни по скорости, ни по памяти. А тут получается что даже если мне нужно при старте программы (1 раз на весь запуск) сложить 2 строки вместе — мне нужно ломать голову над тем как это сделать. Я был бы не против такой системы если бы она прилагалась опционально к нормальным строчкам. То есть, грубо говоря (если взять за основу STL) — чтобы каждый std::string мог вернуть буфер в котором он лежит + были операции над статическими строками, типа того что c-smile описал тут: http://www.rsdn.ru/forum/message/2287365.1.aspx

Автор: c-smile
Дата: 02.01.07

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

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

S>"Вы просто не умеете их готовить"
Спасибо за разъяснения я поначалу не знал про http://www.boost.org/libs/smart_ptr/enable_shared_from_this.html и в RSDN обсуждалось enable_shared_from_this http://www.rsdn.ru/Forum/?mid=2300457

Автор: night beast
Дата: 13.01.07

Попробую обобщить – имеются 2 типа указателей. Первый тип это совместное владение, второй снабжение указателя информацией об разрушении. Может быть так что объект содержится внутри другого объекта или контейнера, который сам заботится об удалении и тогда сильные не нужны. Для обоих типов есть 2 подхода – либо объект знает про указатели либо нет. Знание объекта об указателях более надежно, с другой стороны мы можем не иметь возможности менять тип объекта, если коды не наши. Да и классы могут быть какието общеупотребительные, в которых лишнее не желательно Например такие простые как CPoint или даже целое л-валуе.

boost::shared_ptr однозначно требует алокации счетчика. enable_shared_from_this просто регистрирует его. В частности

Requires: enable_shared_from_this<T> must be an accessible base class of T. *this must be a subobject of an instance t of type T . There must exist at least one shared_ptr instance p that owns t.

Думаю сделать shared_ptr с возможностями добавлять enable_intrusive_from_this и enable_weak_from_this былобы правильней. Узнать об разрушении объекта ведь можно ведь не только из деструктора владеющего указателя, но из деструктора самого объекта.

Есть еще такие варианты не включать enable_intrusive_from_this в пользовательский класс , а сделать обертку которая имеет оператор T& и распределять память прямо при создании smart_ptr , но это если тип копируем.

Чет много вариантов набралось, даже если link не считать…….