Re[5]: Язык С и инкапсуляция
От: Анатолий Широков СССР  
Дата: 21.05.15 07:38
Оценка:
Здравствуйте, v_andal, Вы писали:

_>Своеобразный однако файервол. А Вы ничего не путаете? Обычно дескрипторы возникают там, где в пользовательском пространстве необходимо адресовать память из пространства ядра. Напрямую пользовательская программа не имеет доступа к пространству ядра, вот и приходится вводить дескрипторы. То есть это не способ защитить структуру, а способ предоставить доступ к области недоступной пользователю. Если структура уже находится в пространстве пользовательской программы, то смысла в дескрипторах никакого, только код усложнять, да скорость снижать. ИМХО


Файервол, как файервол. Не понимаю, где вы здесь видите усложнение — ну косвенный доступ по дескриптору, ну большая защищенность служебных данных, ну нет необходимости клиенту заботится об утечках (сборкой мусора занимается вендор библиотеки). ИМХО
Re[6]: Язык С и инкапсуляция
От: v_andal Германия  
Дата: 21.05.15 07:59
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

АШ>Здравствуйте, v_andal, Вы писали:


_>>Своеобразный однако файервол. А Вы ничего не путаете? Обычно дескрипторы возникают там, где в пользовательском пространстве необходимо адресовать память из пространства ядра. Напрямую пользовательская программа не имеет доступа к пространству ядра, вот и приходится вводить дескрипторы. То есть это не способ защитить структуру, а способ предоставить доступ к области недоступной пользователю. Если структура уже находится в пространстве пользовательской программы, то смысла в дескрипторах никакого, только код усложнять, да скорость снижать. ИМХО


АШ>Файервол, как файервол. Не понимаю, где вы здесь видите усложнение — ну косвенный доступ по дескриптору, ну большая защищенность служебных данных, ну нет необходимости клиенту заботится об утечках (сборкой мусора занимается вендор библиотеки). ИМХО


Да понятно, что усложнение минимально, просто оно не имеет смысла. Опять же, файервол — это то, что нельзя пройти в наглую, только с разрешения. В данном же случае, если библиотека в пользовательском пространстве, то ходить можно хоть с разрешением, хоть в наглую. Какой же это "файервол"? Так, потуги спрятать свою структуру чуток подальше. Я всего лишь не вижу в этих потугах смысла. Об утечках клиенту всё равно придётся заботится. Если он дескриптор забыл освободить, то никакой мусорщик внутреннюю структуру не вычистит ибо пользователь не сказал, что она не нужна. Ну ленивый я тип, ненавижу делать то, что не имеет никакого смысла
Re[7]: Язык С и инкапсуляция
От: Анатолий Широков СССР  
Дата: 21.05.15 08:22
Оценка:
Здравствуйте, v_andal, Вы писали:

_>Да понятно, что усложнение минимально, просто оно не имеет смысла. Опять же, файервол — это то, что нельзя пройти в наглую, только с разрешения. В данном же случае, если библиотека в пользовательском пространстве, то ходить можно хоть с разрешением, хоть в наглую. Какой же это "файервол"? Так, потуги спрятать свою структуру чуток подальше. Я всего лишь не вижу в этих потугах смысла. Об утечках клиенту всё равно придётся заботится. Если он дескриптор забыл освободить, то никакой мусорщик внутреннюю структуру не вычистит ибо пользователь не сказал, что она не нужна. Ну ленивый я тип, ненавижу делать то, что не имеет никакого смысла


Файервол расскроет свою мощь при межпроцессорном взаимодействии. Ну, скажем, скажут автора топика — а слабо это в виде сервиса сделать, а он такой "да, нет проблем" А так, конечно, если в рамках одного процесса, то здесь с вами не поспорить:
http://www.youtube.com/watch?v=YEdJe2whw1I
Re[8]: Язык С и инкапсуляция
От: v_andal Германия  
Дата: 21.05.15 09:16
Оценка:
Здравствуйте, Анатолий Широков, Вы писали:

АШ>Файервол расскроет свою мощь при межпроцессорном взаимодействии. Ну, скажем, скажут автора топика — а слабо это в виде сервиса сделать, а он такой "да, нет проблем" А так, конечно, если в рамках одного процесса, то здесь с вами не поспорить:


Ну вот ежели отдельным сервисом, а не библиотекой, тогда и будем дескрипторы пользовать, куда тут от них деться
Re[8]: Язык С и инкапсуляция
От: Tilir Россия http://tilir.livejournal.com
Дата: 22.05.15 12:22
Оценка:
Здравствуйте, bazis1, Вы писали:

B>нет, я просто люблю деньги и хорошо измеряемые показатели.


Нет, вы не любите деньги:



Обратите внимание на соотношение зарплат по C и C++ в США. Это апрель 2015-го.
Re[4]: Язык С и инкапсуляция
От: Ops Россия  
Дата: 22.05.15 13:24
Оценка: +1
Здравствуйте, landerhigh, Вы писали:

D>>Или микроконтроллер без компилятора C++ я вот тоже в своей жизни встречал. Или, конечно, с C++ но памяти типа 4 кбайта — "не лезет".

L>4 килобайта? Это в некотором смысла просто дофига.
Они просто Александреску не осилили, и считают что плюсы — это только контейнеры, динамическая память и исключения. Кое-что делал с помощью библиотеки для встройки, основанной на стратегиях, получается очень красиво, а главное — компактно, эффективно и, в какой-то мере, кроссплатформенно, можно писать под одно семейство МК, абстрагируясь от части различий в периферии конкретных моделей.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[9]: Язык С и инкапсуляция
От: bazis1 Канада  
Дата: 22.05.15 16:22
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Здравствуйте, bazis1, Вы писали:


B>>нет, я просто люблю деньги и хорошо измеряемые показатели.


T>Нет, вы не любите деньги:


T>Image: main-qimg-16b3bf2e3154004266cdd6c1c020e61e


T>Обратите внимание на соотношение зарплат по C и C++ в США. Это апрель 2015-го.

медиана ниже. что говорит о том, что верхняя граница обусловлена небольшим количеством вакансий с очень специфическими требованиями. плюс, не видно количество вакансий.
Re[5]: Язык С и инкапсуляция
От: Анатолий Широков СССР  
Дата: 25.05.15 08:27
Оценка: +1
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, landerhigh, Вы писали:


D>>>Или микроконтроллер без компилятора C++ я вот тоже в своей жизни встречал. Или, конечно, с C++ но памяти типа 4 кбайта — "не лезет".

L>>4 килобайта? Это в некотором смысла просто дофига.
Ops>Они просто Александреску не осилили, и считают что плюсы — это только контейнеры, динамическая память и исключения. Кое-что делал с помощью библиотеки для встройки, основанной на стратегиях, получается очень красиво, а главное — компактно, эффективно и, в какой-то мере, кроссплатформенно, можно писать под одно семейство МК, абстрагируясь от части различий в периферии конкретных моделей.

Здесь же не школота собралась, что ты вот так про "не осилил". Кто выбирает языковое средство, тот анализирует много факторов, в том числе и оверхед привносимый самим языком. Ну а если ты лимитирован наличием ограниченного набора языков для конкретной платформы, то и разговора нет относительно "осилил".
Re[10]: Язык С и инкапсуляция
От: Tilir Россия http://tilir.livejournal.com
Дата: 25.05.15 08:50
Оценка: +1
Здравствуйте, bazis1, Вы писали:

B>медиана ниже. что говорит о том, что верхняя граница обусловлена небольшим количеством вакансий с очень специфическими требованиями. плюс, не видно количество вакансий.


Только что зашел на dice.com и воспользовался там поиском (вы тоже так можете, вы же не религиозный фанатик, а любите измеряемые показатели, верно?). 5491 совпадение по C (правда включает в себя те, где указано C/C++) и 4770 по С++ (разумеется тоже включает в себя это общее подмножество). Но визуально в выдаче и чистого C много.

Отсюда вывод: если вы действительно любите деньги, вы лучше не забывайте язык C. У этого языка есть по крайней мере одно важное преимущество: никогда не надо мучительно догадываться что делает оператор "+" сегодня с утра и какая из двадцати шести его перегрузок будет вызвана вот здесь вот. Для индустриальных решений это бывает гораздо важнее чем выразительность, шаблоны и compile-time фишки.
Re[6]: Язык С и инкапсуляция
От: Ops Россия  
Дата: 25.05.15 11:17
Оценка: +1
Здравствуйте, Анатолий Широков, Вы писали:

АШ>Здесь же не школота собралась, что ты вот так про "не осилил". Кто выбирает языковое средство, тот анализирует много факторов, в том числе и оверхед привносимый самим языком. Ну а если ты лимитирован наличием ограниченного набора языков для конкретной платформы, то и разговора нет относительно "осилил".


Тогда почему C у них в 4кб лезет, а С++ — нет?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[11]: Язык С и инкапсуляция
От: bazis1 Канада  
Дата: 25.05.15 16:36
Оценка:
Здравствуйте, Tilir, Вы писали:

T>Здравствуйте, bazis1, Вы писали:


B>>медиана ниже. что говорит о том, что верхняя граница обусловлена небольшим количеством вакансий с очень специфическими требованиями. плюс, не видно количество вакансий.


T>Только что зашел на dice.com и воспользовался там поиском (вы тоже так можете, вы же не религиозный фанатик, а любите измеряемые показатели, верно?). 5491 совпадение по C (правда включает в себя те, где указано C/C++) и 4770 по С++ (разумеется тоже включает в себя это общее подмножество). Но визуально в выдаче и чистого C много.

Ну тогда идем в advanced и убираем C++, C# и Objective, чтобы увидеть чистый C. Остается 2198 вакансий. Теперь убираем C# и Objective из C++ и получаем 3182.

T>Отсюда вывод: если вы действительно любите деньги, вы лучше не забывайте язык C. У этого языка есть по крайней мере одно важное преимущество: никогда не надо мучительно догадываться что делает оператор "+" сегодня с утра и какая из двадцати шести его перегрузок будет вызвана вот здесь вот. Для индустриальных решений это бывает гораздо важнее чем выразительность, шаблоны и compile-time фишки.

Исходя из этой логики, лучше идти работать слесарем, т.к. не надо догадываться, как пользоваться молотком.
Re[12]: Язык С и инкапсуляция
От: Tilir Россия http://tilir.livejournal.com
Дата: 26.05.15 09:00
Оценка:
Здравствуйте, bazis1, Вы писали:

B> чистый C. Остается 2198 вакансий. C++ и получаем 3182.


Все ещё отличный расклад для C, вы не находите?

B>Исходя из этой логики, лучше идти работать слесарем, т.к. не надо догадываться, как пользоваться молотком.


Я окончательно понял: вы не любите деньги. Вы любите процесс =)) Тут нет ничего плохого, я сам такой. Все эти сладенькие фишки с шаблончиками, с вариабельными шаблончиками, с лямбдочками, уняня и мимими. Собственно именно большое количество людей, которым обязательно нужно чтобы молоток был с тремя ручками (процедурный стиль, ооп-стиль и функциональный стиль), причем все три ручки в пространстве были ортогональны, и обеспечивает популярность C++.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.