Сообщение Re[18]: Visual C# vs C++. Надо сравнить перспективы. от 09.01.2017 13:14
Изменено 09.01.2017 13:15 lpd
Re[18]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>Модель акторов это очень хорошо. Однако она не всегда применяется, а передача объекта в другой поток встречается на каждом шагу, и тут указатели удобны.
_>А что у тебя за механизм передачи данных между потоками? ) Есть конечно специфические варианты прокидывания данных через систему (типа использования PostMessage в винде или что-то подобное), которые позволяют передать указатель и не позволяют объект. Но это как бы далеко не лучший способ организации межпоточного взаимодействия. Если же у тебя всё организовано по нормальному, внутри приложения, то непонятно откуда возьмётся разница в передаче между указателем и самим объектом.
PostMessage он не только в винде — это распространенный механизм, и очень полезный, т.к. упрощает синхронизацию и исключает большинство deadlockов при обмене данными между потоками. Но в данном случае достаточно просто передать в конструктор std::thread указатель, и после этого поиспользовать и затем забыть про него в основном потоке, а с локальными объектами этого сделать нельзя.
Вообщем, можно спорить относительно полезности семантики. Очевидно, что это большое нововведение, меняющее язык, и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14. На мой взгляд, это все равно что требовать от C++ программиста знания perl, lisp, erlang, rust или еще какого-то редкого языка, который, без сомнения, может чем-то улучшить программу. И это делается массово. Я, например, не увлекаюсь языками программирования — C++ это для меня только инструмент, а специализации у меня другие. И _необходимости_ использовать C++11-14 в программе нет. Это всего лишь дополнение к языку, к которому у разных людей разное отношение.
_>Здравствуйте, lpd, Вы писали:
lpd>>Модель акторов это очень хорошо. Однако она не всегда применяется, а передача объекта в другой поток встречается на каждом шагу, и тут указатели удобны.
_>А что у тебя за механизм передачи данных между потоками? ) Есть конечно специфические варианты прокидывания данных через систему (типа использования PostMessage в винде или что-то подобное), которые позволяют передать указатель и не позволяют объект. Но это как бы далеко не лучший способ организации межпоточного взаимодействия. Если же у тебя всё организовано по нормальному, внутри приложения, то непонятно откуда возьмётся разница в передаче между указателем и самим объектом.
PostMessage он не только в винде — это распространенный механизм, и очень полезный, т.к. упрощает синхронизацию и исключает большинство deadlockов при обмене данными между потоками. Но в данном случае достаточно просто передать в конструктор std::thread указатель, и после этого поиспользовать и затем забыть про него в основном потоке, а с локальными объектами этого сделать нельзя.
Вообщем, можно спорить относительно полезности семантики. Очевидно, что это большое нововведение, меняющее язык, и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14. На мой взгляд, это все равно что требовать от C++ программиста знания perl, lisp, erlang, rust или еще какого-то редкого языка, который, без сомнения, может чем-то улучшить программу. И это делается массово. Я, например, не увлекаюсь языками программирования — C++ это для меня только инструмент, а специализации у меня другие. И _необходимости_ использовать C++11-14 в программе нет. Это всего лишь дополнение к языку, к которому у разных людей разное отношение.
Re[18]: Visual C# vs C++. Надо сравнить перспективы.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
lpd>>Модель акторов это очень хорошо. Однако она не всегда применяется, а передача объекта в другой поток встречается на каждом шагу, и тут указатели удобны.
_>А что у тебя за механизм передачи данных между потоками? ) Есть конечно специфические варианты прокидывания данных через систему (типа использования PostMessage в винде или что-то подобное), которые позволяют передать указатель и не позволяют объект. Но это как бы далеко не лучший способ организации межпоточного взаимодействия. Если же у тебя всё организовано по нормальному, внутри приложения, то непонятно откуда возьмётся разница в передаче между указателем и самим объектом.
PostMessage он не только в винде — это распространенный механизм, и очень полезный, т.к. упрощает синхронизацию и исключает большинство deadlockов при обмене данными между потоками. Но в данном случае достаточно просто передать в конструктор std::thread указатель, и после этого поиспользовать и затем забыть про него в основном потоке, как-то синхронизируясь, а с локальными объектами этого сделать нельзя.
Вообщем, можно спорить относительно полезности семантики. Очевидно, что это большое нововведение, меняющее язык, и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14. На мой взгляд, это все равно что требовать от C++ программиста знания perl, lisp, erlang, rust или еще какого-то редкого языка, который, без сомнения, может чем-то улучшить программу. И это делается массово. Я, например, не увлекаюсь языками программирования — C++ это для меня только инструмент, а специализации у меня другие. И _необходимости_ использовать C++11-14 в программе нет. Это всего лишь дополнение к языку, к которому у разных людей разное отношение.
_>Здравствуйте, lpd, Вы писали:
lpd>>Модель акторов это очень хорошо. Однако она не всегда применяется, а передача объекта в другой поток встречается на каждом шагу, и тут указатели удобны.
_>А что у тебя за механизм передачи данных между потоками? ) Есть конечно специфические варианты прокидывания данных через систему (типа использования PostMessage в винде или что-то подобное), которые позволяют передать указатель и не позволяют объект. Но это как бы далеко не лучший способ организации межпоточного взаимодействия. Если же у тебя всё организовано по нормальному, внутри приложения, то непонятно откуда возьмётся разница в передаче между указателем и самим объектом.
PostMessage он не только в винде — это распространенный механизм, и очень полезный, т.к. упрощает синхронизацию и исключает большинство deadlockов при обмене данными между потоками. Но в данном случае достаточно просто передать в конструктор std::thread указатель, и после этого поиспользовать и затем забыть про него в основном потоке, как-то синхронизируясь, а с локальными объектами этого сделать нельзя.
Вообщем, можно спорить относительно полезности семантики. Очевидно, что это большое нововведение, меняющее язык, и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14. На мой взгляд, это все равно что требовать от C++ программиста знания perl, lisp, erlang, rust или еще какого-то редкого языка, который, без сомнения, может чем-то улучшить программу. И это делается массово. Я, например, не увлекаюсь языками программирования — C++ это для меня только инструмент, а специализации у меня другие. И _необходимости_ использовать C++11-14 в программе нет. Это всего лишь дополнение к языку, к которому у разных людей разное отношение.