Сообщение Re[5]: В STL почему нет аналога Event Objects(Win32) от 27.02.2015 3:32
Изменено 27.02.2015 3:52 Pavel Dvorkin
Здравствуйте, Шахтер, Вы писали:
Ш>Это называется упражнение в телепатии.
Мы начинаем скатываться в ФП, если не в КСВ
Ш>Как причина -- идиотская. В ядрах и не должно быть реализации всех мыслимых типов синхронизирующих объектов. Должен быть достаточный базис, позволяющий реализовывать их в приложениях.
Теоретически да. Практически же имеют место всякие привходящие обстоятельства, которые играют роль при разработке той или иной библиотеки. Называть такие решения идиотскими я бы не стал.
Я никогда не занимался вопросом, какой именно набор синхрообъектов является базисом, на основе которого можно сделать любую синхронизацию. Наверное, на этот счет есть какая-то теория. В частности, тот же мютекс в Win API — это лишь двоичный семафор, правда, с несколько измененнным поведением (кстати, из-за этого в ядре его называют mutant).
MS в Win API , по-видимому, решила сделать все возможные виды синхрообъектов, не заботясь об их минимальном наборе.
Кстати, аналогичное имело место в том, что касается языков програмирования. В годы моей программистской молодости были 2 термина : язык-ядро (тщательно отобранный набор ортогональных средств, ничего дублирующегося), и язык-оболочка (вали в кучу все, что придумаешь, пусть программист потом берет то, что хочет). И те, и другие существовали.
Ш>STL -- это не библиотека поддержки операционной системы. По задумке, это библиотека программирования общего назначения, предназначенная для облегчения рутинных вещей для программиста.
+1
Ш>И как таковая она должна содержать в том числе и широкий набор примитивов синхронизации, предоставляя удобный общий интерфейс для их использования и избавляя программиста от необходимости вникать в нюансы операционной системы.
Ш>Например, библиотека fstream скрывает детали низкоуровневой работы с файлами. В Windows мы вызываем функции ReadFile/WriteFile для чтения/записи в файл, а в Linux read/write.
Ш>Используя стандартную библиотеку, можно абстрагироваться от этого и писать переносимый код.
Вполне согласен. Можно еще 100500 примеров привести. И тем не менее порой при разработке библиотек принимают во внимание потенциальную возможность реализации на разных платформах. К примеру, как быть с библиотекой оконнного интерфейса или графики ? В стандарте С++ их нет, а работа с окнами и графикой не менее важна, чем работа с файлами. Ответ прост — да поможет бог тому, кто решится это дело стандартизовать. Существующие реализации (тот же Qt) относительно переносимы, но сделать их стандартом едва ли возможно.
Кстати, о файлах. Современная концепция работы с файлами на нижнем уровне (файл есть бесструктурный набор байтов, в котором возможно позиционирование) родом из Unix. С++ (через С) родом оттуда же. Оттуда это перекочевало в MS-DOS и Windows. Сейчас эта концепция — стандарт де-факто, и большинство здесь присутствующих едва ли предполагает, что может быть иначе. А может, точнее, могло. В OS 360/370 на уровне ядра поддерживались понятия файлов последовательного доступа, прямого доступа, индексно-последовательные файлы, виртуально-последовательные файлы. Этого сейчас у нас нет, и слава богу, так как все это, как стало позже понятно, можно делать и не на уровне ядра. А если бы это сохранилось (кстати, не исключаю, что в нынешних наследниках OS/360 это и до сих пор есть)? Тогда бы авторы С++ (и все прочих языков) имели бы хорошую головную боль насчет поддержки этих возможностей в языке. Не поддерживать — значит, язык не дает возможности работать с приличным куском базового ПО OS/360. Поддерживать — значит писать эмулятор этого для *Nix, а оно надо ?
Ш>Это называется упражнение в телепатии.
Мы начинаем скатываться в ФП, если не в КСВ
Ш>Как причина -- идиотская. В ядрах и не должно быть реализации всех мыслимых типов синхронизирующих объектов. Должен быть достаточный базис, позволяющий реализовывать их в приложениях.
Теоретически да. Практически же имеют место всякие привходящие обстоятельства, которые играют роль при разработке той или иной библиотеки. Называть такие решения идиотскими я бы не стал.
Я никогда не занимался вопросом, какой именно набор синхрообъектов является базисом, на основе которого можно сделать любую синхронизацию. Наверное, на этот счет есть какая-то теория. В частности, тот же мютекс в Win API — это лишь двоичный семафор, правда, с несколько измененнным поведением (кстати, из-за этого в ядре его называют mutant).
MS в Win API , по-видимому, решила сделать все возможные виды синхрообъектов, не заботясь об их минимальном наборе.
Кстати, аналогичное имело место в том, что касается языков програмирования. В годы моей программистской молодости были 2 термина : язык-ядро (тщательно отобранный набор ортогональных средств, ничего дублирующегося), и язык-оболочка (вали в кучу все, что придумаешь, пусть программист потом берет то, что хочет). И те, и другие существовали.
Ш>STL -- это не библиотека поддержки операционной системы. По задумке, это библиотека программирования общего назначения, предназначенная для облегчения рутинных вещей для программиста.
+1
Ш>И как таковая она должна содержать в том числе и широкий набор примитивов синхронизации, предоставляя удобный общий интерфейс для их использования и избавляя программиста от необходимости вникать в нюансы операционной системы.
Ш>Например, библиотека fstream скрывает детали низкоуровневой работы с файлами. В Windows мы вызываем функции ReadFile/WriteFile для чтения/записи в файл, а в Linux read/write.
Ш>Используя стандартную библиотеку, можно абстрагироваться от этого и писать переносимый код.
Вполне согласен. Можно еще 100500 примеров привести. И тем не менее порой при разработке библиотек принимают во внимание потенциальную возможность реализации на разных платформах. К примеру, как быть с библиотекой оконнного интерфейса или графики ? В стандарте С++ их нет, а работа с окнами и графикой не менее важна, чем работа с файлами. Ответ прост — да поможет бог тому, кто решится это дело стандартизовать. Существующие реализации (тот же Qt) относительно переносимы, но сделать их стандартом едва ли возможно.
Кстати, о файлах. Современная концепция работы с файлами на нижнем уровне (файл есть бесструктурный набор байтов, в котором возможно позиционирование) родом из Unix. С++ (через С) родом оттуда же. Оттуда это перекочевало в MS-DOS и Windows. Сейчас эта концепция — стандарт де-факто, и большинство здесь присутствующих едва ли предполагает, что может быть иначе. А может, точнее, могло. В OS 360/370 на уровне ядра поддерживались понятия файлов последовательного доступа, прямого доступа, индексно-последовательные файлы, виртуально-последовательные файлы. Этого сейчас у нас нет, и слава богу, так как все это, как стало позже понятно, можно делать и не на уровне ядра. А если бы это сохранилось (кстати, не исключаю, что в нынешних наследниках OS/360 это и до сих пор есть)? Тогда бы авторы С++ (и все прочих языков) имели бы хорошую головную боль насчет поддержки этих возможностей в языке. Не поддерживать — значит, язык не дает возможности работать с приличным куском базового ПО OS/360. Поддерживать — значит писать эмулятор этого для *Nix, а оно надо ?
Re[5]: В STL почему нет аналога Event Objects(Win32)
Здравствуйте, Шахтер, Вы писали:
Ш>Это называется упражнение в телепатии.
Мы начинаем скатываться в ФП, если не в КСВ
Ш>Как причина -- идиотская. В ядрах и не должно быть реализации всех мыслимых типов синхронизирующих объектов. Должен быть достаточный базис, позволяющий реализовывать их в приложениях.
Теоретически да. Практически же имеют место всякие привходящие обстоятельства, которые играют роль при разработке той или иной библиотеки. Называть такие решения идиотскими я бы не стал.
Я никогда не занимался вопросом, какой именно набор синхрообъектов является базисом, на основе которого можно сделать любую синхронизацию. Наверное, на этот счет есть какая-то теория. В частности, тот же мютекс в Win API — это лишь двоичный семафор, правда, с несколько измененнным поведением (кстати, из-за этого в ядре его называют mutant).
MS в Win API , по-видимому, решила сделать все возможные виды синхрообъектов, не заботясь об их минимальном наборе.
Кстати, аналогичное имело место в том, что касается языков програмирования. В годы моей программистской молодости были 2 термина : язык-ядро (тщательно отобранный набор ортогональных средств, ничего дублирующегося), и язык-оболочка (вали в кучу все, что придумаешь, пусть программист потом берет то, что хочет). И те, и другие существовали.
Ш>STL -- это не библиотека поддержки операционной системы. По задумке, это библиотека программирования общего назначения, предназначенная для облегчения рутинных вещей для программиста.
+1
Ш>И как таковая она должна содержать в том числе и широкий набор примитивов синхронизации, предоставляя удобный общий интерфейс для их использования и избавляя программиста от необходимости вникать в нюансы операционной системы.
Ш>Например, библиотека fstream скрывает детали низкоуровневой работы с файлами. В Windows мы вызываем функции ReadFile/WriteFile для чтения/записи в файл, а в Linux read/write.
Ш>Используя стандартную библиотеку, можно абстрагироваться от этого и писать переносимый код.
Вполне согласен. Можно еще 100500 примеров привести. И тем не менее порой при разработке библиотек принимают во внимание потенциальную возможность реализации на разных платформах. К примеру, как быть с библиотекой оконнного интерфейса или графики ? В стандарте С++ их нет, а работа с окнами и графикой не менее важна, чем работа с файлами. Ответ прост — да поможет бог тому, кто решится это дело стандартизовать. Существующие реализации (тот же Qt) относительно переносимы, но сделать их стандартом едва ли возможно.
Кстати, о файлах. Современная концепция работы с файлами на нижнем уровне (файл есть бесструктурный набор байтов, в котором возможно позиционирование) родом из Unix. С++ (через С) родом оттуда же. Оттуда это перекочевало в MS-DOS и Windows. Сейчас эта концепция — стандарт де-факто, и большинство здесь присутствующих едва ли предполагает, что может быть иначе. А может, точнее, могло. В OS 360/370 на уровне ядра поддерживались понятия файлов последовательного доступа, прямого доступа, индексно-последовательные файлы, виртуально-последовательные файлы. И в Фортране и ПЛ/1 были особые средства для работы с каждым из этих видов файлов. Этого сейчас у нас нет, и слава богу, так как все это, как стало позже понятно, можно делать и не на уровне ядра. А если бы это сохранилось (кстати, не исключаю, что в нынешних наследниках OS/360 это и до сих пор есть)? Тогда бы авторы С++ (и все прочих языков) имели бы хорошую головную боль насчет поддержки этих возможностей в языке. Не поддерживать — значит, язык не дает возможности работать с приличным куском базового ПО OS/360. Поддерживать — значит писать эмулятор этого для *Nix, а оно надо ?
Ш>Это называется упражнение в телепатии.
Мы начинаем скатываться в ФП, если не в КСВ
Ш>Как причина -- идиотская. В ядрах и не должно быть реализации всех мыслимых типов синхронизирующих объектов. Должен быть достаточный базис, позволяющий реализовывать их в приложениях.
Теоретически да. Практически же имеют место всякие привходящие обстоятельства, которые играют роль при разработке той или иной библиотеки. Называть такие решения идиотскими я бы не стал.
Я никогда не занимался вопросом, какой именно набор синхрообъектов является базисом, на основе которого можно сделать любую синхронизацию. Наверное, на этот счет есть какая-то теория. В частности, тот же мютекс в Win API — это лишь двоичный семафор, правда, с несколько измененнным поведением (кстати, из-за этого в ядре его называют mutant).
MS в Win API , по-видимому, решила сделать все возможные виды синхрообъектов, не заботясь об их минимальном наборе.
Кстати, аналогичное имело место в том, что касается языков програмирования. В годы моей программистской молодости были 2 термина : язык-ядро (тщательно отобранный набор ортогональных средств, ничего дублирующегося), и язык-оболочка (вали в кучу все, что придумаешь, пусть программист потом берет то, что хочет). И те, и другие существовали.
Ш>STL -- это не библиотека поддержки операционной системы. По задумке, это библиотека программирования общего назначения, предназначенная для облегчения рутинных вещей для программиста.
+1
Ш>И как таковая она должна содержать в том числе и широкий набор примитивов синхронизации, предоставляя удобный общий интерфейс для их использования и избавляя программиста от необходимости вникать в нюансы операционной системы.
Ш>Например, библиотека fstream скрывает детали низкоуровневой работы с файлами. В Windows мы вызываем функции ReadFile/WriteFile для чтения/записи в файл, а в Linux read/write.
Ш>Используя стандартную библиотеку, можно абстрагироваться от этого и писать переносимый код.
Вполне согласен. Можно еще 100500 примеров привести. И тем не менее порой при разработке библиотек принимают во внимание потенциальную возможность реализации на разных платформах. К примеру, как быть с библиотекой оконнного интерфейса или графики ? В стандарте С++ их нет, а работа с окнами и графикой не менее важна, чем работа с файлами. Ответ прост — да поможет бог тому, кто решится это дело стандартизовать. Существующие реализации (тот же Qt) относительно переносимы, но сделать их стандартом едва ли возможно.
Кстати, о файлах. Современная концепция работы с файлами на нижнем уровне (файл есть бесструктурный набор байтов, в котором возможно позиционирование) родом из Unix. С++ (через С) родом оттуда же. Оттуда это перекочевало в MS-DOS и Windows. Сейчас эта концепция — стандарт де-факто, и большинство здесь присутствующих едва ли предполагает, что может быть иначе. А может, точнее, могло. В OS 360/370 на уровне ядра поддерживались понятия файлов последовательного доступа, прямого доступа, индексно-последовательные файлы, виртуально-последовательные файлы. И в Фортране и ПЛ/1 были особые средства для работы с каждым из этих видов файлов. Этого сейчас у нас нет, и слава богу, так как все это, как стало позже понятно, можно делать и не на уровне ядра. А если бы это сохранилось (кстати, не исключаю, что в нынешних наследниках OS/360 это и до сих пор есть)? Тогда бы авторы С++ (и все прочих языков) имели бы хорошую головную боль насчет поддержки этих возможностей в языке. Не поддерживать — значит, язык не дает возможности работать с приличным куском базового ПО OS/360. Поддерживать — значит писать эмулятор этого для *Nix, а оно надо ?