Есть ли будущее у DELPHI?

Цитата Бобёр @ 06.03.12, 06:18

WriteConsoleOutput/WriteConsoleInput

Это уже не стандартный способ. По крайней мере не С++'ный.

Добавлено 06.03.12, 06:27

Цитата Qraizer @ 06.03.12, 04:06

Просто в то время приложения были всё ещё слабы возможностями и с ОС связаны малым объёмом сервиса. Если ваши процессы имеют от ОС так же мало сервисов, fork()нуть его, подозреваю, несложно.
Процессы Win32 получают от ОС очень много сервисов, причём ОС их не столько поставляет, сколько выступает в роли диспетчера между процессами-клиентами и процессами-серверами. И таких связей набегает приличный граф.

Поясни на примере, а то я не понял, что ты имеешь в виду.

Цитата Бобёр @ 06.03.12, 06:17

fprintf с дескриптором 1 или 2...

Цитата trainer @ 06.03.12, 06:18

fwrite, puts/fputs

Имеется ввиду что-то вроде такого?

    std::ofstream out("con");
    out << "Super cout" << std::flush;

Если да, то это же не по Стандарту вроде.

Имеется в виду
fprintf(stdout, ...)
fwrite( ..., stdout);
puts(...)
fputs( ..., stdout);

А, точно, я про них забыл как-то

P.S. В некоторых реализациях у ofstream есть конструкторы и/или функция open, принимающая в качестве параметра дескриптор файла или FILE*

OpenGL, fprintf(), puts(), fputs(), std::cerr

Добавлено 06.03.12, 09:01
Файловые потоки не подходят по двум причинам:

• имена консольных устройств не стандартизированы; невелика беда, однако одним Стандартом уже не обойдёшься;
• (касается чисто Плюсов) классы стандартых объектов std::cout/std::cin - это std::ostream/std::istream, а файловые объекты будут иметь std::ofstream/std::ifstream: разница в интерфейсе классов - в std:: (i/o)stream нет нескольких методов - и в игнорировании фасета std::codecvt<> в их локалях, что делает невозможным преобразования char<->wchar_t на std::cout/std::cin.

D_KEY, в цитатах примеры. За одно только отсутствие AddRef уже полученным COM-интерфейсам дельфисты пасть порвут, а просто так AddRef делать нельзя, логика приложения может быть разной. Установленные каналы взаимодействия со службами и драйверами тоже могут провалиться по их инициативе, если предусмотреть в них соответствующие API вызовы для этого, а просто так сдублировать HANDLE без уведомления службы/драйвера - это сродни использованию сырых указателей и противоречит базовым принципам архитектуры ОС. Итп.

Сообщение отредактировано: Qraizer - 06.03.12, 09:04

Qraizer, в общем интимные проблемы windows и сопутствующих технологий
Жаль, что это плачевно в конечном итоге сказывается на кроссплатформенном софте.

Цитата D_KEY @ 06.03.12, 10:37

Qraizer, в общем интимные проблемы windows и сопутствующих технологий
Жаль, что это плачевно в конечном итоге сказывается на кроссплатформенном софте.

Плачевно то, что юниксоиды вечно норовят подогнать всё, под свои стандарты.

Цитата D_KEY @ 06.03.12, 10:37

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

С кроссплатформенным софтом всё в порядке.

Кросс платформенность - это.. ну не то, что бы миф.
Вот как, мне, скажем, используя только "кроссплатформенный" fopen() открыть файл эксклюзивно? Или открыть так, что бы остальные могли только читать и захлебнуться слюной при записи. А у меня такая хрень требуется часто, потому что работаем в окружении непредсказуемом, может происходить всякое. Буду использовать fopen() - будет кроссплатформенно, но на винде не особенно рабочим, скорее полусырым.

Сообщение отредактировано: Бобёр - 06.03.12, 11:08

У Delphi есть будущее! Это C++, C#, Java

Цитата KILLER @ 06.03.12, 10:58

Цитата D_KEY @ 06.03.12, 10:37

Qraizer, в общем интимные проблемы windows и сопутствующих технологий
Жаль, что это плачевно в конечном итоге сказывается на кроссплатформенном софте.

Плачевно то, что юниксоиды вечно норовят подогнать всё, под свои стандарты.

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

Цитата [S]mike @ 06.03.12, 11:21

У Delphi есть будущее! Это C++, C#, Java

...PHP, JavaScript, [S]mike...

Сообщение отредактировано: Астарот - 06.03.12, 11:54

Цитата Повстанець @ 06.03.12, 11:02

Цитата D_KEY @ 06.03.12, 10:37

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

С кроссплатформенным софтом всё в порядке.

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

Сообщение отредактировано: D_KEY - 06.03.12, 11:56

Цитата D_KEY @ 06.03.12, 11:55

Я знаю. Просто обидно за процессы немного. Юзаем нитки, хотя достаточно процессов.

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