C++ haters handbook :-)

[Ull9]

так как сформулирован пример, тут тупик.красивого решения нет.
если у меня в коде такая потребность существует, то я применяю принципиально другой подход. Есть на такие случаи два паттерна реактор и проактор. (обакстати уже реализованы в АСЕ, причем на почти всех платформах). Суть в следующем.
Если я что то жду, допустим чтение из файла, или сообщение по сокету, или вообще нечто асинхронное, то создаю обьект, регистрирую его в проакторе (запускаю в нем, для его нужд, 4 треда (по числу процессоров)), передаю в проактор асинхронный ресурс, например хендл файла, и хопля, проактор меня сам известит, через колл бэк интерфейс, что чтение строки в файле произошло.
и Я ПОЛУЧАЮ УЖЕ ПРОЧИТАННУЮ СТРОКУ.

надеюсь я понятно выразился.

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

С ТАО, тоже занимался, капризная вещь, но запустил потом ноу проблем.

[Guffy]

class DisposeableThread;

class Disposeable
{
 Disposeable* prev;
 Disposeable* next;
public:
 Disposeable():prev(0), next(0)  { 
  //.code..
 }
 ~Disposeable() { 
  //.code..
 }

 friend DisposeableThread; 
}

class DisposeableThread
{
 Disposeable* first;
 class DisposeablePtr
 {
  DisposeableThread* tr;
 public:  
  Disposeable* ptr;
  DisposeablePtr(DisposeableThread* t, Disposeable* d):tr(t), ptr(d) {
    if(tr->first) 
     tr->first->prev=ptr; 
    prt->next=tr->first;
    tr->first=prt;
  }
  ~DisposeablePtr(){ 
    if(ptr->prev) {
     tr->first=ptr->prev;
     ptr->prev->next=ptr->next;
    }
    if(ptr->next)
     ptr->next->prev=ptr->prev;
    delete ptr; 
  }
 }
public:
 DisposeableThread():first(0) {
 }
 ~DisposeableThread() {
   while(first) {   
    Disposeable* t=first;
    first=first->next;
    delete t;
  }
 }
 void ThreadProc() {
   DisposeablePtr resource1(this, new Disposeable());
   Sleep(10000);
   {
    DisposeablePtr resource2(this, new Disposeable());
    Sleep(10000);
    {
     DisposeablePtr resource3(this, new Disposeable());
     Sleep(10000);
    }
    Sleep(10000);
   }
   Sleep(10000);
 }
}

На самом деле, возможно, стоит чуть сложнее, но в целом идея, надеюсь, ясна?

[homo ludens]

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

Ты делаешь совершенно правильно, кроме того современный код обычно использует неблокирующие вызовы либо aio_read/write, которые решают много проблем и дают плюс к производительности. Хороший обзор, хотя немного устаревший - http://www.kegel.com/c10k.html - так называемая проблема с10k - 10000 клиентов на сервер.
У меня проблема возникала в том, что интерфейс к базе данных в потоке мог выполнять запрос очень долго и если надо было убивать поток срочно, то приходилось делать такие трюки (ту систему делал на С++). Асинхронных запросов к БД увы не встречал.

Тем не менее я думаю, что даже в ACE, в модели трид на клиент, если ты в клиентском триде дашь например что-то типа fgets(stdin) или sleep(MAX_INT-1) и попытаешься убить трид в этот момент, то есть только два варианта - либо трид не убьется и будет ждать завершения, либо убьется с потерей ресурсов. Другой вопрос, что это редко когда надо, поэтому на эти грабли практически никто не наступает.

У меня своих проблем хватает, я допустим бизнесс логикой займусь.

Юзать готовые крупные библиотеки класса ACE и заниматься только бизнес-логикой конечно удобней, И я пробовал такой подход, только у меня на системы 24х7 контракт на поддержку и развитие - на время жизни системы. И если меня будят в 3 часа ночи через год после сдачи проекта с требованием восстановить работоспособность за 10 минут, то времени на звонки в саппорты нету, а свой код знаешь всегда. Оказалось проще написать свой вариант, не такой удобный и универсальный, но зато ряд проблем ушло навсегда.
Хотя конечно это тоже решение уродское, изобретать велосипед, но было много раз, когда чужая толстая компонента вдруг перестает поддерживаться или вообще фирма меняет владельца или из нее уходят спецы, писавшие компоненту - и все, уже не разберешься в проблеме за разумное время. Причем это было как с open-source, так и с коммерческим саппортом. Ну нафиг, лучше спать спокойно.

[CODE]

На самом деле, возможно, стоит чуть сложнее, но в целом идея, надеюсь, ясна?

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

На С код выглядит намного проще

void *thread_func(void* p)
{
  pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED,0);
  pthread_setcancelstate(PTHREAD_CANCEL_DISABLE,0);
 ...
  intfunc();
 ...
 return 0;
}

void intfunc(void)
{  
  struct x1 x1;
  struct x2 *x2=malloc(sizeof(struct x2));
  pthread_cleanup_push(cleanup,x2);
  int __pt;
  pthread_setcancelstate(PTHREAD_CANCEL_ENABLE,&__pt);
  read/sleep/pthread_testcancel - любой длительный процесс допускающий канселляцию.
  pthread_setcancelstate(__pt,0);
  pthread_cleanup_pop(1);

  cleanup(x2);

}

void cleanup(void* p)
{
  if(p)
   free(p);
}

Хотя конечно тоже всех проблем не решает, так как если в канселлируемом участке идет не атомарный вызов, а вызов функции чужой компоненты (например запрос к БД), то я не знаю какие ресурсы размещаются там внутри. Например если будет getline вместо read - случайный memory leak гарантирован и тут уже ничего не поможет, нет способов это решить.
А в 24х7 любой memory leak будет накапливаться и в конце концов убьет систему.

[Guffy]

а шож вы хотели? ресурсы в потоке - не сахар. как заказывали, так и получили.
тут либо так, либо потоку передается указатель на структуру (объект) передавать и
поток только с полями и работает, накаких локальных ресурсов на стеке.

А в вашем коде - это заслуга не Ц ни в коем разе.
Это реализация птридов вам помогает повесить фунцию очистки.
А моя реализация- делает все сама.
На самом деле вы меня натолкнули на мысль упростить по методике стека

class DisposeableThread;

class Disposeable
{
 Disposeable* next;
public:
 Disposeable():next(0)  { 
  //.code..
 }
 ~Disposeable() { 
  //.code..
 }

 friend DisposeableThread; 
}

class DisposeableThread
{
 Disposeable* first;
 class DisposeablePtr
 {
  DisposeableThread* tr;
 public:  
  Disposeable* ptr;
  DisposeablePtr(DisposeableThread* t, Disposeable* d):tr(t), ptr(d) {
    prt->next=tr->first;
    tr->first=prt;
  }
  ~DisposeablePtr(){ 
     tr->first=ptr->next;
    delete ptr; 
  }
 }
public:
 DisposeableThread():first(0) {
 }
 ~DisposeableThread() {
   while(first) {   
    Disposeable* t=first;
    first=first->next;
    delete t;
  }
 }
 void ThreadProc() {
   DisposeablePtr resource1(this, new Disposeable());
   Sleep(10000);
 }
}

обратите внимание на саму ThreadProc, а все астальное считайте моей реализацией птридов

[Ull9]

спасибо за похвалу. разумеется подход правильный. и если использовать не доморощеные велосипеды а стандартные, то другому программисту разобратся значительно легче, или даже велика вероятность, что он АСЕ уже знает по другим проектам

теперь об этом

Тем не менее я думаю, что даже в ACE, в модели трид на клиент,

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

[homo ludens]

при любом подходе, измение кода влечет перекомпиляцию. ЛЮБОМ, иначе как код будет изменен? Вопрос только в том что пимпл и интерфейсы позволяют УМЕНьШИТь обем перекомпиляции. далее. интерфейс не всегда возможен. Например прямо сейчас у меня контракт, в котором сказано maintenance, понятно? не могу я код перелопачивать! НЕМОГУ. максимум, что могу делать forward declaration or pimpl.

Тут перекомпиляция на самом деле вопрос второй. Интерфейсы позволяют уменьшить связность кода, т.е. зависимости между компонентами. Как одно из следствий - уменьшение времени перекомпиляции. Но напрмер есть две команды программеров написавшие свои компоненты и если изменение куска кода одной командой влечет за собой изменение общего для них h-файла, то ковыряться в коде придется обоим. А если изменения интерфейса нет - то только одной.
В сильносвязанном проекте любой пук одного человека может вызвать правку кода всеми остальными.
Поэтому и требуется изоляция.
И еще пример. Система, которую нельзя останавливать. Но можно выгрузить динамическую библиотеку и подгрузить новую. Очень удобно, но требует железно стабильного интерфейса.

Если у нас есть интерфейс компоненты как набор функций и мы их меняем - то работа начинается у всех. Следовательно методы интерфейса должны быть самой стабильной частью системы.
А если добавляются методы - имхо это нормальная практика при росте системы? В С перекомпиляции всего проекта нету, нужно перекомпилировать только те модули которые используют новые методы. А в С++ перекомпиляция возникает если методы - виртуальные функции, тогда физический размер унаследованного от интерфейса класса меняется. Но только перекомпиляция, другие команды разработчиков использующие старый интерфейс свой код не меняют - только перекомпилируют.

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

Если у тебя maintence, то убрать существующие члены класса ты не можешь - придется много лазить по чужому коду. Здесь pimpl хорош, но опять таки пока не начинают добавляться виртуалки. Тогда - опять перекомпиляция.
А если пишется новый код с нуля?
Вроде из абстрактных соображений идеальным решением был бы абстрактный класс-интерфейс без состояний, реализующий factory для разных объектов, представленными в свою очередь тоже интерфейсами.
Но без виртуалок. А таких абстрактных классов не бывает - это уже что-то другое. Поэтому и возникает техника pimpl.

В С pimpl не требуется - опять таки нет поддержки виртуалок компилятором и абстрактный интерфейс - просто набор функций, включая конструкторы/инициализаторы и деструкторы. А если нужны виртуалки - реализуются индиректами и интерфейс никак не трогают - они часть внутреннего состояния. И в С межкомпонентное взаимодействие оказывается намного проще чем в С++.

Вообще, если меня склероз не подводит, то предшественником pimpl были d-pointers, используемые в Qt. И основной их мотивацией было как раз снизить время компиляции и зависимость между компонентами.

У меня есть такое четкое визуальное представление о С как двумерном языке, а С++ - трехмерном. И это новое измерение, добавляемое ООП и концентрацией на типах, а не на flow как будто только добавляет возможности, но именно из за их обилия - решать задачу иногда становится сложнее.
Я вообще не от хорошей жизни из С++ ушел.

[Ull9]

в принципе верно. согласен.
прости но это как бы тривиальные вещи. и интрерфейсы, и пимплы,
Началось как бы с того что пимпл перед воид имет одно преимущество - отсутствие воид.
Ну а то что интерфейсы лучше пимпл, ясный перец, что лучше. ОБ ЭТОМ спора небыло.

а вот почему из ц++ ушел в с, непонятно, эдак можно следующим языком ассемблер выбрать.

[homo ludens]

а шож вы хотели? ресурсы в потоке - не сахар. как заказывали, так и получили.
тут либо так, либо потоку передается указатель на структуру (объект) передавать и
поток только с полями и работает, накаких локальных ресурсов на стеке.

т.е. про exception - забыть. Про неатомарные автоматические переменные забыть. Про временные объекты забыть.
Писать на С++ забыв вообще про все кроме динамических ресурсов - это тяжеловато, имхо.

А в вашем коде - это заслуга не Ц ни в коем разе.
Это реализация птридов вам помогает повесить фунцию очистки.

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

А функцию очистки можно и в С++ юзать, проблем нету.
Кроме того, если делать глобальный контроллер ресурсов, то лучше юзать pthread_key и pthread_get/setspecific. Там автоматом все очищается, своего рода общий деструктор потока.
или вообще писать __thread char x[200];
Просто точка срабатывания редкая, потому проще локально определить cleanup, чем следить за всеми ресурсами в потоке.

[Guffy]

т.е. про exception - забыть. Про неатомарные автоматические переменные забыть. Про временные объекты забыть.
Писать на С++ забыв вообще про все кроме динамических ресурсов - это тяжеловато, имхо.



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

А функцию очистки можно и в С++ юзать, проблем нету.
Кроме того, если делать глобальный контроллер ресурсов, то лучше юзать pthread_key и pthread_get/setspecific. Там автоматом все очищается, своего рода общий деструктор потока.
или вообще писать __thread char x[200];
Просто точка срабатывания редкая, потому проще локально определить cleanup, чем следить за всеми ресурсами в потоке.

exception тут не причем.
вы все пытаетесь тут всучить мне набор функций pthread_ХХХ
и выдать это за средства самого Ц.
Во-первых, все те же pthread_ХХХ я могу использовать из ЦПП, ничего не потеряв.
Во-вторых, pthread_ХХХ - это еще не весь мир. Я, например, их в галаза не видел - не работаю я на линухе/юнихе. В вин32 совсем другой набор
потоковых ф-й.
Вышеописанный код на ЦПП имеет только одно ограничение - все объекты нужно создавать в хипе через new и оборачивать в DisposeablePtr - все это исходит из предположения, что после убиения потока у него уже нет стека - поэтому все что он насоздавал должно быть в хипе. Ни на какие вспомогательные средства реализации подсистемы потоков он не опирается.
А вообще, какое дело имеет многопоточное программирование (что в больше части методология) к окончательной и полной победе Ц над ЦПП?

[homo ludens]

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

модель трид на клиента, когда поток создается при появлении клиента и удаляется при его уходе я никому не посоветую. В первую очередь потому, что сам имел глупость когда-то ей пользоваться.

Но модель трид на клиент с использованием пула потоков в некоторых случаях вполне жизнеспособна. Зависит от синхронности базовых операций. Если есть что-то типа прокси или web-сервера, где вызовы клиента ждут асинхронного завершения файловых функций с сокетом или файлом, то "трид на клиент" не нужен никаким образом. А вот если каждый клиент постоянно чешет базу данных (и не внешний SQL а вкомпиленный DB manager), то тут вполне нормально - предел базы наступит раньше чем предел потоков. Кроме того есть плюс по безопасности, я могу привязать секюрити контекст к номеру потока после авторизации и запретить некоторые операции с другим номером потока. Плюс подвисание клиентского потока не мешает остальным клиентам, а пострадавший просто переконнектится.
Системы в 600 потоков у меня работали в реальной жизни на одноядерных машинах. Как, это другой вопрос, но у меня допустимый latency - 400мс, пока хватало. И есть подозрение, что до 1000 потоков вполне дотянуло бы.
Кроме того ACE - "тяжелая" библиотека и кушать ресурс должна намного больше, чем pthread.

Началось как бы с того что пимпл перед воид имет одно преимущество - отсутствие воид.

И один недостаток - если добавляются виртуалки возникает перекомпиляция. А в С ее не будет никогда - это гарантированная пуленепробиваемая изочяция. Кроме того воид легко обойти - вместо typedef void* mytype_t пишешь typedef struct { void* data} mytype_t и компилятор прекращает приводить типы. А в С++ без виртуалок прожить сложно - это слишком удобные и теплые тапочки, чтобы потом переобуваться в сапоги. Наследование интерфейсов без них красиво не организуешь.

а вот почему из ц++ ушел в с, непонятно, эдак можно следующим языком ассемблер выбрать.

Что-то не работает - спускаюсь на уровень ниже и пытаюсь разобраться. Так и дошел до жизни такой. ;-)
Кроме того, при моем подходе с предварительным построением макета С++ дает очень мало преимуществ и практически все они представляют собой синтаксический сахар, на который я обычно обращаю мало внимания.
В ассембелер не уйду - переносимость слабая плюс модели процов меняются. А С код остается с тобой на всю жизнь.
С С++ кстати та же проблема - это динамично развивающийся язык, который не всегда обращает внимание на обратную совместимость. И есть шанс, что написанные один раз много лет назад библиотеки придется править или включать специальный режим компиляции. У меня в одном древнем куске кода висит например инициализация массива с явными параметрами конструктора. Когда-то это было нормально, сейчас это не откомпилится никак.
Или вот пример реального кода (уже приводил в другом обсуждении):

#if GCC_VERSION >= 40000
namespace xxx
{
  namespace yyy
  {
#endif  

template <> char* func<bar>::foo(int dump) { return zen(dump); }

#if GCC_VERSION >= 40000
  }
}
#endif

вы все пытаетесь тут всучить мне набор функций pthread_ХХХ
и выдать это за средства самого Ц.

Это не средства С, это средства его стандартных библиотек.

Во-вторых, pthread_ХХХ - это еще не весь мир. Я, например, их в галаза не видел - не работаю я на линухе/юнихе. В вин32 совсем другой набор
потоковых ф-й.

Вы ошиблись. Это практически весь мир. Это Portable Operating System Interface. И в винде POSIX threads тоже есть, включая СЕ. Пользуясь POSIX мой код будет портируем практически везде, включая Windows.
Разумеется для Win-специфичного софта разумней пользоваться его собственными потоками. А вот если надо делать платформенно независимое низкоуровневое решение - без pthreads не обойтись.

Вышеописанный код на ЦПП имеет только одно ограничение

Я пытаюсь показать почему такой код надо запретить к использованию по соображениям неправильного дизайна.
1. создание объекта в хипе намного более затратно по сравнению с созданием объекта в стеке.
2. однопоточный код и многопоточный начинают выглядеть полностью по разному.
3. нелокальность кода. В моей реализации возникновение ожидания обрамляется прямо в коде вокруг ожидания. Ушло ожидание - ушел блок. Появилось - появился блок. Код правится только там, где произошло изменение. В твоей реализации - требуется переработка всего кода потока. Миграция функций из убиваемого потока в главный или наоборот приводит к полному переписыванию всего кода функции и всех вызываемых ей функций. В проекте от 100к строк это просто нереально - ты будешь его постоянно перерабатывать, пока весь код не станет таким (кстати об уродливом коде).

А вообще, какое дело имеет многопоточное программирование (что в больше части методология) к окончательной и полной победе Ц над ЦПП?

А я где-то писал, что С победит С++?
Я писал, что С++ придется уйти при смене глобальной парадигмы - фэнбои ООП слишком жестко привязали его к объектной технике и из универсального языка он превратился в объектный. А С - останется и мигрировать допустим в функциональную схему для него не составит проблем.
Глупо ожидать, что ООП будет жить вечно, не правда ли?

А многопоточное программирование, как и распределенные системы - это не будущее - это настоящее. У меня на конец года светится интересный заказ на гриде с MPI. И для многих программистов на С++ оказывается очень неприятным сюрпризом то, что в некоторых ситуациях объект может быть удален без выполнения деструктора. И чтобы уйти от этого неприятного факта - они пишут код, похожий на тот, который ты привел. Код который использовать нельзя ни в коем случае - это смерть проекта.

[Guffy]

Вы ошиблись. Это практически весь мир. Это Portable Operating System Interface. И в винде POSIX threads тоже есть, включая СЕ. Пользуясь POSIX мой код будет портируем практически везде, включая Windows.
Разумеется для Win-специфичного софта разумней пользоваться его собственными потоками. А вот если надо делать платформенно независимое низкоуровневое решение - без pthreads не обойтись.

Нет, уважаемый. Имхо, это Вы ошиблись. В винде позикс-подсистема есть, да. Но использование двух подсистем в одной проге, насколько я помню, невозможно. Т.е. хотите pthreads от мелкософт - сидите в рамках позикса, а на функции Вин32АПИ можете только облизываться. И наоборот. Или нужны посторонние приблуды. Поэтому все опенсорс кросплатформенные проекты, которые я видел, пользуются своим слоем абстракции и на винде привязывают его к Вин32АПИ.

Я пытаюсь показать почему такой код надо запретить к использованию по соображениям неправильного дизайна.
1. создание объекта в хипе намного более затратно по сравнению с созданием объекта в стеке.
2. однопоточный код и многопоточный начинают выглядеть полностью по разному.
3. нелокальность кода. В моей реализации возникновение ожидания обрамляется прямо в коде вокруг ожидания. Ушло ожидание - ушел блок. Появилось - появился блок. Код правится только там, где произошло изменение. В твоей реализации - требуется переработка всего кода потока. Миграция функций из убиваемого потока в главный или наоборот приводит к полному переписыванию всего кода функции и всех вызываемых ей функций. В проекте от 100к строк это просто нереально - ты будешь его постоянно перерабатывать, пока весь код не станет таким (кстати об уродливом коде).

А я пытаюсь объяснить, что такой дизайн был исходя из отсутствия привязки к конкретной модели тридов и предположения о худшем - после смерти потока памяти его стека уже нет. Но если в реальной жизни какая-то платформа даст мне поблажки (ну те же pthreads) - можете не боятся я, при желании, неприменно ими воспользуюсь в полный рост, еще и со всеми прелестями ЦПП. И код будет как лялечка.
И оформлю все это дело так, что неважно сколько будет размер первоначального кода - главное, чтобы в нескольких (десятках, сотнях) тридпроц нужно было писать как можно меньше и меньше задумываться.
Я еще и очень ленивый
"Лучше день потратить, потом за полчаса долететь".
Кстати, и еще неизвестно, что есть "плохой дизайн". Может это все таки этот замечательный пример, когда подсекают ноги синхронному вызову и неизвестно что это за собой потянет? Да, это реалии, но все же... В винде, вроде бы, только вот к висте они пришли не просто к асинхронному ИО, но и с возможностью отмены ожидания. Может и разработчики разных БД когда-нибудь возьмутся за голову наконец-то.

А я где-то писал, что С победит С++?
Я писал, что С++ придется уйти при смене глобальной парадигмы - фэнбои ООП слишком жестко привязали его к объектной технике и из универсального языка он превратился в объектный. А С - останется и мигрировать допустим в функциональную схему для него не составит проблем.
Глупо ожидать, что ООП будет жить вечно, не правда ли?

А многопоточное программирование, как и распределенные системы - это не будущее - это настоящее. У меня на конец года светится интересный заказ на гриде с MPI. И для многих программистов на С++ оказывается очень неприятным сюрпризом то, что в некоторых ситуациях объект может быть удален без выполнения деструктора. И чтобы уйти от этого неприятного факта - они пишут код, похожий на тот, который ты привел. Код который использовать нельзя ни в коем случае - это смерть проекта.

Может конкретно этими словами и не писали, но эта лебединая песня красной линией проходит по ветке. "С - останется и мигрировать допустим в функциональную схему" - лошади приделают крылья
на мое имхо - массовые языки широкого универсального (или почти универсального) применения, это
C, C++, Object Pascal (Delphi), C# (ну и другие из семейства дотнета, ну да бог с ними), Java. Все остальное живет в своих прочно занятых нишах и нишках. И как кто ни пытался - эще из своей нишки не выбрался на большую дорогу. (про перлы, питоны, лу, бу и т.п. лучше не дразните - не знаю, и знать не хочу. да и не мейнстрим все это). А Страуструп был явно не дурачок, если C++ смог так подняться.
Все из этого списка, кроме жавы, я очень близко знаю. (могу сделать краткий сравнительный обзор) ну разве что на Ц реальных проектов не писал. и не буду. "нехочу" (с) проф.Преображенский.
Так вот, Object Pascal (Delphi), C# и Java - это, по большому счету, родственники идеологии C++. Каждый из них имеет некие уникальные фишки. Основные, это (ну кроме сборки мусора - это для некоторых святое) ссылки (как #include) на откомпилированные модули и более резвитая поддержка метаданных компилятором (проперти, рефлекшн). На рефлекшн C++ крыть практически не чем, но в остальном он по возможностям покруче будет, а остальные, соотвественно, по идеологии попроще. Но все это - ООП, как ни крути.
И ООП еще будет здравствовать, не так уж он болен, как вы считаете. И фенбои С делают ООП на С :P

Многопоточнось. Во многих прогах ее нет, не будет и она там не нужна. Там где она нужна, еще какую-то часть отобьют упрощенные модели типа OpenMP. И только оставшиеся будут пользоваться всеми прелестями и граблями.
Для многих программистов многое оказывается неожиданностью. Давайте не будем ставиь в укор какому-либо языку то, что им пользуются люди, занимающиеся не своим делом.
А код определяется постановкой задачи и ограничениями окружения. И как его делать или не делать применительно к потокам - см. выше. Не было бы в птридах уже готовой приблуды - еще низвестно каким извратом на С нужно было бы выкручиваться.

[homo ludens]

Нет, уважаемый. Имхо, это Вы ошиблись. В винде позикс-подсистема есть, да. Но использование двух подсистем в одной проге, насколько я помню, невозможно. Т.е. хотите pthreads от мелкософт - сидите в рамках позикса, а на функции Вин32АПИ можете только облизываться. И наоборот. Или нужны посторонние приблуды. Поэтому все опенсорс кросплатформенные проекты, которые я видел, пользуются своим слоем абстракции и на винде привязывают его к Вин32АПИ.

Cтранно, что мои POSIX либы перекомпилируются без проблем под Win32. Наверное потому что не пользуюсь MS компилятором...

А pthread от MS я не хочу - я всего лишь хочу писать код не заморачиваясь под какой ОС он будет работать. Для того стандарты и придуманы. И потому на Win32api не облизываюсь - нафиг он мне нужен. Кто рисует окошки в виндах - пользуется моей либой в виде COM-объекта и все, никаких проблем. Так что использование двух подсистем в одной проге возможно.
Под опенсоурс вы наверное имеете в виду средства для рисования окошек? : -)

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

Тут наверное специальная модель процессора нужна, С++ совместимая. : -) Как вы вообще представляете себе вызов деструктора автоматического объекта после смерти трида? Трид умер, а поток команд есть?

Но если в реальной жизни какая-то платформа даст мне поблажки (ну те же pthreads) - можете не боятся я, при желании, неприменно ими воспользуюсь в полный рост, еще и со всеми прелестями ЦПП. И код будет как лялечка.

Эта проблема не разрешима в принципе, даже с дополнительной поддержкой ядра ОС. Деструктор должен выполняться в другом триде, а для автоматических переменных это невозможно. Нужна поддержка языка. А ее нет ни в С++ ни в С. Просто в С нет деструкторов, потому там эта проблема сводится лишь к вызову cleanup.

Кстати, и еще неизвестно, что есть "плохой дизайн". Может это все таки этот замечательный пример, когда подсекают ноги синхронному вызову и неизвестно что это за собой потянет? Да, это реалии, но все же... В винде, вроде бы, только вот к висте они пришли не просто к асинхронному ИО, но и с возможностью отмены ожидания. Может и разработчики разных БД когда-нибудь возьмутся за голову наконец-то.

Хороший дизайн должен допускать малые изменения кода при малом изменении логики. Мой дизайн это дает - ваш нет. Подсечка неатомарного синхронного вызова простыми методами в принципе не разрешима - ни в С ни в С++. Однако в GNU libc (не портируемое решение) я могу динамически подменить malloc через malloc_hook. И это решает проблему на 99%, если делать подмену с обратной подменой в скобках, обрамляющих неатомарный вызов. Другой вопрос, что если не видишь исходного кода той библиотеки, которую юзаешь, то не знаешь только ли динамическая память там юзается - может быть например глобальный массив, а его так не почистишь. Правильная либа обычно ведет себя нормально.

"С - останется и мигрировать допустим в функциональную схему" - лошади приделают крылья

ну приделали же ему два плюсика для ООП. Значит и в будущем сделают так же. Опыт ведь уже есть.

на мое имхо - массовые языки широкого универсального (или почти универсального) применения, это
C, C++, Object Pascal (Delphi), C# (ну и другие из семейства дотнета, ну да бог с ними), Java. Все остальное живет в своих прочно занятых нишах и нишках. И как кто ни пытался - эще из своей нишки не выбрался на большую дорогу. (про перлы, питоны, лу, бу и т.п. лучше не дразните - не знаю, и знать не хочу. да и не мейнстрим все это). А Страуструп был явно не дурачок, если C++ смог так подняться.

Форум, на котором мы общаемся не написан ни на одном из этих языков. Он написан на PHP. Для управления сервером используется perl. Apache, на котором это все запущено написан на С, как и perl и PHP. Работа админа на этом сервере - написание shell-скриптов, которые тоже не на джава. shell-интерпретатор написан на С. Емейл, который проходит через этот сервер обрабатывается почтовиком, который тоже написан не на Дельфи. Таких серверов по миру миллионы. Не хотите знать про это - ваше право. Но мне интересно что же такое мейнстрим в вашем понимании? Сотни негров-кодеров в кубиклах? Тема для разговора с коллегами о новом паттерне? Microsoft Journal и DrDobbs где на один абзац умной мысли приходится 5 страниц пропаганды частной технологии и 10 - рекламы?
Имхо есть вещи о которых много говорят, а есть вещи которые много работают. Почувствуйте разницу.

И ООП еще будет здравствовать, не так уж он болен, как вы считаете. И фенбои С делают ООП на С :P

А я не считаю его больным, просто я помню как тоже самое говорили про структурное программирование.
Кстати reflection в надстройках C++ есть, в том же OpenC++. Причем не только для чтения, а и с возможностью добавления новых членов класса.
И сборка мусора в С есть - пакет GC, его даже GNU компилятор использует.

Многопоточнось. Во многих прогах ее нет, не будет и она там не нужна. Там где она нужна, еще какую-то часть отобьют упрощенные модели типа OpenMP. И только оставшиеся будут пользоваться всеми прелестями и граблями.

Тогда выкиньте свой мультикор и замените на одноядерку. МП нужна в любом сервере, в любых ресурсоемких вычислениях, блин даже P2P клиента на ней наверное удобней писать.
Хотя если вы рисуете окошки на винде... Только это имхо не называется программированием.
http://www.joelonsoftware.com/items/2006/08/01.html - Can Your Programming Language Do This?
(там же есть на русском, но ссылка не копируется).

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

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

А код определяется постановкой задачи и ограничениями окружения. И как его делать или не делать применительно к потокам - см. выше. Не было бы в птридах уже готовой приблуды - еще низвестно каким извратом на С нужно было бы выкручиваться.

POSIX - очень абстрактная спецификация и рассчитана как раз так, чтобы реализовать оптимальную комбинацию максимальной полноты и минимальных наворотов. Опять таки Unix way. Наворачивать туда работу с памятью имхо было бы как раз плохим дизайном.

[Guffy]

Вы, видимо, видите весь мир программ через амбразуру серверов приложений. И так пренебрежительно относитесь к "окошкам". В позиксе под виндой вы будете иметь потоки, сокеты и файлы (включая потоки стандартного ввода и вывода). И все. Остальное - трики.
Чтоб вы не боялись за меня, что я любитель только "окошек", и что это вообще не программирование - начальство подшучивает надо мной, что я "двигателист". Они вечно поручали мне какие-то engine.

OpenC++, возможно - к сожалению, помер в конце 2004го. Т.е. с тех пор релизов не было и незвестно - будут ли.

На чем написан форум - меня абсолютно не трогает. С таким же успехом он мог бы быть на С#+ASP.NET+IIS. Или на С++ и ClearSilver. И почему в отдельной теме веб-программирования многие веб-программисты (видимо, очень уважаемые люди, в отличие от негров-кодеров в кубиклах) выбрали ПХП - меня тоже не чешет.
И пугать меня почтовыми серверами не стоит. Может и на дельфи есть такие. А то я вас буду пугать сотнями миллионов пользователей Windows Media Player, который, вполне не исключено (но, возможно и нет), сделан на С++. А также другими штучками, которые можно встретить на каждом десктопе (и линуховом в том числе). А десктопов поболее будет, чем серверов. Короче, бухгалтерию тут разводить ни к чему.

И чтоб уже подвязать с мультипоточностью, повторюсь:
1. Если мне нужен будет позикс для мультипоточности - я его возьму и не поперхнусь. и в ЦПП в том числе.
2. То, что остаток кода не выполняется при остановке потока, и дестуркторы в том числе - для меня не новость. Тут вы не угадали.
3. Вышепреведенный пример на это был рассчитан с самого начала. Когда делается delete DisposeableThread - там все подчищается.
4. Если я буду уверен, что после чего-то типа thread_terminate и переред чем-то типа thread_delete будет еще жива память, которая была стеком потока и если воспользоваться __thread - код можно упростить и я смогу даже вызывать деструкторы автоматических переменных, наследованных от определенного класса. могу попробовать доказать.
5. Вы, как любитель во всем разбираться внутри, возможно внутрь птридов не очень то и заглядывали. Вполне вероятно, что там есть нечто подобное, а то и похлеще. Вы просто выучили этот АПИ, приноровились к нему и пользуетесь. Если это Вас полностью устраивает - я Вас вполне без шуток поздравляю. Просто не надо сравнивать то, что вам дают готовое, с тем, что вам бы пришлось делать самому, если б вам не дали ничего.

[homo ludens]

Вы, видимо, видите весь мир программ через амбразуру серверов приложений. И так пренебрежительно относитесь к "окошкам". В позиксе под виндой вы будете иметь потоки, сокеты и файлы (включая потоки стандартного ввода и вывода). И все. Остальное - трики.

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

Поймите, я не использую ресурсы ОС, я пишу код, который должен выпоняться везде. И если я напишу
int x =99999; char *y = (char*)&x; char z= *y; то это сработает на x86 и не сработает на Sparc.
И если я напишу printf("%d",sizeof(x)), то это пройдет в 32-х битном интеле и вызовет креш в 64-битном АМД.
Нельзя мне юзать платформенно-зависимые вещи.

OpenC++, возможно - к сожалению, помер в конце 2004го. Т.е. с тех пор релизов не было и незвестно - будут ли.

И чем это мешает им пользоваться?

И пугать меня почтовыми серверами не стоит. Может и на дельфи есть такие. А то я вас буду пугать сотнями миллионов пользователей Windows Media Player, который, вполне не исключено (но, возможно и нет), сделан на С++. А также другими штучками, которые можно встретить на каждом десктопе (и линуховом в том числе). А десктопов поболее будет, чем серверов. Короче, бухгалтерию тут разводить ни к чему.

Количество пользователей почтовых серверов больше количества десктопов - здесь и роботы и автомейлеры и мобильщики и т.п. И если бы почтовый сервер как Windows Media Player говорил что не может найти кодек для чарсета или отсылал бы почту на другой адрес - инета бы не было. Надежность и качество приложений разное. И время жизни тоже. Storage leak в десктопе неважен - прикладуха не работает месяцами и годами, так что можно терять память сколько угодно.
Кстати, не знаю ни одного человека, который бы юзал WMP - даже у моей знакомой блондинки стоит ZoomPlayer + Winamp. Откуда такая цифра - 100М?

5. Вы, как любитель во всем разбираться внутри, возможно внутрь птридов не очень то и заглядывали. Вполне вероятно, что там есть нечто подобное, а то и похлеще. Вы просто выучили этот АПИ, приноровились к нему и пользуетесь. Если это Вас полностью устраивает - я Вас вполне без шуток поздравляю. Просто не надо сравнивать то, что вам дают готовое, с тем, что вам бы пришлось делать самому, если б вам не дали ничего.

Блин, как можно заглянуть внутрь спецификации? POSIX.1c - это набор документов, куда там заглядывать?
В реализацию на Линухе я заглядывал давно, когда были linuxthreads, сейчас время NPTL, а допустим в реализацию AIX не заглядывал, не было у меня в тот момент AIX, да и сейчас нет. В HPUX версии которая у меня была - вообще никаких тридов не было, ни позиксов, ни каких-то других.
За дискуссией по поводу linuxthreads - NPTL - NGPT давно следил, уменьшение времени запуска 100000 потоков с 15 минут до 2 секунд меня например порадовало, отлаживаю софт я на линухе, стресс тесты пошли быстрее.
Только для портируемого приложения это все бесполезно - не буду я юзать футексы вместо мутексов, потому что тогда ни винда ни AIX меня не поймут. И я не знаю сколько потоков поднимется на винде или HPUX за 2 секунды, потому экономлю каждый.

А насчет готового АПИ, вы правы, чего я еще неписал в этой жизни - это sheduler. ;-) От этого бог миловал. Разве что на спор в 80-х на синклере в учебных целях (там прерывание таймера 50 ли 25 гц уже не помню переключало контексты - такая вот учебная задачка. Но назвать это планировщиком конечно трудно.

[Guffy]

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

Поймите, я не использую ресурсы ОС, я пишу код, который должен выпоняться везде. И если я напишу
int x =99999; char *y = (char*)&x; char z= *y; то это сработает на x86 и не сработает на Sparc.
И если я напишу printf("%d",sizeof(x)), то это пройдет в 32-х битном интеле и вызовет креш в 64-битном АМД.
Нельзя мне юзать платформенно-зависимые вещи.

Во первых, непонятно, какая связь между окошками и регулярно подвисающими приложениями. Это опять же ортогональные вещи.
Во вторых, по поводу отделения дизайна окошек от логики - ту, вы может
будете удивлены, но подвижки уже есть. И сделал это, в реальной жизни, а не в концепции, как ни странно, мелкософт. WPF, XAML - новейшие фишки 3го фреймворка (я, правда, пока толком не ознакомился, но хочу).
А вообще жисть штука сложная. И я больше сталкивался не с тем, что нужно написать высокоэлегантный кроссплатформенный код и чтобы задача нравилась. Нужно написать конкретный проект на конкретной платформе и в конкретные (сжатые) сроки. И еще по уродской спецификации. И ежики плачут, плюются, но лезут на кактус.

И чем это мешает им пользоваться?

Ничего. Кроме того, что если на момент помирания там остались куски, приделанные на коленке, то доделывать уже только самому, разгребая до кончиков костей. Да и просто странно. Либо автор утратил интерес к теме сам по себе. Либо столкнулся с чем-то, что оказалось проще плюнуть и забросить.
Кстати, вообще-то эта кухня что-то вроде "препроцессора" к ЦПП, так что в достоинства самого ЦПП рефлекшн я пока торопиться добавлять не буду

Количество пользователей почтовых серверов больше количества десктопов - здесь и роботы и автомейлеры и мобильщики и т.п. И если бы почтовый сервер как Windows Media Player говорил что не может найти кодек для чарсета или отсылал бы почту на другой адрес - инета бы не было. Надежность и качество приложений разное. И время жизни тоже. Storage leak в десктопе неважен - прикладуха не работает месяцами и годами, так что можно терять память сколько угодно.
Кстати, не знаю ни одного человека, который бы юзал WMP - даже у моей знакомой блондинки стоит ZoomPlayer + Winamp. Откуда такая цифра - 100М?

Ну давайте тогда еще по косточкам разберем, кто пользуется стеком TCP\IP
И вспомним легендарные истории о багах в sendmail. И какое шаманство было заполнить sendmail.conf. И про "открытые релеи" вспомним. Надежность почты сейчас - это тысячи битых граблями голов на протяжении полутора-двух десятков лет.
И вы будете тыкать пальцем, но я пользую WMP 11. Так же как и некотрое другие плейеры. И VLC пользую, у которого масса уникальных фишек, но который если как минимум раз 10 не рухнет за день - у него день зря прошел (кстати, ООП на Ц - чистое здоровье ).
А WMP падал очень редко, на откровенно битых файлах, на которых и другие ноги ламают.
А еще на ЦПП мозилка и КДЕ со всей своей гопкомпанией

[homo ludens]

Во первых, непонятно, какая связь между окошками и регулярно подвисающими приложениями. Это опять же ортогональные вещи.

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

Во вторых, по поводу отделения дизайна окошек от логики - ту, вы может
будете удивлены, но подвижки уже есть. И сделал это, в реальной жизни, а не в концепции, как ни странно, мелкософт. WPF, XAML - новейшие фишки 3го фреймворка (я, правда, пока толком не ознакомился, но хочу).

Сильно интересовался XUL от Мозиллы, но имхо до удобства использования там далековато.
Вообще в прошлом году написал для себя требования к GUI библиотеке, с которой мне лично было бы удобно работать. Пока ничего похожего не нашел, ни в дотнете ни где-то еще.
Но правда дотнет3 пока еще не смотрел, жду пока все желающие фэнбои понаступают на грабли и покричат об этих граблях в сети. А попозже, по расчищенному месту и идти приятней...

А вообще жисть штука сложная. И я больше сталкивался не с тем, что нужно написать высокоэлегантный кроссплатформенный код и чтобы задача нравилась. Нужно написать конкретный проект на конкретной платформе и в конкретные (сжатые) сроки. И еще по уродской спецификации. И ежики плачут, плюются, но лезут на кактус.

Бизнес-модель такая. Вот например, вы никогда не задумывались над тем, почему среда разработки от МС всегда будет супер интегрированная с кучей собственных фич и если бы у них была возможность продавать или давать на шару в комплекте с IDE кресло для программиста с автоподогревом - они бы занялись этим сразу? А вот тот же GNU - компонентнтая система допускающая использование любых библиотек в своем коде и основанная на минимализме, и IDE в мире GNU намного менее популярны. С чего бы это? Почему МС никогда не сделает GUI-библиотеки кроссплатформенными понятно, но почему МС, известная тем, что продвигала множество стандартов в разных областях (например протокол DHCP - стандарт МС) никогда не стандартизирует GUI?
Я вот например ответ знаю.

Ничего. Кроме того, что если на момент помирания там остались куски, приделанные на коленке, то доделывать уже только самому, разгребая до кончиков костей. Да и просто странно. Либо автор утратил интерес к теме сам по себе. Либо столкнулся с чем-то, что оказалось проще плюнуть и забросить.
Кстати, вообще-то эта кухня что-то вроде "препроцессора" к ЦПП, так что в достоинства самого ЦПП рефлекшн я пока торопиться добавлять не буду

Несколько лет назад делал на нем всякие мелочи, потом попробовал реализовать контрактный инвариант класса и понял, что проще написать собственный кодогенератор. Не то что бы это не работало, но писать препроцессорный код на С++ - это все равно что писать шелл-скрипт на джаве.
А потом представил как это бы выглядело на С и понял, что это надо срочно реализовывать.

И вспомним легендарные истории о багах в sendmail. И какое шаманство было заполнить sendmail.conf. И про "открытые релеи" вспомним. Надежность почты сейчас - это тысячи битых граблями голов на протяжении полутора-двух десятков лет.

сендмейл это еще цветочки, а вот telnetd, который из BSD перекочевал куда только мог дотянутся (включая опорные маршрутизаторы Cisco) - вот это была бомба, которая похоже продолжает взрываться в разных местах. Последний раз в Cisco-роутерах года 4 назад бахнула.
Однако весь этот код (сендмейл и телнетд) - это унаследованный код раннего периода взрывного роста интернета. Сейчас так не пишут как тогда - с использованием небезопасных функций, без проверки на переполнение буфера, без жестких тестов и т.п..

А еще на ЦПП мозилка и КДЕ со всей своей гопкомпанией

Дык я всегда говорил, что кроме ГУИ мне С++ не дает практически никакой выгоды.
ООП, реализованное на С по глупому - это попытка сделать кальку с С++ реализаций с помощью препроцессора. Сначала стандартного, потом самописного. Имхо это тяжелый бред, потому что если хочешь из С сделать С++, то тогда почему не пользоваться С++ сразу? Нужно такси или нужны шашечки?
А вот реализация например инкапсуляции на С его же средствами происходит совсем по другому, чем на С++ и иногда выходит даже четче чем на С++ - см. мою дискуссию с Ull9.

[Phoenixxe]

Про ACE слышал очень много хорошего, однако сам с ним не успел поработать. С другой стороны в годы увлечения CORBA пытался запустить TAO (их смежный продукт) - увы, мне не удалось его даже скомпилировать. Сейчас наверное ситуация изменилась к лучшему, но тогда (2002 +-год) это был продукт выглядевший очень сыровато.

в 2006 скомпилировался в Visaul Studio 2005
all ok