Инициализация статического поля

@rikimaru2013 · Регистрация: 30.11.2013

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

Добрый день,

как объяснить необходимость объявить все статические поля, даже те у которых есть конструктор по умолчанию, вне класса до main. Почему код ниже компилятор не может сам всё порешать в 2016-ом году?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <iostream>
using namespace std;
 
 
struct Foo
{
   static int x;
};
int Foo::x;
 
int main()
{
   Foo::x;
}

IGPIGP · 30.03.2016, 00:21

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

ну так и статик точно так же определяется конструктором

Пока не увижу, - не поверю. При всём уважении.

@hoggy · 30.03.2016, 00:21

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

Это абсолютно в точности то же самое, что вы нам пытаетесь втемяшить.

это ведь вы утверждали:

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

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

я подчеркну:

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

Компилятор за вас это сделать не может - он не знает, в какой момент вы хотите выполнить нетривиальную инициализацию вашего объекта.

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

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

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

но из этого никак не следует, что:

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

говорить о функциях с более чем одним аргументом не имеет смысла

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

следуя этой аналогии дальше, приходим к противоречию с:

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

Компилятор за вас это сделать не может - он не знает

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

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

втемяшить

@TheCalligrapher · 30.03.2016, 00:24

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

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

Что означает эта фраза?

@hoggy · 30.03.2016, 00:29

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

Как-то ваши слова противоречат данному коду, где конструктором и не пахнет, а статик поле есть и используется

ну дык, а это что по вашему такое?

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

int Foo::x = 13;

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

Пока не увижу не поверю.

http://rextester.com/QSMSQ79438

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
34
35
36
37
#include <iostream>
 
struct foo
{
    foo() { 
        std::cout <<"foo: я - статический член класса,"
        " и я проинициализировался конструктором\n";
    } 
};
 
struct bar
{
    bar() { 
        std::cout <<"bar: я - обычный член класса,"
        " и я проинициализировался конструктором\n";
    } 
};
 
template<class T, class U>
struct trololo
{
    T b; 
    static U f;
};
 
template<class T, class U>
U trololo<T,U>::f;
    
 
 
int main()
{
    std::cout << "Hello, world!\n";
    
    trololo<bar, foo> ololo;
    trololo<bar, foo>::f;
}

Добавлено через 46 секунд

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

Что означает эта фраза?

в контексте господина IGPIGP - объект конструируется при помощи конструктора.

@rikimaru2013 · 30.03.2016, 00:34 **[ТС]**

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

ну дык, а это что по вашему такое?

инициализация (определение как подправил бы Croessmah меня ) фундаментального типа у которого нету конструктора )))))))))))))))))))))))))))

@hoggy · 30.03.2016, 00:38

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

инициализация фундаментального типа у которого нету конструктора

все у него есть.
и даже не один.
одних только дефолтных конструкторов - две штуки,
с двумя разными поведениями.

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

http://rextester.com/PDK55092

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
#include <iostream>
 
template<class T> void foo(T t)
{
    t.~T();
};
 
int main()
{
    std::cout << "Hello, world!\n";
    
    foo<int>(10);
}

IGPIGP · 30.03.2016, 00:39

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

С локальными статик полями, как-то множественная инициализация(о которой вы так писали) не происходит

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

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
#include <iostream>
using namespace std;
 
struct First
{
static int first;
};
//int First::first=Second::second+Third::third;//тут не видно Second и Third
struct Second
{
static int second;
};
 
struct Third
{
static int third;
};
int First::first=Second::second+Third::third;
int Second::second=1;
int Third::third=2;
 
int main(int argc, char* argv[])
{
cout<<First::first;//3
cout<<endl;
system("pause");
return 0;
}

@TheCalligrapher · 30.03.2016, 00:49

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

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

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

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

в каком именно порядке будут вычислены конкретные аргументы конкретной функции.
и программист ему для этого не нужен.

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

круг замкнулся.

Тут уж совсем какой-то отрыв от логики повествования пошел. Я не смог расшифровать.

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

Более того, уясните простую вещь: если оторваться от требований стандартной С++ машины, то ни в языке С, ни в языке С++ вообще нет никакого порядка, кроме порядка возникновения наблюдаемого поведения (observable behavior), которое сводится к выполнению операций ввода-вывода и доступу к volatile объектам. Все остальное - лишь частично упорядочивающие абстракции, определяющие общую семантику операций, а не порядок их выполнения. И в ряду таких частично упорядочивающих абстракций порядок инициализации статических объектов никак не выделяется ни в худшую, ни в лучшую сторону. Как не выделяется и порядок вычисления аргументов функции или подвыражений в выражении.

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

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

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

Совершено не верно. Опять какие-то ненужные доморощенные теории пошли. Не надо путать С++ с Джавой.

Конструкторы в С++ могу быть только у класс-типов. Никаких конструкторов у скалярных типов нет и никогда не было.

Программирование шаблонов в этой области унифицировано на чисто синтаксическом уровне: на уровне общего синтаксиса инициализации (и общего синтаксиса вызова псевдодеструктора). Никаких "фиктивных конструкторов" тут нет и выдумывать их на ровном месте не надо. Это никому не нужно.

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

одних только дефолтных конструкторов - две штуки,

Белиберда как терминологическая, так и в общем.

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

и отвечают общим требованиям: иметь конструкторы, деструкторы, и тп.
и если бы это было не так

Совершенно не верно. Еще раз: конструкторы и деструкторы в С++ есть только у класс-типов и больше нигде.

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

тогда программирование на шаблонах превратилось бы в Адь и Израиль.

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

IGPIGP · 30.03.2016, 00:50

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

struct foo

Вы можете заставить конструктор изменять собственное статическое поле. Это не подвиг. Но лучше это делать сеттером. Не придётся ради этого объект создавать. То есть, такое поведение может быть только у объектов класса, которые изменяют статические поля при своём появлении. Если задуматься о том, откуда такой объект может знать о том, как менять такое поле, то можно сделать вывод, что это относится к полям, описывающим сам акт рождения объекта, в отношении ко всем существующим. Например, счётчик объектов. Это может быть, но круг подобных полей ограничен.
Что касается шаблонов, то они описывают не объект, а совокупность классов, каждый из которых может описывать объект. То есть, инстанс они описывают. Сравнение шаблона с классом, в этом смысле, мне не кажется корректным.

@hoggy · 30.03.2016, 01:00

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

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

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

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

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

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

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

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

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

Меня ваш глобальный порядок (точнее, его отсутствие) совершенно не расстраивает.

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

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

Более того, уясните простую вещь

не понятно, к чему это было сказано.

@TheCalligrapher · 30.03.2016, 01:03

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

в контексте господина IGPIGP - объект конструируется при помощи конструктора.

Опять какая-то оторванный от темы поток текста.

"Господин IGPIGP" открыто сказал, что инициализация нестатических полей класса описывается конструктором их класса-хозяина.

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

После чего вы привели какой-то пример кода, который вообще никаким боком к этому вопросу не относится. К чему это?

@hoggy · 30.03.2016, 01:16

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

Никаких "фиктивных конструкторов" тут нет и выдумывать их на ровном месте не надо.

"фиктивный конструктор", или по другому "не настоящий" как бе именно это и означает:

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

унифицировано на чисто синтаксическом уровне: на уровне общего синтаксиса инициализации (и общего синтаксиса вызова псевдодеструктора)

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

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

Белиберда как терминологическая, так и в общем.

вы там что-то выше вещали о "наблюдаемом поведении".

вот здесь я наблюдаю два разных поведения:

C++
1
2
3
4
5
6
7
8
9
10
11
12
#include <iostream>
 
int main()
{
    std::cout << "Hello, world!\n";
    
    int a; //<--- дефолтный ничего не делающий конструктор
       // мусор
       
    int b = int(); // <--- дефолтный конструктор
       // инициализация нулём
}

особенно это критично где нибудь в шаблонах.
из-за практических соображений.

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

Ничего ни в какой "Адь и Израиль", как видите, не превратилось и без конструкторов.

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

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

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

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

в стандарте сказано: примитивы косят под полноценные оо-типы.

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

о да, шандец просто противоречие.

@TheCalligrapher · 30.03.2016, 01:16

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

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

Что за белиберда? Это заявление из разряда "на примере оператора sizeof мы видим, что строковые функции стандартной библиотеки уже давно научились вычислять размер объекта без попутного форматирования жесткого диска".

Это замечательно. Но мне совершенно не интересно, что там компиляторы научились делать в шаблонах, как мне совершенно не интересно, что там компиляторы научились делать в sizeof.

В шаблонах компиляторы научились лишь бороться с множественным выделением памяти для одного и того же объекта (или функции). Я же ясно и четко сказал в самом начале: требование явного объявления статического объекта не имеет ни какого отношения к борьбе с множественным выделением памяти. Поэтому зачем вы нам постоянно дылдоните про то, что "компиляторы научились" - мне не ясно. Это не имеете никакого отношения к рассматриваемому вопросу.

Речь же идет о том, что порядок инициализации статических объектов частично упорядочен и это частичный порядок подчинен мне и моему замыслу. И ни о каком "компиляторы научились" речи быть не может, ибо моего замысла компилятор не знает и знать не может. (Это даже не говоря о том, что при желании я могу до той же степени также упорядочить и шаблонную инициализацию через явную инстанциацию.)

@hoggy · 30.03.2016, 01:21

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

Но лучше это делать сеттером.

казалось бы... при чем тут инициализация статика...

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

"Господин IGPIGP" открыто сказал, что инициализация нестатических полей класса описывается конструктором их класса-хозяина.
Вы заявили, что то же самое справедливо и для статических полей класса, вызвав тем самым всеобщее недоумение.

не знаю насчет всеобщего.
но сейчас недоумение у меня вызываете вы.

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

IGPIGP · 30.03.2016, 01:30

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

казалось бы... при чем тут инициализация статика...

Да при том что статический член не создаётся с объектом. А изменить (установить) его при рождении объекта можно.
То есть я не понимаю фразы о том "ну так и статик точно так же определяется конструктором" и об этом говорю.

@TheCalligrapher · 30.03.2016, 01:34

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

"фиктивный конструктор", или по другому "не настоящий" как бе именно это и означает:

Это классно. Но это выдуманная вами лично на ровном месте сущность. Она никому не нужна. В языке С++ все прекрасно и стройно объясняется без ваших выдумок о "фиктивных конструкторах".

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

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

Ой, не смешите меня! Зачем нам какие-то асмо выхлопы? У языка есть стандарт, где все черным по белому написано. В стандарте языка ясно сказано, что конструкторы существовать только у класс-типов. Тема закрыта.

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

вот здесь я наблюдаю два разных поведения:

C++
1
2
3
4
int a; //<--- дефолтный ничего не делающий конструктор
       // мусор
int b = int(); // <--- дефолтный конструктор
       // инициализация нулём

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

В спецификации же языка просто сказано, что локальный скалярный объект без инициализатора содержит неопределенное значение.

И в спецификации же языка просто сказано, что выражение T() порождает value-initialized значение типа T, value-initialization для int сводится к инициализации нулем.

Нигде никак не упоминается никаких конструкторов.

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

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

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

А вот "правдоподобная имитация полноценного оо-типа" существует только в вашем воображении. Вы с чего-то принялись расценивать обычный С++ синтаксис, как какой-то "ОО". Никакого отношения ни к какому "ОО" ничего из этого не имеет.

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

в стандарте сказано: примитивы косят под полноценные оо-типы.

Что за белиберда? В стандарте где-то называют примитивные типы "неполноценными"? Цитату приведите-ка про это ваше косят.

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

Примеры таких выдуманных сущностей есть: двухфазный поиск имен в шаблонах (two-phаse lookup) - в стандарте отсутствует как самостоятельная концепция, но полезна, как понятный альтернативный способ описания поиска. Таблицы виртуальных методов - то же самое. Принцип SFINAE - то же самое. Понятие "универсальной ссылки" (universal reference) Мейерса - тоже.

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

@hoggy · 30.03.2016, 01:39

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

Что за белиберда? Это заявление из разряда "на примере оператора sizeof мы видим, что строковые функции стандартной библиотеки уже давно научились вычислять размер объекта без попутного форматирования жесткого диска".

давайте определимся:
вы сейчас троллите, или тупите?

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

В шаблонах компиляторы научились лишь бороться с множественным выделением памяти для одного и того же объекта (или функции). Я же ясно и четко сказал в самом начале: требование явного объявления статического объекта не имеет ни какого отношения к борьбе с множественным выделением памяти. Поэтому зачем вы нам постоянно дылдоните про то, что "компиляторы научились" - мне не ясно. Это не имеете никакого отношения к рассматриваемому вопросу.

имеет.
раз до сих пор не понятно, тогда я поясню.

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

1.
прежде всего необходимо решить проблему множественного определения.

2.
определить момент инициализации такого члена
в рамках одной единицы трансляции.

в настоящий момент оби эти технические задачи решены.

порядок в рамках 1 ед. трансляции как и прежде - в порядке объявления.
множеств

пример возможного дизайна:

C++
1
2
3
4
5
6
7
8
int gValue = 10;    // 1
 
struct some
{
    static sValue = gValue;  //2 
};
 
int gBack = some::sValue;  //3

проблему ODR можно порешать точно так же,
как это сделано для шаблонов.

резюмируя:
в настоящий момент нет никаких технических ограничений.

это просто тупо не реализовано и все.

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

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

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

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

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

Да при том что статический член не создаётся с объектом. А изменить (установить) его при рождении объекта можно.
То есть я не понимаю фразы о том "ну так и статик точно так же определяется конструктором" и об этом говорю.

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

ни у обычных классов,
ни у шаблонных.

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

представьте себе, что это будет происходить прямо в декларации класса:

было так:

C++
1
2
3
4
5
struct foo
{
    static bar b;
};
bar foo::b(10); //<---- мы указали чем хотим инициализировать

стало так:

C++
1
2
3
4
struct foo
{
    static bar b(10); //<---- мы указали чем хотим инициализировать
};

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

IGPIGP · 30.03.2016, 01:52

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

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

Ну то есть, дело не в конструкторах. В теле класса можно бы реализовать инициализацию статического члена. Но это сокращение возможностей. Ведь статический член данных, это статическая переменная, прикрытая пространством имени класса, + модификатор доступа. На этом суверенитет класса над ней прекращается. То есть, степень обусловленности её принадлежности классу, значительно ниже чем у данных объекта. Зачем же сокращать область видимости определения статической переменной? По сути, она объявлена в классе, чтобы не захламлять пространство имён программы и для того, чтобы её объявление не болталось, где попало. Лишь наличие модификатора доступа, отличает её от статических переменных объявленных в пространствах имён.
Фактически, разговор сводится к тому, чтобы сократить возможности ради внешних признаков. Так мне кажется.

@hoggy · 30.03.2016, 01:59

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

Это классно. Но это выдуманная вами лично на ровном месте сущность. Она никому не нужна. В языке С++ все прекрасно и стройно объясняется без ваших выдумок о "фиктивных конструкторах".

это такая же выдуманная мною сущность,
как и ваши "псевдодеструкторы", или "синтаксические уровни".

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

Это потому, что вы выдумали доморощенную теорию - химеру - про некие "фиктивные конструкторы"

это не теория.
это - практика.

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

И в спецификации же языка просто сказано, что выражение T() порождает value-initialized значение типа T, value-initialization для int сводится к инициализации нулем.

это как то противоречит "фиктивным конструкторам" ?

вот это ваше "выражение T()" - назовите мне хотя бы одну причину,
по которой я не могу воспринимать его как вызов конструктора для некого T?

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

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

Мне прекрасно очевидно, для чего это сделано.

ну так давайте, говорите.
зачем это было сделано.

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

А вот "правдоподобная имитация полноценного оо-типа" существует только в вашем воображении. Вы с чего-то принялись расценивать обычный С++ синтаксис, как какой-то "ОО". Никакого отношения ни к какому "ОО" ничего из этого не имеет.

вот сейчас это уже похоже на откровенный бред.

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

Что за белиберда?

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

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

В стандарте где-то называют примитивные типы "неполноценными"?

я писал о полноценных оо-типах.
они не являются классами.
цитатку поищите сами.

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

Но увы, таковой ценностью они не обладают. Стандартная система концепций и проще, и понятнее.

а вот это уже троллинг.

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

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

Но это сокращение возможностей.

нет никаких сокращений возможностей.

хотите - определяйте как раньше в спп.
хотите - определяйте в хедере
а хотите - определяйте прямо в классе.

IGPIGP · 30.03.2016, 02:06

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

хотите - определяйте как раньше в спп.
хотите - определяйте в хедере
а хотите - определяйте прямо в классе.

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

Новые блоги и статьи Все статьи Все блоги /
Запрет пометки на удаление и отмены проведения Maks 16.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "ПутевойЛист" разработанного в КА2. Задача: запретить помечать на удаление и отменять проведения путевого листа при условии, если он сдан. . .	Как надо было делать правильно - вообще не слушать ИИ, его дело - текст. Hrethgir 15.07.2026 А вообще надо было делать не так, чтобы не исправлять ошибку https:/ / www. cyberforum. ru/ blogs/ 223907/ 10996. html , правильно было : удалил кнопку, а потом добавил её. Всё это стресс конечно. Почему?. . .	Знаете, от чего появляется стресс? kumehtar 15.07.2026 Стресс появляется оттого, что вы, зная как поступить правильно, делаете наоборот. Ларри Уингет	Нас бьют, а мы крепчаем? Какая чушь! kumehtar 15.07.2026 Вот это вот бытующее мнение, что человек меняется только под действием проблем, всегда считал вредоносным. Поверь, от проблем у людей появляются не изменения, а нервное расстройство и ПТСР. А. . .
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .