The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Проект MOOL развивает средства разработки драйверов ядра Lin..., opennews (ok), 04-Окт-14, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


22. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от Xasd (ok), 04-Окт-14, 01:41 
> Стоит напомнить, что Линус Торвальдс является ярым противником C++ и считает его ужасным языком, сковывающим разработчиков рамками ранее созданных абстракций (например, при желании избавиться от неэффективных абстракций, разработчик сталкивается с тем, что весь код зависит от созданных вокруг этих абстракций объектных моделей и не может исправить ситуацию не переписывая своё приложение).

вот же мозгач Линус! молодец, правильно думает..

что же будет когда его не станет (из-за автобуса, того-самого)..?

Ответить | Правка | Наверх | Cообщить модератору

48. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +1 +/–
Сообщение от Ан (??), 04-Окт-14, 14:12 
А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру?

Вообще в API всегда встают вопросы о поддержке каких-то структур/функций и желании их заменить, переписать. Так что это как-то из пальца высосано. Эта проблема всплывёт как в C++ так и в С.

Ответить | Правка | Наверх | Cообщить модератору

69. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от тоже Анонимemail (ok), 04-Окт-14, 17:01 
> Эта проблема всплывёт как в C++ так и в С.

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


Ответить | Правка | Наверх | Cообщить модератору

98. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от freehckemail (ok), 05-Окт-14, 18:21 
>> Эта проблема всплывёт как в C++ так и в С.
> Эта проблема всплывет в любом языке. Вопрос в объеме кода, который действительно
> зависит от таких изменений.
> В С и С++ при правильном написании это - только тот код,
> который реально работает с этими полями. Весь остальной код, касающийся этой
> структуры, видит только указатель - то есть некое место в памяти
> определенного размера, но неизвестного назначения.

А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит. И таким образом всё равно при изменении полей структуры придётся перекомпилировать все пользующиеся этой структурой программы, хотя казалось бы, интерфейсы остались неизменными.

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

Ответить | Правка | Наверх | Cообщить модератору

102. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от тоже Анонимemail (ok), 05-Окт-14, 22:35 
Неизменными интерфейсы будут только в том случае, если в интерфейсах используется не структура, а указатель на нее. В этом случае тому коду, который не лезет внутрь структуры, безразлично, что скрывается под void*, а тому, который лезет - ну, тут перекомпиляция при изменениях неизбежна.
Ответить | Правка | Наверх | Cообщить модератору

104. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от freehckemail (ok), 05-Окт-14, 23:29 
> Неизменными интерфейсы будут только в том случае, если в интерфейсах используется не
> структура, а указатель на нее. В этом случае тому коду, который
> не лезет внутрь структуры, безразлично, что скрывается под void*, а тому,
> который лезет - ну, тут перекомпиляция при изменениях неизбежна.

Я правильно понимаю, что Вы предлагаете:
1) В заголовках писать только определение интерфейсов,
2) Описание структуры вынести из заголовков в код библиотеки,
3) Интерфейс-конструктор будет выделять память в куче и возвращать указатель на неё, а все остальные интерфейсы будут оперировать указателями структуры,
4) В программе, которая пользуется библиотекой, все переменные, подразумевающие хранение данной структуры, будут иметь тип void.

Если я правильно Вас понял и ничего не забыл, то в принципе это выглядит как решение... Но не станет ли код слишком громоздким?

Ответить | Правка | Наверх | Cообщить модератору

116. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от тоже Анонимemail (ok), 06-Окт-14, 08:42 
Описание структуры логично вынести из заголовков с API в заголовки, которые будет подключать только тот код, которому это действительно нужно. Остальному перекомпилироваться совершенно необязательно.
Ответить | Правка | Наверх | Cообщить модератору

121. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от Аноним (-), 06-Окт-14, 12:01 
А что делать? Либо поля структуры, их размер, порядок, тип и количество являются частью интерфейса — и тогда мы можем сами выделять память, обращаться к отдельным полям не call get_field1, а mov eax, [struct_var+offset_field1], и т.п., — либо не являются, а вместо них есть абстрактный интерфейс к структуре — функции создания/удаления, геттеры-сеттеры, всякие удобные запросы (типа метода size() для связного списка) — но тогда, увы, появляются накладные расходы за счет косвенности, и полностью их никак не убрать.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

124. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от freehckemail (ok), 06-Окт-14, 12:36 
Накладные расходы - не такая уж большая плата за новый уровень абстракции. Проблема как раз в том, что читать это будет невозможно. Тут возникает логичный вопрос: зачем Вам вообще сдалась жёсткая типизация языка Си, если при работе с библиотеками Вы будете использовать void* для структуры, определённой этой библиотекой? Вы мало того, что читать это замучаетесь, так ещё и потеряете (хоть и не шибко хороший) контроль типов.

Я вот чувствую, что если мой собеседник ещё немного поразмышлял бы, то пришёл бы к выводу, что для подобного программирования очень подходят языки с динамической типизацией переменных.

Ответить | Правка | Наверх | Cообщить модератору

126. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от тоже Анонимemail (ok), 06-Окт-14, 13:30 
Могу в ответ посоветовать вам поразмышлять: возможно, для подобных задач просто стоит использовать не жесткие структуры, а что-то другое? Глядишь, и не понадобится оверхед на ненужные абстракции типа динамической типизации переменных.
Сейчас по разнице между форматами обмена информацией (бинарным, расширяемым и комбинированным) накоплен колоссальный мировой опыт...
Ответить | Правка | Наверх | Cообщить модератору

127. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от freehckemail (ok), 06-Окт-14, 13:37 
Извините, но я предпочту закончить этот диалог. Он как-то сильно на два монолога смахивает.
Ответить | Правка | Наверх | Cообщить модератору

128. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  –1 +/–
Сообщение от Аноним (-), 06-Окт-14, 13:57 
Нахрен void*? Или в С нельзя сказать

struct MEGA_STRUCT;
typedef struct MEGA_STRUCT* PMEGA_STRUCT;

? Вот вам PMEGA_STRUCT, вот вам функция FIRST_FIELD_TYPE get_first_field(PMEGA_STRUCT), вот вам PMEGA_STRUCT alloc_struct(void*(*)(size_t)). Правда, я с чистым С никогда не работал, может, там так и нельзя.

Хотя, конечно, разница между mega_struct.first_field = 5 и set_first_field(mega_struct, 5) есть, я не спорю - ну так поэтому в С++ часто вместо сеттеров пишут геттеры, которые возвращают ссылки, чтобы можно было писать mega_struct.first_field() = 5.

Ответить | Правка | К родителю #124 | Наверх | Cообщить модератору

132. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от dq0s4y71 (ok), 06-Окт-14, 15:48 
> А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит.

Причём здесь заголовки? В Си вы можете написать в заголовке:

/* my_object.h */

struct my_object;
struct my_object * my_object_create();
int my_object_do_something(struct my_object * object);

И всё. А саму структуру и работу с ней вы можете расписать в реализации:

/* my_object.с */

struct my_object {
  int field1, field2;
  ...
};

struct my_object * my_object_create() {
  struct my_object * ret = malloc(sizeof(struct my_object));
  ...
  return ret;
}

int my_object_do_something(struct my_object * object) {

  object->field1 = ...;
  ...
}


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

В С++ такой номер не пройдёт - там, если вы хотите чтобы работали виртуальные методы, нужно иметь прототип класса. И изменить что-то в этом базовом классе без необходимости перекомпиляции всего когда снизу доверху вы не сможете.

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

144. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  –1 +/–
Сообщение от freehckemail (ok), 07-Окт-14, 01:32 
>> А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить под переменную? Правильно, заголовки подключит.
> Причём здесь заголовки? В Си вы можете написать в заголовке:
> /* my_object.h */
> struct my_object;

Не знал, что можно объявлять структуру, не объявляя сами поля.
Серьёзно, я продолжаю периодически узнавать что-то новое, и это меня всё больше и больше удивляет. Вот документация: http://www.gnu.org/software/gnu-c-manual/gnu-c-manual.html#D...

И здесь ни слова о том, что так можно.

Но так, оказывается, действительно можно. Я сейчас специально поискал подобные вещи. Нашёл в stdio.h - именно так, оказывается, определена структура FILE.

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

Ответить | Правка | Наверх | Cообщить модератору

149. "Проект MOOL развивает средства разработки драйверов ядра..."  +/–
Сообщение от arisu (ok), 07-Окт-14, 09:09 
> Вот логичный вопрос-продолжение: а есть ли где-нибудь более подробная справка, в которой
> такие моменты обозначены?

да. называется «стандарт языка си». стоит недорого.

Ответить | Правка | Наверх | Cообщить модератору

163. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от dq0s4y71 (ok), 07-Окт-14, 12:45 
ниже ответил
Ответить | Правка | К родителю #144 | Наверх | Cообщить модератору

142. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от Посторонним В (?), 07-Окт-14, 00:30 
>[оверквотинг удален]
>> структуры, видит только указатель - то есть некое место в памяти
>> определенного размера, но неизвестного назначения.
> А как эта скомпилированная программа на C/C++ узнает сколько памяти нужно выделить
> под переменную? Правильно, заголовки подключит. И таким образом всё равно при
> изменении полей структуры придётся перекомпилировать все пользующиеся этой структурой
> программы, хотя казалось бы, интерфейсы остались неизменными.
> Это известная проблема языка C, которая, к сожалению, не решается просто "правильным"
> написанием кода. Но что касается наличия данной проблемы в других языках,
> то квантификатор "любой" тут не к месту. Существуют языки, которые от
> этого не страдают. Лиспы, например.

Как бы перекомпилировать ядро с новой версией всё равно необходимо...

Ответить | Правка | К родителю #98 | Наверх | Cообщить модератору

123. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  –4 +/–
Сообщение от bOOsteremail (?), 06-Окт-14, 12:20 
В С++ легче чем в C. Templates рулят, правда не для школьников.
Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

130. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от dq0s4y71 (ok), 06-Окт-14, 15:31 
> А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру?

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

Вы можете вообще даже не объявлять поля структуры:

struct my_object;

struct my_object * my_object_create();
int my_object_do_something(struct my_object * object);

И это будет работать. А о внутренней структуре вашего объекта пользователь может вообще ничего не знать, в отличие от плюсов.

Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

143. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  –1 +/–
Сообщение от Посторонним В (?), 07-Окт-14, 00:38 
>> А если сишнаую структуру захочешь изменить(заменить существующее поле на другое) то что внезапно весь зависимый софт сам перепишется под новую структуру?
> А в чём проблема? Передавайте в функцию указатель на структуру, а какие
> поля у этой структуры, никого может не волновать, кроме внутренней реализации.
> Вы можете вообще даже не объявлять поля структуры:
> struct my_object;
> struct my_object * my_object_create();
> int my_object_do_something(struct my_object * object);
> И это будет работать. А о внутренней структуре вашего объекта пользователь может
> вообще ничего не знать, в отличие от плюсов.

И тут как-то внезапно выясняется, что C++ как бы не должен быть хуже C.

Вообще.


struct my_object1;
struct my_object2;
int do_something(struct my_object1 *);
int do_something(struct my_object2 *);

:-)
Ответить | Правка | Наверх | Cообщить модератору

162. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от dq0s4y71 (ok), 07-Окт-14, 12:43 
Внезапно выясняется, что если вы хотите использовать какие-то методы класса, класс должен быть определён :)
Ответить | Правка | Наверх | Cообщить модератору

145. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  –1 +/–
Сообщение от freehckemail (ok), 07-Окт-14, 01:34 
> Вы можете вообще даже не объявлять поля структуры:
> struct my_object;
> struct my_object * my_object_create();
> int my_object_do_something(struct my_object * object);

Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно объявлять структуры, не объявляя сами поля?
А то меня очень огорчает тот факт, что о таких вещах я узнаю только сейчас, хотя вроде бы с Си очень давно знаком.

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

148. "Проект MOOL развивает средства разработки драйверов ядра..."  –1 +/–
Сообщение от arisu (ok), 07-Окт-14, 09:08 
> Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно
> объявлять структуры, не объявляя сами поля?

в стандарте, однако. forward declaration называется.

Ответить | Правка | Наверх | Cообщить модератору

154. "Проект MOOL развивает средства разработки драйверов ядра..."  –1 +/–
Сообщение от freehckemail (ok), 07-Окт-14, 11:09 
>> Уважаемый, не затруднит ли Вас подсказать мне, где это задокументировано, что можно
>> объявлять структуры, не объявляя сами поля?
> в стандарте, однако. forward declaration называется.

Я думаю, не с проста Вы не приводите ссылок. Я поискал. И стандарт, и forward declaration. И не нашёл этой документации. Arisu, попробуйте быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень не кажутся.

Ответить | Правка | Наверх | Cообщить модератору

156. "Проект MOOL развивает средства разработки драйверов ядра..."  +1 +/–
Сообщение от arisu (ok), 07-Окт-14, 11:23 
> Я думаю, не с проста Вы не приводите ссылок.

конечно: я предполагаю минимальные навыки гуглежа.

> Я поискал. И стандарт, и forward declaration. И не нашёл этой документации.

это прискорбно. я по «c struct forward declaration» нашёл сразу много интересного. тебе гугель поломали.

а стандарт денег стоит, да. поэтому на него очень сложно ссылки приводить.

> Arisu, попробуйте
> быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень
> не кажутся.

куда уж дальше-то? и направление поиска дал, и ключевые слова… ни разу не написал, что «это должны знать все, а кто не знает — тот лох». ан нет, мало, надо разжевать и в рот положить. пардон, но это уже только за деньги.

Ответить | Правка | Наверх | Cообщить модератору

161. "Проект MOOL развивает средства разработки драйверов ядра..."  +/–
Сообщение от freehckemail (ok), 07-Окт-14, 12:43 
>> Я поискал. И стандарт, и forward declaration. И не нашёл этой документации.
> это прискорбно. я по «c struct forward declaration» нашёл сразу много интересного.
> тебе гугель поломали.

Arisu, мне сдаётся, что ты видишь то, что хочешь видеть. Интересного мне не надо. Мне надо чётких определений. Какой смысл посылать человека на stackoverflow и wikipedia, когда тебя спрашивают про документацию?

> а стандарт денег стоит, да. поэтому на него очень сложно ссылки приводить.

Неужели же нет где-нибудь халявной версии? Я вот тоже поискал-поискал, да обломался.
upd: однако нет, нашёл. http://www.open-std.org/jtc1/sc22/wg14/

>> Arisu, попробуйте
>> быть снисходительным, ибо вещи, которые Вам так очевидны, мне таковыми очень
>> не кажутся.
> куда уж дальше-то? и направление поиска дал, и ключевые слова… ни разу
> не написал, что «это должны знать все, а кто не знает
> — тот лох». ан нет, мало, надо разжевать и в рот
> положить. пардон, но это уже только за деньги.

Arisu, а не звучит ли это странно после такого начала:

>> Я думаю, не с проста Вы не приводите ссылок.
> конечно: я предполагаю минимальные навыки гуглежа.

То есть мне гугль поломали, искать я не умею. А ты, значит, умеешь, но ссылки привести не можешь. Гундишь только: "обленились совсем,  всё им на блюдечке"...  Тоже мне, Д'Артаньян.

Ответить | Правка | Наверх | Cообщить модератору

164. "Проект MOOL развивает средства разработки драйверов ядра..."  +1 +/–
Сообщение от arisu (ok), 07-Окт-14, 12:45 
> Arisu, мне сдаётся, что ты видишь то, что хочешь видеть. Интересного мне
> не надо. Мне надо чётких определений. Какой смысл посылать человека на
> stackoverflow и wikipedia, когда тебя спрашивают про документацию?

что-то я запамятовал: когда мы успели трудовой договор заключить? и где моя зарплата?

> Arisu, а не звучит ли это странно после такого начала:

нет.

> То есть мне гугль поломали, искать я не умею. А ты, значит,
> умеешь, но ссылки привести не можешь. Гундишь только: "обленились совсем,  
> всё им на блюдечке"...  Тоже мне, Д'Артаньян.

Rasch abkochen, dann Vormarsch nach Sokal.

Ответить | Правка | Наверх | Cообщить модератору

166. "Проект MOOL развивает средства разработки драйверов ядра..."  –1 +/–
Сообщение от freehckemail (ok), 07-Окт-14, 12:49 
upd: стандарты
http://www.open-std.org/jtc1/sc22/wg14/
Ответить | Правка | Наверх | Cообщить модератору

180. "Проект MOOL развивает средства разработки драйверов ядра..."  +1 +/–
Сообщение от Аноним (-), 08-Окт-14, 06:55 
> upd: стандарты
> http://www.open-std.org/jtc1/sc22/wg14/

Ну вот видишь, Кэп конечно бывает редиской с его наездами, но зачастую оказывается прав. После наезда то нашлось. Вот так волшебные пинки и творят чудеса в обучении пользовании поисковиками :)

Ответить | Правка | Наверх | Cообщить модератору

183. "Проект MOOL развивает средства разработки драйверов ядра..."  +/–
Сообщение от arisu (ok), 08-Окт-14, 09:37 
только вот стандарты там маленько не качаются, и текстов нет. C11, например, купить предлагают. даже, вроде бы, и драфтов нет.
Ответить | Правка | Наверх | Cообщить модератору

160. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от dq0s4y71 (ok), 07-Окт-14, 12:40 
Это называется tentative definition. Задокументировано в стандарте C99, если вам нужно точно:

> 6.9.2 External object definitions
> ...
> A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition.Ifatranslation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0.

Это относится не только к структурам, но и, например, к массивам:

int array[];

int * ptr = array;

...

int array[10];

И это правильно :)

Ответить | Правка | К родителю #145 | Наверх | Cообщить модератору

168. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  –1 +/–
Сообщение от freehckemail (ok), 07-Окт-14, 13:28 
> Это называется tentative definition. Задокументировано в стандарте C99, если вам нужно
> точно:
>> 6.9.2 External object definitions
>> ...
>> A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition.Ifatranslation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0.
> Это относится не только к структурам, но и, например, к массивам: ...

Спасибо. Я нашёл стандарт и прочитал этот кусок. Там, вроде, не говорится о структурах.

Структуры, вообще говоря, разговор особый. Насколько я могу понять, люди обычно говорят об: объявлении(declare) структуры (struct name;), об определении(define) структуры (struct name {char* field1, char* field2};), об объявлении переменной, типом которой является структура (struct name var;) и об определении этой переменной (struct name var = {"Dmitrii", "Kashin"});

Я на выходных поищу в стандарте определение слов declare и define. Интересно посмотреть, что стандарт говорит по этому поводу.

Ответить | Правка | Наверх | Cообщить модератору

170. "Проект MOOL развивает средства разработки драйверов ядра Lin..."  +/–
Сообщение от dq0s4y71 (ok), 07-Окт-14, 14:52 
> Спасибо. Я нашёл стандарт и прочитал этот кусок. Там, вроде, не говорится о структурах.

А это, собственно говоря, относится ко всем типам. Можно написать:

int x;

int x = 1;

И это будет правильно :)

> Я на выходных поищу в стандарте определение слов declare и define. Интересно посмотреть, что стандарт говорит по этому поводу.

Интересно, что даже компиляторостроители иногда не отличают эти термины. Например, разные компиляторы называют разными словами одну и ту же ошибку:

> error: 'x' undeclared (first use in this function)
> Undefined symbol 'x' in function main

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру