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

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

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

На этом, как говорили раньше, позвольте откланяться, примите и проч.

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

H>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Если можешь объяснить (на пальцах), как это должно компилироваться и работать (пример, который я привел) — объясни. Если нет — закончим дискуссию.

H>А как вообще работает вывод типов в языках?
H>Или он тоже не работает в "условиях в реальных проектов"?

Как работает вывод типов в основных языках — объяснять не надо, а вот какая от этого может быть польза в том примере, который я привел — объясни. Если бы я эту программу писал — поставил бы float и на этом вывод типов бы закончился. Проверки компилятором сводились бы к коректности употребления float в том или ином месте. Мне говорят — можно и больше проверок компилятором, будет польза. Можешь — объясни, на этом примере.

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

J>Она не завернута явно, но твои InitialPtr, OpenPtr и ClosedPtr — это же состояния КА, так что хоть горшком назови

Это просто состояния.
Понятное дело, что любой объект это и есть автомат. Разница тут лишь в присутствии/отсутствии ограничений на формат сигналов. ИМХО, обычный вызов методов всяко удобнее специальных go_transition.

V>>Для случая файла на порядок дешевле создать в куче некий "shared object", чем делать DuplicateHandle/CloseHandle в каждом конструкторе копирования и деструкторе состояния Opened.
J>А у меня этого и нету, это у тебя file передается, по-разному обернутый, а у меня передается его состояние, которое с тем, кто и как владеет файлом, никак не связаны. А у тебя смешано владение и состояние.

Дык, у тебя-то состояние разнесено по 2-м сущностям — по File, и по его "дополнительному" состоянию. Т.е. получить некое состояние и куда-то передать не получится, тебе надо будет передавать пару: объект, инкапсулирующий логику слежения за ресурсами, и текущее его вспомогательное состояние. Мне это кажется малость перебором, пусть это "дополнительное" состояние как-нить внутри хранит ссылку на "основное". Отсюда и пляски со смарт-поинтерами.

J>А контроль ресурсов мне тут не нужен, не понимаю, почему ты так на него напираешь.

Он "не нужен" если все происходит в одном scope. Но так бывает редко.

J>Чем тебя не устраивает вызов f.go( s, Read{data_to_read} )? Что ты там хотел, буфер передавать с размером? Тогда это будет выглядеть так: f.go( s, Read{&buffer, size} ).

Ну... Если я в каждой строчке своей программы буду писать f.go(), чтобы вызывать каждый метод каждого объекта — я лучше застрелюсь.

J>Еще как воткну, ты думаешь, я только на operator<< тестировал? Ты просто не знаешь силы variadic macros. Вообще говоря, единственное, что может сломать макрос — это запятая, которая неизбежно увеличивает количество параметров. Отсюда весь гемор. С появлением variadic macros этой проблемы больше нет.

Я даже боюсь предположить, сколько мне ждать, чтобы эта же фича появилась в MS VC++.

V>>Для того, чтобы твоё s3 нельзя было переиспользовать после Close(). Да, тоже притянутость за уши, согласен, но тут иначе никак. У тебя сей момент вообще не контролируется, т.е. в случае ошибки при вызове методов для закрытого файла диагностировать это в общем случае будет труднее. А у меня задуман как бы специальный smart-pointer, который выплюнет ошибку вроде "нарушение протокола".
J>Да ладно. Сам файл в состоянии в рантайме проконтролировать, что его уже закрыли, и бросить исключение, точно так же, как это делается сейчас. Никакой разницы с твоим обнулившимся указателем, который точно так же проверяется в рантайме.

С файлом согласен, а в другом месте с диагностикой будут проблемы. В принципе, настаивать не хочу, костыль он и в Африке костыль.

V>>Уникальность, как уже сказал — это единственный способ гарантировать протокол. Ввиду того, что уникальность в С++ не подерживается, был предожен этот костыль.
J>Битва костылей

Да какая там битва? Ленивое ими помахивание.

J>Ну вот припиши внешний go_chain в твоей схеме, чтоб была ошибка компиляции, и сравним.
J>В моей это делается тремя строчками, см. мое исходное сообщение. Как это сделать просто в твоей — я не вижу.

Я новые фичи даже еще не пробовал ни разу, и пока в скепсисе, бо собирать проекты надо как для виндовых, так и для линуховых клиентов. Обхожусь для частичного примерения boost::bind/boost::function, вполне прокатывает.

Можно в итоге сделать так:

struct File { std::string fname; int handle; }; 
File openFile(const std::string & path);
File readFile(File file, void * bufer, size_t count);
void closeFile(File file);

int main(int argc, char* argv[])
{
  using namespace boost;

  char buffer[1024];

  function<void(string)> processFile = 
    call_chain
      >> bind(openFile, _1)
      >> bind(readFile, _1, buffer, sizeof(buffer))
      >> bind(closeFile, _1);

  processFile("some.path");
  return 0;
}

call_chain — небольшая однократно-писанная инфраструктура на три десятка строк на базе boost::bind/boost::function<>.


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

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

Заметь, тут функциональный подход малость удобнее, коль речь заходит о "цепочках" вызовов и комбинаторах, бо надо создавать лямбды, которые будут "звенья" этой цепи.

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

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

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

PD>Самостоятельный человек , прежде чем выбирать информацию, должен убедиться в том, что она может быть ему полезной.
Ну раз ты задаешь вопрос, а тебе говорят, что ответ есть в статье, как сам думаешь, может ли быть информация полезной? Окажется ли она в самом деле полезной — это уже потом будет ясно, после прочтения.

PD>В противном случае он рискует выбрать массу бесполезной информации.
А в твоём случае он гарантирует себе остаться без полезной.
Что лучше, иногда потратить время впустую или никогда не тратить его на полезное?

PD> Вот для этого форумы и нужны — они позволяют объяснить в нескольких словах самостоятельному человеку, в чем эта информация заключается и почему она может быть полезной.
Тебе объяснили, чем она может быть полезна. Саму информацию пережёвывать уже не дело форума.

PD>На этом, как говорили раньше, позвольте откланяться, примите и проч.
Доброго дня.

On 16/04/11 13:50, Pavel Dvorkin wrote:
> ИМХО все это чистый академизм, не имеющий отношения к реальной работе.
А где границу академичности провести? Скажем, а накой нужны типы вообще? Кто придумал эту гадость с string, integer, float? Была у нас функция, которая брала температуру в градусах
func(integer t)
потом вдруг выяснилось, что температура-то может быть не целой и должны писать
func(float t)
а потом и кто-то решил вводить значения "дубак", "жара", "брр.." и нам надо уже
fuct(string t)
?
Эти все типы тоже чистый академизм? Надо писать всё на асме, где у тебя есть лишь адрес ячейки в памяти?