Как перегрузить методы, чтобы получились аналоги get set из C#

@Lagilo · Регистрация: 17.04.2014

Студворк — интернет-сервис помощи студентам

Как можно перегрузить методы, что бы получился аналог get set из C#. Т.е. что то такое:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class A
{
 private:
       int count;
 public:
       int X
       {
           get { return x; }
       }
       A(){}
       ~A(){}
}
 
main()
{
     int y;
     A a();
     y = a.X;
}

P.S. знаю, что данный код не будет работать

@nmcf · 12.10.2015, 23:33

Сообщение от Lagilo

Вот что нужно был

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

@Fulcrum_013 · 12.10.2015, 23:33

Сообщение от nmcf

Ну здесь всё же немного не так. В C# можно назначить одно имя для свойства, а фактически оперировать с внутренним полем с другим именем.

можно и так:

C++
1
2
3
4
5
6
7
8
class Foo{
       private:
           int FBar;
       protected:
          void SetBar(int newBar);
       public:
          __property int Bar={read=FBar, write=SetBar};
}

Ну и вообще в любых комбинациях геттера и сеттера и даже отсутствия одного из них.

@Lagilo · 12.10.2015, 23:33 **[ТС]**

Сообщение от Fulcrum_013

В нормальных компиляторах делается так:

C++
1
2
3
4
5
6
7
class Foo{
       protected:
          void SetBar(int newBar);
          int GetBar();
       public:
          __property int Bar={read=GetBar, write=SetBar};
}

Во всех остальных:

C++
1
2
3
4
5
6
class Foo{
       public:
          void SetBar(int newBar);
          int GetBar();
            __declspec (property(get=GetBar,set=SetBar))int Bar;
};

Вот я только не понимаю как это работает.
Например у меня есть класс с несколькими переменными:

C++
1
2
3
4
5
6
7
class A
{
private:
       int x,y;
public:
       //что тут нужно написать, что бы можно было считывать и изменять x и y?
}

И вообще, стоит ли инкапсулировать переменные x и y? Может их просто в public засунуть? Но ведь тогда нарушаются правила ООП.

@hoggy · 12.10.2015, 23:38

Сообщение от Fulcrum_013

Да и мне тут на форуме с пеной у рта доказывали что второй вариант не мелкомягкий а часть стандарта

в стандарте пропертей нет, и никогда не было.

@Fulcrum_013 · 12.10.2015, 23:43

Сообщение от hoggy

в стандарте пропертей нет, и никогда не было.

А пора бы появиться уже лет 20 как минимум. Так же как и указателям на метод объекта.

@castaway · 12.10.2015, 23:44

Сообщение от Lagilo

Как перегрузить методы, чтобы получились аналоги get set из C#

Сообщение от Lagilo

И вообще, стоит ли инкапсулировать переменные x и y? Может их просто в public засунуть? Но ведь тогда нарушаются правила ООП.

Ты изначальный вопрос решил? Если да, то как?

@Lagilo · 12.10.2015, 23:52 **[ТС]**

Пока что вот это кажется самым близким к ответу:

C++
1
2
3
__property int Bar={read=GetBar, write=SetBar};
или
__declspec (property(get=GetBar,set=SetBar))int Bar;

Вообще, хочу заменить такую запись

C++
1
listSpere[i].set_dy(listSpere[i].get_dy()+gravitation);

на такую

C++
1
listSpere[i].set_dy+=gravitation;

@Fulcrum_013 · 12.10.2015, 23:55

Сообщение от Lagilo

Вообще, хочу заменить такую запись

Оба варианта предназначены именно для этого. Только первый борландовский, и поддерживается такой формат только C++ Builder. Второй мелкософтовский. Доступен в Visual C++ и как минимум в C++ Builder.

@castaway · 12.10.2015, 23:58

Сообщение от Lagilo

Пока что вот это кажется самым близким к ответу

Сообщение от hoggy

в стандарте пропертей нет, и никогда не было.

Сообщение от castaway

Этого нет в C++.

Тебе это о чём-то говорит?

@hoggy · 13.10.2015, 00:00

Сообщение от Fulcrum_013

А пора бы появиться уже лет 20 как минимум.

при желании их несложно завелосипедить на шаблонах.
другое дело, что они просто не востребованы.

Сообщение от Fulcrum_013

Так же как и указателям на метод объекта.

на метод класса.
поддерживаются ещё с незапамятных времен.

@Lagilo · 13.10.2015, 00:01 **[ТС]**

Сообщение от castaway

Тебе это о чём-то говорит?

Сообщение от Fulcrum_013

Originally Posted by Lagilo
Вообще, хочу заменить такую запись
Оба варианта предназначены именно для этого. Только первый борландовский, и поддерживается такой формат только C++ Builder. Второй мелкософтовский. Доступен в Visual C++ и как минимум в C++ Builder.

А изначально хотел такого добиться при помощи перегрузок.

@Fulcrum_013 · 13.10.2015, 00:13

Сообщение от hoggy

при желании их несложно завелосипедить на шаблонах.
другое дело, что они просто не востребованы.

Абалдеть. Ты в серьезные сырцы заглядывал когда нить типа фреймверков предназначенных для визуальной разработки? Они вообще только на пропертях и живут. И лисапедить ничего не надо. Надо тупо компилятору поставить табличку подстановок вызовов и полей. Да ну и еще залисапеть плиз double или std::vector в качестве индекса массива. Если и залисапетишь оно будет абсолютно нечитабельным - а соответсвенно главным источником ошибок.

Сообщение от hoggy

поддерживаются ещё с незапамятных времен.

Объекта а не класса, причем non static. Поддерживаются билдером разве что. Имеется в виду указатели вида returntype (__closure *Proc)(arglist); Залисапеженный на шаблонах костыль из лямбд это не указатель на метод объекта а обход отсутствия такового.

@hoggy · 13.10.2015, 00:28

Сообщение от Fulcrum_013

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

да. qt/mygui/cegui/etc.
1.
нет. не живут.
2.
проперти там нафиг не упали.

Сообщение от Fulcrum_013

Если и залисапетишь оно будет абсолютно нечитабельным - а соответсвенно главным источником ошибок.

дело не в читабельности.
дело в том, что они не дают ровным счетом никакого профита
в сравнении с самыми обычными геттерами/сеттерами.
в них просто нет смысла.

Сообщение от Fulcrum_013

Объекта а не класса, причем non static.

либо ваш билдер умеет рантайм-рефлексию (а он не умеет).
либо вы опять начали тупить.

крестовых указателей на функцию-член объекта не существует в природе.

Сообщение от Fulcrum_013

Имеется в виду указатели вида returntype (__closure *Proc)(arglist);

см "указатели на функции-члены".
их умеют все компиляторы ещё с бородатых времен.

Сообщение от Fulcrum_013

Залисапеженный на шаблонах костыль из лямбд

лямбды - технология компилятора,
и не имеет никакого отношения ни к указателям на функцию-член,
ни к шаблонам.

в общем, вы опять начинаете нести бред.

@Fulcrum_013 · 13.10.2015, 00:45

Сообщение от hoggy

см "указатели на функции-члены".
их умеют все компиляторы ещё с бородатых времен.

А зачем там сам класс указывается? Имеется в виду указатель на метод с произвольным типом класса, т.е с достаточностью совпадения сигнатур методов.

Добавлено через 5 минут

Сообщение от hoggy

дело не в читабельности.
дело в том, что они не дают ровным счетом никакого профита
в сравнении с самыми обычными геттерами/сеттерами.
в них просто нет смысла.

Профит даже в той же читабельности наглядно показал ТС

Сообщение от Lagilo

Вообще, хочу заменить такую запись
Код C++Выделить код
1
listSpere[i].set_dy(listSpere[i].get_dy()+gravitation);
на такую
Код C++Выделить код
1
listSpere[i].set_dy+=gravitation;

Где читабельней и понятней?
Второй профит - управление доступом к полям на чтение запись. Read only поля к примеру, без излишнего в таком случае вызова геттера.
Ну и то без чего не обойдется визувльное проектирование в принципе - эти таблички подстановки записываются компилятором в RTTI и используются инспектором объектов для визуального редактирования.

Добавлено через 3 минуты

Сообщение от hoggy

либо ваш быдлер умеет рантайм-рефлексию

Он это первый поумел. Без нее визуальное проектирование невозможно. рефлектит правда не все а только то что нужно для визуальной разработки - секцию __published

@hoggy · 13.10.2015, 00:57

Сообщение от Fulcrum_013

А зачем там сам класс указывается?

почему "жи"/"ши" пишится через "и"?
потому что правила языка.

Сообщение от Fulcrum_013

Имеется в виду указатель на метод с произвольным типом класса

таких указателей на языке не существует.

Сообщение от Fulcrum_013

т.е с достаточностью совпадения сигнатур методов.

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

не путайте понятие "указатель на функцию-член" и "делегат".
ваш
returntype (__closure *Proc)(arglist);

только выглядит как указатель.
на самом деле это - делегат.
довольно таки жалкий по своим возможностям.
но все таки, это - делегат, а не member-function-pointer.
там под капотом целая механика по связыванию объекта
с указателем-на-функцию-член.

на языке с++ существует стандартный делегат: std::function,
который предоставляет богатые возможности
по части любых связок как для свободных функций,
так и для функций-членов, и для лямбд,
и для любых других функторов.

Добавлено через 7 минут

Сообщение от Fulcrum_013

Где читабельней и понятней?

однозначно - сеттер/геттер читабельнее и понятнее.
и привычнее.

в любой цивилизованной идешке можно вбить:

C++
1
some.set

и она покажется все, что можно посетить для такого класса.

уберите префиксы "set"/"get" , и получите зоопарк имен.
и это плохо для читабельности.

Сообщение от Fulcrum_013

Read only поля к примеру, без излишнего в таком случае вызова геттера.

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

с точки зрения оптимизации:

C++
1
const some& get()const { return value; }

для компилятора это тоже самое, что и проперти, как расширения компилятора.
в обоих случаях все прекрасно inline.
и нет никаких лишних вызовов.

Сообщение от Fulcrum_013

Ну и то без чего не обойдется визувльное проектирование в принципе - эти таблички подстановки записываются компилятором в RTTI и используются инспектором объектов для визуального редактирования.

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

@Fulcrum_013 · 13.10.2015, 00:59

Сообщение от hoggy

существует стандартный делегат: std::function,

Да костыль это ДОС-овских времен, с той лишь разнице что позволяет делать функтором анонимную лябду, а не делегат.
У Бъерна явно с ООП всегда туго было. А то бы сразу понял что биндинг чего либо к делегату избыточен, все что ему передается должен передавать вызывающий, а весь этот шаблонно-лямбдовый синтаксис опять же тоже только ухудшает читабельность и ведет к ошибкам.

А вот указатели которые называются указателем на члены (с указанием типа класса) действительно не востребованы. За 20 лет которые С++ колупаю ни разу не встречал чтобы где то применялись.

Добавлено через 1 минуту

Сообщение от hoggy

но формошлепству это как то так особе не помешало.

Они появились вместе с визуальными редакторами. Кстати применяются не только для формошлепства, а для улучшения читабельности кода.

@hoggy · 13.10.2015, 01:00

Сообщение от Fulcrum_013

Он это первый поумел.

покажите пример.

Сообщение от Fulcrum_013

Без нее визуальное проектирование невозможно.

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

@Fulcrum_013 · 13.10.2015, 01:12

Сообщение от hoggy

не взирая на тот факт, что какой нибудь qt и без всякой рефлексии формошлепит,

Не ну можно поплясать с бубном в вот таком духе

C++
1
2
3
4
5
6
7
8
9
TEditInfo* __fastcall TLine::CreateEditInfo() {
    TEditInfo *Info = new TEditInfo("Line");
    Info->AddParameter("Length", SetLength, GetLength);
    Info->AddParameter("Direction", SetDirection, GetDirection);
    Info->AddParameter("Start", Start);
    Info->AddParameter("Delta", SetDelta, GetDelta);
    Info->AddParameter("End", End);
    return Info;
}

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

Добавлено через 5 минут

Сообщение от hoggy

покажите пример.

Читаем в референсе раздел RTTI

@hoggy · 13.10.2015, 01:15

Сообщение от Fulcrum_013

Да костыль это ДОС-овских времен,

вы откуда берете эту чушь?

во времена доса его ещё не существовало.
std::function вошел в стандарт начиная лишь с++11.

Сообщение от Fulcrum_013

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

это что за бред?

std::function и есть делегат.
он умеет цеплять любые функциональные объекты:
функции, функции-члены, лямбды, функторы.

ему пофигу анонимное оно там, или нет.
может цеплять как по значению, так и по ссылкам.

Сообщение от Fulcrum_013

У Бъерна явно с ООП всегда туго было. А то бы сразу понял что биндинг чего либо к делегату избыточен, все что ему передается должен передавать вызывающий

<skip>
вы сами поняли, что за бред написали,
и как это коррелирует с реальным положением дел?

Сообщение от Fulcrum_013

а весь этот шаблонно-лямбдовый синтаксис опять же тоже только ухудшает читабельность и ведет к ошибкам.

вы не осилили тип функции?
или лямбды?

что именно в следующей строке вам трудно прочитать?

C++
1
2
typedef std::function<bool(const some&)> 
    callback;

Сообщение от Fulcrum_013

А вот указатели которые называются указателем на члены (с указанием типа класса) действительно не востребованы.

ваш горячо любимый returntype (__closure *Proc)(arglist);
использует их у себя под капотом, например.

Добавлено через 1 минуту

Сообщение от Fulcrum_013

Не ну можно поплясать с бубном в вот таком духе

нафига это нужно?

Сообщение от Fulcrum_013

Читаем в референсе раздел RTTI

рантайм-идентификация-типов не имеет к рантайм-рефлексии никакого отношения.

так вы покажите пример рантайм-рефлексии?
или это так, пустые слова?

@Fulcrum_013 · 13.10.2015, 07:04

Сообщение от hoggy

для компилятора это тоже самое, что и проперти, как расширения компилятора.

А для программиста? Посчитайте количество потребных символов.

Добавлено через 2 минуты

Сообщение от hoggy

использует их у себя под капотом, например.

Смнительно. __closure хранит два указателя - на данные и на код.
вызов ассемблируется на прямую.

Добавлено через 2 минуты

Сообщение от hoggy

нафига это нужно?

Для визуального редактирования свойств. То бишь для того чтобы инспектор объектов знал названия полей и как прочитать и записать введенные в них в визуальном редакторе значения. Кстати без разницы для формошлепства или для чертежешлепства.

Добавлено через 5 минут

Сообщение от hoggy

рантайм-рефлексии

Рефлексия - от слова отражение. т.е получение списка полей и методов объектов в рантайме. Именно это и делает борландовская система RTTI. восспринимайте просто "информацию о типе" шире чем classid

Добавлено через 19 минут

Сообщение от hoggy

почему "жи"/"ши" пишится через "и"?
потому что правила языка.

В такой вариации они никому не нужны. Потому как в 99.99999999999999999% случаев можно вместо указателя на метод передать указатель на объект и вызывать любой его метод.
А передача указателя именно на метод требуется тогда когда класс-подписчик неизвестен вызывающему классу, т.е на каждом шагу.
А что касается правила языка, то правила алгоритмического языка растут из потребностей программистов. Если стандарт отстал от жизни лет на 20 то это проблемы комитета и тех производителей компиляторов которые тупо следуют стандарту. Никакие темплейты и стандартизация бибилиотек в дальнейшем развитии языка не помогут, если игнорировать эффективные и насущные потребности в расширении синтаксисиа.

Добавлено через 16 минут
А то не комитет по стандартизации получается а отдел сбыта фирмы Dinkumware

Добавлено через 14 минут

Сообщение от hoggy

вы откуда берете эту чушь?
во времена доса его ещё не существовало.
std::function вошел в стандарт начиная лишь с++11.

А вы еще не поняли откуда он взялся? Делали делегата просто - передавали указатель на просто функцию (не член) которая вызывала метод. Объект передавался или багажными данными или хранился где то в глобальной переменной, или хардкодился в зависимости от ситуации. Любители шаблонов это обтемплатили. Так и появился std::function. А те у кого в голове мозги а не шаблоны внесли соответствующее расширение в компилятор.

Добавлено через 11 минут

Сообщение от hoggy

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

А очень просто. Бъерн всегда делал упор на шаблоны допуская при этом ляпы и недоделки в ООП части, хотя и не смертельные.
Причина в принципе понятна. Но не понятно что они еще пытаются выжать из такого вспомогательного средства как шаблоны. Шаблоны нельзя ставить во главу угла так как компайл-тайм полиморфизм никогда не заменит ран-тайм полиморфизм. Поэтому основой должно быть ООП, а соответсвенно устранение в стандарте недоделок в плане синтаксиса свойств и делегатов и стандартизации рефлекшина, а шаблоны - вспомогательное средство. Но при таком подходе Dinkumware в трубу вылетит.

Добавлено через 24 минуты

Сообщение от Lagilo

И вообще, стоит ли инкапсулировать переменные x и y? Может их просто в public засунуть? Но ведь тогда нарушаются правила ООП.

Это уже зависит от сути задачи. Если при обращении к переменным необходимо выполнять какие либо еще действия (проверки, вычисления их значений) или определять переменные только для чтения (или только для записи) то стоит использовать свойства. А иначе инкапсуляция не нужна.

Сообщение от Lagilo

Вот я только не понимаю как это работает.

Да точно так же как в шарпе. Только геттер и сеттер не анонимные. т.е. пишешь методы которые производят доступ, потом секции public объявляешь фактически фиктивную переменную по правилам объявления свойств в том компиляторе который используешь и указываешь скрытые в privat геттер и сеттер (ну или закрытое поле в которое писать/читать).

Добавлено через 5 минут
Пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
class TAngle{
private:
      scalar FValue;
protected:
      scalar __fastcall GetRadians(){return Value*M_2xPI;};
      scalar __fastcall GetDegrees(){return Value*360.;};
      scalar __fastcall GetGrads(){return Value*400.;};
      scalar __fastcall GetScale(TAngleScale n){return Value*AngleScales[n];};
      scalar __fastcall GetCustomScale(scalar aScale){return Value*aScale;};
      void __fastcall SetRadians(scalar New){Value=New/M_2xPI;};
      void __fastcall SetDegrees(scalar New){Value=New/360.;};
      void __fastcall SetGrads(scalar New){Value=New/400.;};
      void __fastcall SetScale(TAngleScale n,scalar New){Value=New/AngleScales[n];};
      void __fastcall SetCustomScale(scalar aScale,scalar New){Value=New/aScale;};
      void __fastcall SetValue(scalar New){FValue=New-(int)New;if (FValue<0) FValue=1+FValue;else if (FValue==1)FValue=0;};
      TVector __fastcall GetVector(){scalar c,s; SinCos(Radians,&s,&c); return TVector(c,s,0);};
      void __fastcall SetVector(TVector New){Radians=ArcTan2(New.y,New.x);};
public:
      __property scalar Scale[TAngleScale ScaleId]={read=GetScale,write=SetScale};
      __property scalar CustomScale[scalar aScale]={read=GetCustomScale,write=SetCustomScale};
      __property scalar Radians={read=GetRadians,write=SetRadians};
      __property scalar Degrees={read=GetDegrees,write=SetDegrees};
      __property scalar Grads={read=GetGrads,write=SetGrads};
      __property TVector Vector={read=GetVector,write=SetVector};
      __property scalar Value={read=FValue,write=SetValue};
      __fastcall TAngle(){FValue=0;};
      __fastcall TAngle(scalar V){Value=V;};
};
void main(){
 TAngle a;
a.Radians=M_PI;
cout<<a.Gradus; // выведет 180
}

Добавлено через 1 час 24 минуты

Сообщение от hoggy

что именно в следующей строке вам трудно прочитать?
typedef std::function<bool(const some&)>
* * callback;

То как потом сделать вот так

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class A{
        public:
             void proca(bool value); 
};
class B{
        public:
             void procb(bool value); 
 
};
void main(){
A a;
B b;
callback c;
c=a.proca;
c(1);
c=b.procb;
c(0);
}

Добавлено через 39 минут

Сообщение от hoggy

вам нужно понять простую вещь: проперти - синтаксический сахар и не более того.

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

Добавлено через 1 час 10 минут

Сообщение от hoggy

дело не в читабельности.
дело в том, что они не дают ровным счетом никакого профита
в сравнении с самыми обычными геттерами/сеттерами.
в них просто нет смысла.

Дают повышение читабельности и скорости разработки алгоритма, плюс фактически задают таблицы RTTI

Сообщение от hoggy

уберите префиксы "set"/"get" , и получите зоопарк имен.
и это плохо для читабельности.

А они никуда не деваются. Просто переезжают в protected

Сообщение от hoggy

но на самом деле под капотом те же самые сеттеры/геттеры.
здесь нет выигрыша в эффективности.

То что у них под капотом это и ежу понятно. Но все таки гораздо читабельней
Obj.Value++;
чем
Obj.SetValue(Obj.GetValue()+1);

По этому эффективность в скорости набора кода и читабельности алгоритма налицо.

Мне деньги платят за безошибочно работающий функционал.
А вам наверное за количество символов в коде?

Добавлено через 25 минут

Сообщение от hoggy

таких указателей на языке не существует.

Комитет проспал добавление их в язык лет эдак на 35.В нормальных компиляторах С++ это сделали 20 лет назад. Добро пожаловать в эпоху событийного управления, которая началась в начале 70-х годов прошлого века.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .