Самая быстрая ОСь для десктопа сегодня?

Купите себе винт SSD и будет у вас всё хорошо.

 

Nafanya

Не будем разводить флейм на эту тему. Бизнес он очень разный.

 

CRT для кого придумали? в винде msvcrt, в линуксах glibc, но смысл один и тот же... ни там, ни там не удобно "сисколлами программировать"... а программируют на QT потому, что QT удобнее, лучше и приятнее MFC... да и есть еще куча кроссплатформенных библиотек кроме QT... кстати на васме обсуждать подобные продукты, во докатились)))

 

Qt! ну ребятки, аж глаза режет.

 

Винда однозначно (семерка или хр - разницы мало), что линукс, что фряха - тормозное говно.

 

branvi

А вот это простите не гуано?

Код (Text):

1.  #include <winsock.h>
2. SOCKET PASCAL FAR socket ( int af, int type, int protocol);

А? Какой к черту паскаль и ФАР, первый вопрос программиста который взглянет на этот код? А это Win-API, сервисы которые предоставляет Винда.

А взгляните на эту красоту:

Код (Text):

1. #include <sys/types.h>
2. #include <sys/socket.h>
3. int socket(int domain, int type, int protocol);

Всё четко, ясно и понятно. Никаких лишних вопросов.

 

вот кстати, убунту 10.10 у меня гораздо быстрее работает, да и поприятнее сама по себе...

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

 

Slackware only!

 

Rel

А все линуксы, по-моему, давно пересели на utf8, и там всё проще. Нет десятка версий message-box'а под разные кодировки. Есть ровно одна, которая работает с utf8.

Не, в определении ms непонятно: что он возвращает? Указатель? Структуру? Байт? Восемь байт? Или может double? Можно это положить на стек, или в страхе что стек переполнится лучше выделить память?
Но это всё ведь полбеды. Что понятнее можно спорить до пены у рта, и толку никакого от спора не будет. Беда в другом. Я помню как-то пытался мультиплексировать ввод-вывод в венде идущий из разных типов файловых дескрипторов, естественно использовал для этого select -- нафиг мне сдались всякие там WindowProc, если мне не нужны окошки. При отладке же выяснилось что делать этого нельзя. Поскольку "адресные пространства" файловых дескрипторов, и дескрипторов сокетов -- различны. И в пределах одного процесса может существовать сокет и открытый файл чьи дескрипторы равны побитово. Вот тебе и вся "понятность". И "один и тот же интерфейс". И bsd-сокеты с posix-совместимостью. Всё в одном флаконе, с красивой лейбой в виде покорёженной разноцветной форточки.

 

Полностью согласен. int он и в Африке int. А откуда знать, что имеют ввиду мелкомягие под SOCKET? Возможно они прописали typedef int SOCKET; а может typedef class Microsoft_Class{/...} SOCKET;
Почему по их вине программисты должны гадать, как на кофейной гуще?

Пусть получают сертификат POSIX и не злят народ

 

это для того, чтобы старые проекты под вин16 компилировались нормально в вин32 и вин64, через #define эти фар и паскаль ничего не значат. смотри сюда http://msdn.microsoft.com/en-us/library/ms740506(v=vs.85).aspx, там нету такого, а инклюдах там можно наковырять и поболее

 

int_256

Код (Text):

1. SOCKET WSAAPI socket(
2.   __in  int af,
3.   __in  int type,
4.   __in  int protocol
5. );

__in - о, а это новое ключевое слово от Microsoft? Похоже у них своя версия C++, которая серьёзно расходится с общепринятым стандартом.

Не поленился и сейчас открыл справочник Шилдта по С++,где перечислены все ключевые слова, так __in - нету его,просто НЕТУ... Стандарт ANSI/ISO.

 

уже даже не смешно... каждое сообщение со жгучей цитатой...

ILP32, LLP64 И тд... гораздо больше потенциальных багов при портировании, нежели с SOCKET...

MSDN... гадают на кофейной гуще roвнокодеры, нормальные программисты знают, что делают...

как ты переполнишь стек? разве что roвнокодом...

 

А не читали в стандарте, что кейворды, начинающиеся с подчеркиваний, определяются реализацией? Кейвордов __try __catch тоже нет в стандарте кстати. Однако, эти неприязненные __in __out __opt улучшают понимание параметров функции + делают возможным более эффективный статический анализ кода, кстати, именно для этого они и были введены.

 

Nafanya
Во первых, __in - это макрос, а не кейворд. А во-вторых, в GCC расширений Стандарта побольше, чем в MSVC.

 

Бред. Макросы введены для понимания, и нечего страшного в них нету, а вот накопившееся гора костылей в винапи другое дело.

 

spa

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

На смену макросам пришли подставляемые функции (inline). Если определять функцию при помощи макроподстановки - вы столько дров наломаете, что мало не покажется. Так как:
1)В макросах тип передаваемого аргумента не отслеживается и не контролируется
2) А вот фиг вы возьмете адрес псевдофункции, объявленной при помощи макроса
3) Макроопределения только внешне похожи на функции, а их поведение совсем иное не как у функций (внешность макросов сильно обманчива) - с этим таких дров наломать можно, что ошибку потом будет практически нереально отследить (Пример приводится в книге философия си++).
4) Это пережиток прошлого - зачем возвращаться к тому времени, когда в функцию foo(), можно было передать бесконечное кол-во аргументов и Си-шняковый компилятор пропускал их, т.к. не контролировал типы.

Есть конечно полезные макросы, которые используются для отладки кода и т.д. то есть врубают или отрубают при прогоне участок кода. Но вот от макроподстановок типа #define func(a,b,c) .... добра не ждите

 

Еще забыл сказать, что верную работоспособность макроподстановок очень сложно протестировать. Она может выдавать правильный результат в 99% случаев, а на 100-й попытке, когда код уже протестирован и продан пользователю дать сбой.

 

Nafanya
я вообще советую тебе не писать ничего о том, чего ты не понимаешь... и вообще надо бы тебе почитать о препроцессоре...

на смену макросам пришли шаблоны... идем читать про инлайн-функции...

это и не нужно... возможные косяки с типами наиболее вероятно проявятся после препроцессора во время компиляции...

какой нaxep адрес? o_O

мне кажется только ты сам считаешь препроцессор функциями...

скажи это авторам буста...

работоспособность макроса легко проверить... достаточно пропустить файл через препроцессор...

кстати предлагаю небольшое пари))) написать программу, которая выводит "Hello world!" в консоль или в MessageBox или в дебажные сообщения... в винде или в линуксах... но абсолютно без использования препроцессора... как идея?

 

Давайте на этом остановимся и не будем разводить флуд. Каждый всё равно останется при своём мнении.