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

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

A>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.

Функции работы с файлом как раз являются таким примером.

// Только объявляем
struct FILE;

FILE* f = fopen(...); // Создание объекта
fprintf(f, "%s", "A"); // Работа с объектом
fclose(f); // Разрушение объекта

Реализация например может быть такой

// Здесь детали реализации
struct FILE
{
 char path[100];
}
 
static private_fopen(...) {return malloc(sizeof(FILE)};

FILE* fopen(...) { return private_fopen(...) }
void fprintf(FILE* f, char const* fmt, ...) { ... }
void fclose(FILE* f) { free(f); }

Как можно видеть детали 'класса' FILE скрыты от нас, и работать с ним возможно только через публичные фукнции.

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

A>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.

Выше привели пример FILE*, он хорош и иллюстративен (используем для инкапсуляции систему модулей, вытаскиваем в заголовочники безликие дескрипторы). Но это только начало разговора. Если вы всерьёз планируете писать в ООП-стиле на C, там внутри лежит ещё много граблей, поэтому рекомендую вначале ознакомиться со state-of-art решением: системой типов и объектов GTK+.

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

_NN>Функции работы с файлом как раз являются таким примером.

Мне нравится обсуждение возможных проблем концепции opaque pointer, которая лежит в основе FILE*

Автор справедливо замечает: решение с opaque data type обрекает вас на выделение объектов в куче. Но это иногда может быть не совсем эффективно. А иногда -- совсем не эффективно. Как решение автор предлагает shadow data types:

      typedef struct  
      {  
        unsigned char size_shadow[16];  
      } wibble;  
 
      void wopen(wibble *, int);

В инкапсулированной части:

    typedef struct  
    {  
        grommet g;  
        flange f;  
    } wibble_rep;

Это позволяет даже на C размещать инкапсулированные объекты на стеке.

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

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

_NN>>Функции работы с файлом как раз являются таким примером.

T>Мне нравится обсуждение возможных проблем концепции opaque pointer, которая лежит в основе FILE*

T>Автор справедливо замечает: решение с opaque data type обрекает вас на выделение объектов в куче. Но это иногда может быть не совсем эффективно. А иногда -- совсем не эффективно. Как решение автор предлагает shadow data types:
Можно еще через alloca выкрутиться или VLA C99.
Например

size_t sizeof_FILE(); 

FILE* f = (FILE*)alloca(sizeof_FILE()); // Выделяем на стеке

// Или так C99
char c[sizeof_FILE()];
FILE* f = (FILE*)&c[0];

fcreate(f); // Вызываем конструктор

Можно обернуть в макрос для удобства.

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

A>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.

0) Объект -- структура.
1) Структура объявляется в двух видах, в анонимном публичном, который содержит только один массив байт, который резервирует нужный объем
данных, и в приватном внутреннем, где расписаны все поля. Первая структура не нужна, если клиента ограничить, что он может хранить объекты в своей памяти
только по ссылке. Тогда указатель на первую структуру заменяется на указатель на void (он же HANDLE).
2) Вся реализация выполняется в отдельном модуле (исходном файле). Заголовки делятся также на публичные и приватные. Клиенту класса приватные заголовки
не даются.
3) создаётся полный набор функций, манипулирующих данными объектами, часто включая создание и удаление объектов.

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

_NN>Можно еще через alloca

_NN>Можно обернуть в макрос для удобства.

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

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

A>>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.

MZ>0) Объект -- структура.
MZ>1) Структура объявляется в двух видах, в анонимном публичном, который содержит только один массив байт, который резервирует нужный объем
MZ>данных, и в приватном внутреннем, где расписаны все поля. Первая структура не нужна, если клиента ограничить, что он может хранить объекты в своей памяти
MZ>только по ссылке. Тогда указатель на первую структуру заменяется на указатель на void (он же HANDLE).
MZ>2) Вся реализация выполняется в отдельном модуле (исходном файле). Заголовки делятся также на публичные и приватные. Клиенту класса приватные заголовки
MZ>не даются.
MZ>3) создаётся полный набор функций, манипулирующих данными объектами, часто включая создание и удаление объектов.

intptr_t

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

T>Выше привели пример FILE*, он хорош и иллюстративен (используем для инкапсуляции систему модулей, вытаскиваем в заголовочники безликие дескрипторы). Но это только начало разговора. Если вы всерьёз планируете писать в ООП-стиле на C, там внутри лежит ещё много граблей, поэтому рекомендую вначале ознакомиться со state-of-art решением: системой типов и объектов GTK+.
жуткое извращение, кстати. в духе "мы религиозно не будем писать на С++, поэтому возьмем и переизобретем большую часть его функционала, используя убогий синтаксис и препроцессор".

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

A>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.
способов может быть много, вот только вопрос — зачем, когда C++ позволяет получить не менее эффективный код с меньшими трудозатратами?

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

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

Основные приемы ООП были придуманы задолго до C++ и не зависят по сути от языка программирования. Никакого переизобретения.

Для выбора языка C у авторов были причины. Например, к тому времени у C уже был стандартизованный ABI, а у C++ его нет до сих пор. Но писать на C++ там тоже можно, для этого есть языковой биндинг gtkmm. А также биндинги под другие языки в количестве.

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

A>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.

Только через указатели, и только на неполный тип. Т.е. в хедере что-то типа typedef struct MyData_t* Handle; Но сама структура определена в си-файле. А функции принимают объект типа Handle.

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

A>Коллеги, подскажите, как на языке С можно эмулировать такое свойство ООП, как инкапсуляция?
A>Т.е. нужно иметь объект, все данные которого являются приватными. И должна быть возможность создавать неограниченное количество однотипных объектов.

В этой теме многие посоветовали в публичный интерфейс выставить указатель на неполный тип, а в реализации использовать полный. Но даже при сокрытии реального типа от клиента никто не запрещает исследовать память по полученному указателю и ее каким-либо образом модифицировать. В свое время MS, защищая свои структуры WINAPI, озаботилась подобным и перешла на фиктивные HANDLE, являющиеся ничем иным как ключем некой внутренней структуры, по которому реализация получает реально скрытые от глаз клиента данные. Эскиз:

// interface.h

typedef int HANDLE;

HANDLE open();
void use(HANDLE);
void close(HANDLE);

// interface.c
#include "interface.h"

const int N=16;

struct data {
   int opened;
   char filename[128];
} buffer[N] = {0};

HANDLE open() 
{
   int h = 0;
   // find free handle
...
   return h;
}

void use(HANDLE h) 
{
   struct data* p = &buffer[h];
   ...
}

void close(HANDLE h)
{
   buffer[h].opened = 0;
}

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

B>способов может быть много, вот только вопрос — зачем, когда C++ позволяет получить не менее эффективный код с меньшими трудозатратами?

Существуют продукты, где нет C++. Вот, например, линуксовое ядро (было когда-то, давно не смотрел).
Наверно, какое-нибудь ещё ядро тоже написано целиком на C.

Или микроконтроллер без компилятора C++ я вот тоже в своей жизни встречал. Или, конечно, с C++ но памяти типа 4 кбайта — "не лезет".
Ну, в общем, есть случаи, когда C практичнее.

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

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

B>>способов может быть много, вот только вопрос — зачем, когда C++ позволяет получить не менее эффективный код с меньшими трудозатратами?

D>Существуют продукты, где нет C++. Вот, например, линуксовое ядро (было когда-то, давно не смотрел).
D>Наверно, какое-нибудь ещё ядро тоже написано целиком на C.
Я и говорю, религиозные заморочки.

D>Или микроконтроллер без компилятора C++ я вот тоже в своей жизни встречал.
Только если проект имеет корни в 70х-80х годах. Сейчас в любой нише цена/мощность есть контроллеры, поддерживаемые GCC.

D>Или, конечно, с C++ но памяти типа 4 кбайта — "не лезет".
Вы просто пользоваться им не умеете. Я в свое время писал на C++ под AVR с 512 байтами (!) памяти. Inline и шаблоны позволяли переложить вещи типа "а теперь этот протокол должен использовать SPI вместо USART" на компилятор, вместо программиста. Просто не надо STL с динамической памятью туда пихать и все будет хорошо.
D>Ну, в общем, есть случаи, когда C практичнее.
При условии, что вы не умеете эффективно выбрать нужный subset С++ и пользоваться им.

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


D>>Существуют продукты, где нет C++. Вот, например, линуксовое ядро (было когда-то, давно не смотрел).
D>>Наверно, какое-нибудь ещё ядро тоже написано целиком на C.
B>Я и говорю, религиозные заморочки.

D>>Или микроконтроллер без компилятора C++ я вот тоже в своей жизни встречал.
B>Только если проект имеет корни в 70х-80х годах. Сейчас в любой нише цена/мощность есть контроллеры, поддерживаемые GCC.

Штатный компилятор для zOS до сих пор С++ толком не поддерживает, даже '03. Так что приходится писать на Си времен K&R.
10 лет назад та же проблема была с HP-UX, не знаю, улучшилось ли что-нибудь сейчас.

хъ

D>>Ну, в общем, есть случаи, когда C практичнее.
B>При условии, что вы не умеете эффективно выбрать нужный subset С++ и пользоваться им.


Это верно, куда уж нам...

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

Недавно писал для pic16 (microchip), в наличии есть только XC8 для этого камня. Так что, ты уж чего-то шашкой размахался на счет вездесущности С++.

Здравствуйте, Анатолий Широков, Вы писали:

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

АШ>Недавно писал для pic16 (microchip), в наличии есть только XC8 для этого камня. Так что, ты уж чего-то шашкой размахался на счет вездесущности С++.
мертвая платформа с меньше 0.1% долей рынка. мимо.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Штатный компилятор для zOS до сих пор С++ толком не поддерживает, даже '03. Так что приходится писать на Си времен K&R.
SVZ>10 лет назад та же проблема была с HP-UX, не знаю, улучшилось ли что-нибудь сейчас.
это обычно означает, что платформа давно умерла, под нее ничего не пишут и, соответственно, нет смысла обновлять компилятор. Я не спорю, что в любой нише можно найти древнюю платформу, последний активный разработчик которой умер от старости в 199x году и там нет C++-компилятора. Я лишь утверждаю, что ориентироваться на такие платформы в 2015 году — странное занятие.

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

SVZ>>Штатный компилятор для zOS до сих пор С++ толком не поддерживает, даже '03. Так что приходится писать на Си времен K&R.
SVZ>>10 лет назад та же проблема была с HP-UX, не знаю, улучшилось ли что-нибудь сейчас.
B>это обычно означает, что платформа давно умерла, под нее ничего не пишут и, соответственно, нет смысла обновлять компилятор. Я не спорю, что в любой нише можно найти древнюю платформу, последний активный разработчик которой умер от старости в 199x году и там нет C++-компилятора. Я лишь утверждаю, что ориентироваться на такие платформы в 2015 году — странное занятие.

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

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

АШ>>Недавно писал для pic16 (microchip), в наличии есть только XC8 для этого камня. Так что, ты уж чего-то шашкой размахался на счет вездесущности С++.
B>мертвая платформа с меньше 0.1% долей рынка. мимо.

В следующий раз так и передам заказчику. Ты такой категоричный поскольку молодой или такой молодой поскольку категоричный, а?

Здравствуйте, Анатолий Широков, Вы писали:

АШ>В следующий раз так и передам заказчику.
последнему, оставшемуся на этой платформе?
АШ>Ты такой категоричный поскольку молодой или такой молодой поскольку категоричный, а?
нет, я просто люблю деньги и хорошо измеряемые показатели. И у меня аллергия на "ууу, не все так категорично, давайте мы вам заплатим половину рынка, и наговорим много слов". А простейший измеряемый показатель популярности — это google trends, который показывает полную смерть сабжевой платформы в сравнении с другими популярными платформами:

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>Это означает, что IBM, который развивает свои мейнфреймы, клал с прибором на мнение голодранцев и продолжает успешно окучивать больших и богатых клиентов. А для этих клиентов приходится разрабатывать софт.
IBM живет по большей части с патентных доходов и налаженных каналов продаж. И zOS — это сужающийся рынок со всеми присущими ему заморочками. н эффективное написание софта там даже не в первой десятке приоритетов.

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

B>А простейший измеряемый показатель популярности — это google trends, который показывает полную смерть сабжевой платформы в сравнении с другими популярными платформами:
Ну арм ты все же некорректно приплел, его и в других нишах немало, где остальным 3-м платформам ловить нечего.

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

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

B>>А простейший измеряемый показатель популярности — это google trends, который показывает полную смерть сабжевой платформы в сравнении с другими популярными платформами:
Ops>Ну арм ты все же некорректно приплел, его и в других нишах немало, где остальным 3-м платформам ловить нечего.
это для общего масштаба. msp430 и avr — вполне подходящие для сравнения платформы.

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

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

АШ>>В следующий раз так и передам заказчику.
B>последнему, оставшемуся на этой платформе?

Схемотехники автономной встройки с низким энергопотреблением имеют твое мнение ввиду. А отказывать им только потому, что нет для этой платформы С++ компилятора как-то не профессионально.

АШ>>Ты такой категоричный поскольку молодой или такой молодой поскольку категоричный, а?
B>нет, я просто люблю деньги и хорошо измеряемые показатели. И у меня аллергия на "ууу, не все так категорично, давайте мы вам заплатим половину рынка, и наговорим много слов". А простейший измеряемый показатель популярности — это google trends, который показывает полную смерть сабжевой платформы в сравнении с другими популярными платформами:

см. выше.

Здравствуйте, Анатолий Широков, Вы писали:

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

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

АШ>>>В следующий раз так и передам заказчику.
B>>последнему, оставшемуся на этой платформе?

АШ>Схемотехники автономной встройки с низким энергопотреблением имеют твое мнение ввиду. А отказывать им только потому, что нет для этой платформы С++ компилятора как-то не профессионально.
Хоть штуку баксов в месяц поднять получается?
P.S. У MSP430 очень неплохое энергопотребление. И проектов будет побольше, раз так в 100. И денег тоже.

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

АШ>>Схемотехники автономной встройки с низким энергопотреблением имеют твое мнение ввиду. А отказывать им только потому, что нет для этой платформы С++ компилятора как-то не профессионально.
B>Хоть штуку баксов в месяц поднять получается?

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

B>P.S. У MSP430 очень неплохое энергопотребление. И проектов будет побольше, раз так в 100. И денег тоже.

Я передам эту информацию электронщикам.

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

D>>Существуют продукты, где нет C++. Вот, например, линуксовое ядро (было когда-то, давно не смотрел).
D>>Наверно, какое-нибудь ещё ядро тоже написано целиком на C.
B>Я и говорю, религиозные заморочки.

По-моему, религиозные заморочки это как раз попытки для всего предложить обожествляемый тобой язык

Не нужно париться. Если кто-то считает, что на С будет лучше — то значит пусть делает на С. И да, можешь считать его недоумком, мир от этого никак не изменится. Что же касается оплаты, то в этом мире платят даже за откровенное дерьмо написанное на том же С++ или Java. Так что не стоит удивляться, что кто-то готов платить за хорошие программы, пусть и написанные на С

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Недавно писал для pic16 (microchip), в наличии есть только XC8 для этого камня. Так что, ты уж чего-то шашкой размахался на счет вездесущности С++.

пик — это практически исключение. Как раз отсутствие компилятора для этой платформы в конечном итоге забъет гвоздь ему в крышку.
И мнения электронщиков никто не спросит.

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

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

4 килобайта? Это в некотором смысла просто дофига.

D>Ну, в общем, есть случаи, когда C практичнее.

Уже практически не осталось.

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

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

АШ>>Недавно писал для pic16 (microchip), в наличии есть только XC8 для этого камня. Так что, ты уж чего-то шашкой размахался на счет вездесущности С++.

L>пик — это практически исключение. Как раз отсутствие компилятора для этой платформы в конечном итоге забъет гвоздь ему в крышку.
L>И мнения электронщиков никто не спросит.

Ну, хорошо, пусть исключение, так что не программировать его по причине отсутствия компилятора C++?

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Ну, хорошо, пусть исключение, так что не программировать его по причине отсутствия компилятора C++?

Ну почему же, программируйте себе на здоровье.
Просто отсутствие компилятора все чаще будет дилбрейкером при рассмотрении аппаратной платформы в качестве кандидата при разработке нового продукта. Приведенные тут графики какбы это подтверждают.

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

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

АШ>>Ну, хорошо, пусть исключение, так что не программировать его по причине отсутствия компилятора C++?

L>Ну почему же, программируйте себе на здоровье.

Спасибо, отец родной

Здравствуйте, Анатолий Широков, Вы писали:
АШ>В этой теме многие посоветовали в публичный интерфейс выставить указатель на неполный тип, а в реализации использовать полный. Но даже при сокрытии реального типа от клиента никто не запрещает исследовать память по полученному указателю и ее каким-либо образом модифицировать. В свое время MS, защищая свои структуры WINAPI, озаботилась подобным и перешла на фиктивные HANDLE, являющиеся ничем иным как ключем некой внутренней структуры, по которому реализация получает реально скрытые от глаз клиента данные.

А зачем собственно такой огород городить? Если задаться целью залезть в какую-то внутреннюю структуру, то с помощью дебаггера это всё равно можно сделать. Если не ошибаюсь, то основная идея сокрытия внутренней структуры в том, чтобы иметь возможность менять её не ломая при этом код пользователя. Если пользователь решил, что он хочет головной боли, то пусть играет с внутренними данными напрямую, дуракам закон не писан С этой точки зрения, указатели на некую структуру, тело которой не определено для пользователя, это более чем достаточно для "инкапсуляции".

Здравствуйте, Анатолий Широков, Вы писали:

АШ>>>Ну, хорошо, пусть исключение, так что не программировать его по причине отсутствия компилятора C++?
L>>Ну почему же, программируйте себе на здоровье.

АШ>Спасибо, отец родной

Но следует обратить внимание на то, что у микрочипа есть и другие контроллеры. Для которых есть и сишный и плюсовый компиляторы.

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

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

АШ>>>>Ну, хорошо, пусть исключение, так что не программировать его по причине отсутствия компилятора C++?
L>>>Ну почему же, программируйте себе на здоровье.

АШ>>Спасибо, отец родной

L>Но следует обратить внимание на то, что у микрочипа есть и другие контроллеры. Для которых есть и сишный и плюсовый компиляторы.

Компилятор С++ у них доступен только для 32 разрядных чипов.

Здравствуйте, Анатолий Широков, Вы писали:

АШ>Компилятор С++ у них доступен только для 32 разрядных чипов.

А также для чипов, выпущенных недавно приобретенными ими компаниями. Вроде Roving.

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

_>А зачем собственно такой огород городить? Если задаться целью залезть в какую-то внутреннюю структуру, то с помощью дебаггера это всё равно можно сделать. Если не ошибаюсь, то основная идея сокрытия внутренней структуры в том, чтобы иметь возможность менять её не ломая при этом код пользователя. Если пользователь решил, что он хочет головной боли, то пусть играет с внутренними данными напрямую, дуракам закон не писан С этой точки зрения, указатели на некую структуру, тело которой не определено для пользователя, это более чем достаточно для "инкапсуляции".

Это своего рода файервол.

Здравствуйте, Анатолий Широков, Вы писали:

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

_>>А зачем собственно такой огород городить? Если задаться целью залезть в какую-то внутреннюю структуру, то с помощью дебаггера это всё равно можно сделать. Если не ошибаюсь, то основная идея сокрытия внутренней структуры в том, чтобы иметь возможность менять её не ломая при этом код пользователя. Если пользователь решил, что он хочет головной боли, то пусть играет с внутренними данными напрямую, дуракам закон не писан С этой точки зрения, указатели на некую структуру, тело которой не определено для пользователя, это более чем достаточно для "инкапсуляции".

АШ>Это своего рода файервол.

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

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

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

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

Здравствуйте, Анатолий Широков, Вы писали:

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

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

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

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

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

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

Файервол расскроет свою мощь при межпроцессорном взаимодействии. Ну, скажем, скажут автора топика — а слабо это в виде сервиса сделать, а он такой "да, нет проблем" А так, конечно, если в рамках одного процесса, то здесь с вами не поспорить:
http://www.youtube.com/watch?v=YEdJe2whw1I

Здравствуйте, Анатолий Широков, Вы писали:

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

Ну вот ежели отдельным сервисом, а не библиотекой, тогда и будем дескрипторы пользовать, куда тут от них деться

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

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

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



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

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

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

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

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

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

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

T>Image: main-qimg-16b3bf2e3154004266cdd6c1c020e61e

T>Обратите внимание на соотношение зарплат по C и C++ в США. Это апрель 2015-го.
медиана ниже. что говорит о том, что верхняя граница обусловлена небольшим количеством вакансий с очень специфическими требованиями. плюс, не видно количество вакансий.

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

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

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

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

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

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

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

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

Здравствуйте, Анатолий Широков, Вы писали:

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

Тогда почему C у них в 4кб лезет, а С++ — нет?

Здравствуйте, 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 фишки.
Исходя из этой логики, лучше идти работать слесарем, т.к. не надо догадываться, как пользоваться молотком.

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

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

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

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

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