Есть ли возможность как не писать несколько раз тип данных в функции 
void f(double x1,double x2)

Mormishka, template?

Mormishka, более 4-х параметров - правило плохого тона, а 3-4 раза повторить в описании и потом сказать IDE - сделай имплементацию - влом?
Или интересуют возможности стандарта? Если второе - то не проще ли почитать сам стандарт?
Там всё сказано, причём однозначно. Не то, что здесь на форуме "собирать мнения"...

Mormishka, нет нельзя. Сколько параметров, столько и типов. Тем более что, как заметил borisbn, более 4-х параметров - признак плохого тона или ошибки дизайна. Так что, от пары повторений ты не умрешь.

а мне всегда нравилась CreateProcess   

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

bsa, не понял, CreateFile не создаёт объект ядра файл? А что же она тогда делает?

она много чего делает. Например:

получает хендл текущей стандартной консоли (кстати вполне легальный код).

с названием "СоздатьФайл" как-то не вяжется, не правда-ли?

bems, 

отлично вяжется. консольный хендл ведет на file object. Как и всякие пайпы и девайсы.
Вы просто не умеете это готовить 

Добавлено @ 00:24
Может это новость, скажу на всякий случай. Этот хендл можно и читать/писать функциями ReadFile/WriteFile. чтобы программа получившая файловый хендл стандартного вывода (например) не обязана была думать что там - файл на диске, консоль или пайп, созданный другой программой.

Это сообщение отредактировал(а) bems - 20.4.2011, 00:24

с чего вы решили что "не умеете"?  

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

При чём здесь слово Create ?

к тому, что создаёт файловый объект. То что ты говоришь смахивает на претензию к оператору new за то что он открывает файл, а не создаёт новый (когда применяется с каким-нить классом "файл", открывающим файл в конструкторе)

bems, Это спор ниочем. Кому-то нравится, кому-то нет...
мне лично пофиг, я уже привык.

Нет, это очень предметный спор. Название функи в точности соответствует тому что она делает
CreateMutex
CreateThread
CreateEvent
CreateFile
CreateProcess
CreateFileMapping

Апи очень последователен: есть объект ядра, значит есть функция, где первое слово Create, а дальше - название объекта

Кстати создать файл  текущей консоли можно и по другому

Как-то без слова Create теперь даже не воспринимается   

В общем случае это разные хендлы. Если стандартный вывод перенаправлен, то CreateFile("CONOUT$" возвращает не то, что GetStdHandle

Добавлено через 9 минут и 41 секунду

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

Не хватает еще одного слова -
вот теперь 'последователен'. Согласитесь, что File и FileObject - это несколько разные сущности   

Ну ты программист или куда? Конечно ж объект, потому что всё суть объекты

bems, вот цитата из документации на CreateFile:Где ты тут видишь упоминание о "объекте ядра"? Нет такого! Я конечно рад за разработчиков API, которые создавали его для себя. Но я, как пользователь, чувствую себя не комфортно от того, что функции делают не то, что следует из их названия.
Согласись, прикладному программисту должно быть глубоко фиолетово от того, что происходит внутри системы. Он захотел открыть файл, файл открылся. А то, что система для этого сделала миллион операций, его волновать вообще не должно.

А вот описалово писали уже для таких как ты, которые за деревьями леса не видят. Пришлось перечислить всякие file, file stream, directory, physical disk и тд.
Также для детей природы есть такой топик http://msdn.microsoft.com/en-us/library/ms...28VS.85%29.aspx

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


Это сообщение отредактировал(а) bems - 20.4.2011, 18:46

Ну если подходить ко всему с точки зрения ядра, то Mutex надо было назвать Mutant. Ибо в ядре он именно так называется   

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

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

Еще пример. Мне нужна работа с СОМ портом. В частности, узнать, сколько байт во входном и выходном буферах. Так вот, ни одна функция, отвечающая за получение информации не позволяет это получить. Зато есть магическая функция ClearCommError, которая кроме того, что сбрасывает флаги ошибок порта (ну в принципе следует из ее названия), еще и позволяет получить определенную информацию о состоянии порта. Догадаться не используя поиск по примерам и не перечитывая все описания НЕВОЗМОЖНО!

Во-первых KMUTANT и KMUTEX синонимы, и строго ядерные (не винапи) функции для манипуляции с ним часто ссылаются на него как на мютекс, например KeInitializeMutex, так что тут скорее просто два названия
Во-вторых понятие "объект ядра" вводится именно в винапи, прикладному коду не нужно знать подробностей, но примерное представление имень необходимо.

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

Внутренне устройство - дело другое. Тебя же никто не заставляет работать со структурой FILE_OBJECT напрямую, но что есть объект файл, что он представлен для тебя хендлом, что объект reference-counted, и счетчик ссылок уменьшается вызовом CloseHandle ты знать обязан, если хочешь использовать апи


Когда ты используя CreateFile открываешь ком-порт, то получаешь хендл на реальный FILE_OBJECT, обслуживаемый соответствующим драйвером. Но файловый объект он больше для поточного обмена данными, а драйвероспецифичные вещи всю жизнь делались посылкой драйверу ioctl. И это есть в msdn, да. в этом случае указывается тот же хендл файлового объенкта, но он служит скорее неким ключем у нужному DEVICE_OBJECT. 
Исходя их этого, уж не является ли тем несуществующим способом, о котором ты говоришь вызов DeviceIoControl с кодом IOCTL_SERIAL_GET_COMMSTATUS? 
кстати эта штука тоже заодно сбрасывает флаги. Если поведение драйвера делает из этих вещей одну цельную операцию, то не удивительно что разработчики апи сделали это одним вызовом.

Это сообщение отредактировал(а) bems - 21.4.2011, 00:21