Прямая инициализация в C++ и функция-конструктор в Javascript

@Timurs · Регистрация: 23.02.2016

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

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

C++
1
Rabbit Bugs_Bunny = new Rabbit('Bugs Bunny');

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

p.s. https://learn.javascript.ru/fu... onstructor
p.p.s. https://learn.javascript.ru/cl... a-funktsii

@Fulcrum_013 · 09.04.2020, 19:58

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

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

То что он заинлайнен никакого отношения к тому что там написан именно вызов именно конструктора не имеет.

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

"а в ответ - тишина". Видимо, идет срочное развитие "теорий" )))

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

Croessmah · 09.04.2020, 19:59

Не по теме:

TheCalligrapher, эти господа так просто не сдадутся. Сейчас будет сказ про уток, кряканье и unsafe c++ и еще много интересного. Ждем.

@Fulcrum_013 · 09.04.2020, 20:03

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

Абсолютно, грубейше не верно.

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

@TheCalligrapher · 09.04.2020, 20:17

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

А в ответ как раз и есть ньюанс для тривиальных типов [...] его когда то давно давно убрали. [...]Потом опомнились [...] не будет фейковых (ака тривиальные) конструкторов у тривиальных типов все метапрограммирование накроется медным тазом.

Баюн вы наш, я уже закрыл эту тему раньше: Что возвращает конструктор?

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

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

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

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

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

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

В языке С++ неинициализированная переменная содержит indeterminate value, доступ к которому в общем случае приводит к неопределенному поведению. В частных случаях, когда доступ не приводит к неопределенному поведению (unsigned char переменные), значение не является стабильным, т.е. последовательные чтения одной и той же переменной могут читать разные значения.

@Fulcrum_013 · 09.04.2020, 20:27

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

В POD классах, являющихся фактически аналогом голых сишных структур, конструктор по умолчанию тривиален, т.е. существует чисто концептуально. Он ничего не делает и никакого кода не порождает. Физически его не существует. А номинальное его существование нужно лишь для упрощения формального изложения в тексте стандарта языка. Текст становится намного проще.

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

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

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

Каким образом оно может изменится если туда никто не пишет то? Такое возможно разве что при разделении памяти по времени жизни объектов.

@hoggy · 09.04.2020, 20:29

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

Абсолютно, грубейше не верно. Между неинициализированными объектами и инициализированными объектами (путь даже мусором в последнем случае) в С и С++ существует гигантское фундаментальное отличие.

такое впечаление, что ты вообще не вчитываешься, что я тебе пишу.

речь не о различии между инициализированными и не инициализированными объектами.
речь о том, что:

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

любая форма инициализации приводит к полной инициализации памяти объекта.

любое отклонение от этого правила - есть UB

нельзя проинициализировать объект наполовину.

однако, важно понимать:
проинициализированный объект - это объект, чъё время жизни началось (готов к работе)
а вовсе не тот объект, для которого каждый без исключения байт был чем то записан.

и если в каком то частном случае тебя устраивает,
что память может содержать мусор - почему нет?

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

пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <iostream>
#include <string>
 
struct sample
{
    sample(): name("trololo")  {}
 
    void work(const int v)
    {
        value = v;
        // work...
    }
    
    std::string name;
    int value;
};
 
int main()
{
    sample object; 
    // <--- здесь объект уже построен, и готов к работе
    object.work(333);
}

в связи с чем не очень то понятно:

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

Агрегатная инициализация ещё со времён С работает по принципу "все или ничего". Частичная инициализация агрегата пользователем всегда приводит к его полной инициализации (напр. к обнулению).
Никогда и нигде в С++ компилятор не генерирует таких дефолтных конструкторов.

каких "таких" ?

C++
1
2
3
4
5
6
7
8
9
struct sample
{
    std::string name;
};
 
...
 
sample object; // о боже! компилятор сгенерировал дефолтный конструктор
// который занулил std::string

@TheCalligrapher · 09.04.2020, 20:51

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

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

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

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

Каким образом оно может изменится если туда никто не пишет то? Такое возможно разве что при разделении памяти по времени жизни объектов.

"Каким образом" - не это стандарт языка ответа не дает. Зачем?

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
  int a, b;
 
  a = 5; // 1. начало области детерминированного значения `a` (начало value-lifetime `a`)
 
  printf("%d\n", b); // 2. чтение недетерминированного значения `b`
  a = 42;            // 3
  printf("%d\n", b); // 4. чтение недетерминированного значения `b`
 
  // 5. после этой точки доcтупа к `a` нет (конец value-lifetime `a`)
 
  b = 10; // 6. начало области детерминированного значения `b` (начало value-lifetime `b`)
  ...
} // 7. конец value-lifetime `b`

В такой ситуации компилятор может сообразить, что переменные a и b имеют непересекающиеся value-lifetime, т.е. не требуют отдельных ячеек в хранилище. Например, он может назначить им один и тот же процессорный регистр. В результате чтение значения b в точках 2 и 4 будет на самом деле видеть значение a. То есть значение b будет "магически" меняться.

Другими словами, вы были близки к истине "при разделении памяти по времени жизни объектов." Разделение памяти в языка С и С+ на само деле делается не "по времени жизни объектов", как вы наивно полагали, а по времени детерминированности их значений, т.е. по т.наз. value-lifetime. Стандарт языка специально построен так, чтобы позволить компиляторам делать разделение памяти по value-lifetime. И свойства indeterminate value, которые я описал выше, ориентированы именно на это.

В DR#451 для С, посвященному именно нестабильности indeterminate values, подробно объяснено еще масса нюансов на эту тему: http://www.open-std.org/Jtc1/s... dr_451.htm

@Fulcrum_013 · 09.04.2020, 21:03

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

"Каким образом" - не это стандарт языка ответа не дает. Зачем?

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

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

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

когда две переменные имеют пересекающиеся области видимости, но не пересекающиеся области "детерминированного значения"

каким боком стабильность зависит от осмысленности значения? Лежит се мусор. Ну неизвестно какой. Но лежать он будет стабильно.

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

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

В такой ситуации компилятор может сообразить, что переменные a и b имеют непересекающиеся value-lifetime, т.е. не требуют отдельных ячеек в хранилище. Например, он может назначить им один и тот же процессорный регистр. В результате чтение значения b в точках 2 и 4 будет на самом деле видеть значение a. То есть значение b будет "магически" меняться.

Ну дак об этом и речь - разделение памяти по времени жизни. Мы же говорим о времени жизни объекта с момента его появления в скопе до момента его выхода. Его значение в этот промежуток времени всегда стабильно вне зависимости от того в каких полях оставили мусор. Любые ссылки на объект вне этих пределов времени не валидны и обращение по ним уже само по себе UВ.
Т.е. вообще строго говоря объект существует от начала работы конструктора и до конца работы деструктора.Даже если какой то из этих граждан тривиальный. А соответсвенно и конструктор и деструктор концептуально есть абсолютно у всего. И то что они тривиальные абсолютно ничего в этом плане не меняет. Это банально интерфейс работы с объектами. Либо он един для всего либо метапрограммирование можно отправлять на свалку истории.

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

@TheCalligrapher · 09.04.2020, 21:09

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

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

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

Мне кажется, что вы недостаточно плотно работаете с моими постами. Сколько раз вы законспектировали мой предыдущий пост? Без конспектирования толка не будет.

И да, кстати, понятие неопределенного поведения в С и С++ включает в себя и "потоки инопланетного происхождения, бегающие по памяти". Привыкайте.

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

Люди в коммитете вообще то более менее адекватные и для того чтобы было такое определение должна быть причина.

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

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

А причина может быть только одна - разделение памяти объектов по времени жизни.

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

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

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

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

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

Т.е. вообще строго говоря объект существует от начала работы конструктора и до конца работы деструктора.

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

@Fulcrum_013 · 09.04.2020, 21:19

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

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

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

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

Я уже привел вам очевидный контрпример.

Вы вообще суть термина "разделение ресурса по времени" понимаете?

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

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

Нет, конечно. Я уже привел вам очевидный контрпример.

Который показывает только то что я вам уже второй час толдычу - нестабильность в течение времени жизни объекта невозможна. Мусор который лежал в b тем же самым мусором и останется.

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

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

Время детерминированности значения - более узкое время, чем время жизни.

При этом шире чем время жизни объект не существует. Может существовать только буфер памяти который объектом не является. Любые обращения вне этих пределов есть UB - вне этих пределов объект в общем случае неработоспособен.

@TheCalligrapher · 09.04.2020, 21:24

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

Но при этом оно будет стабильным.

Нет. Недетерминированное значение не является стабильным.

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

Мало того синтаксис не позволит обратится к объекту до начала его существования вообще никак, и не позволит обратится по имени после конца его существования. Существование же ссылки на уничтоженный объект - уже само по себе UB.

Поток слов.

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

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

Который показывает только то что я вам уже второй час толдычу - нестабильность в течение времени жизни объекта невозможна.

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

И ссылку на DR#451 с объяснениями комитета по стандартизации С давали, и C++ DR (http://www.open-std.org/jtc1/s... n3714.html) ясно говорит "The value may be different each time the lvalue-to-rvalue conversion is applied to the object.", и пример привели, понятие неопределенного поведения вбиваем снова и снова в эти бошки... Но все как об стенку горох...

@Fulcrum_013 · 09.04.2020, 21:25

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

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

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

Croessmah · 09.04.2020, 21:27

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

С чего ему вдруг изменяться самому по себе в течение жизни объекта?

TheCalligrapher, так?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <iostream>
 
 
struct F
{
    [[no_unique_address]] int f;
};
 
 
int main()
{
    F f;
    int b;
    std::cout << b << std::endl;
    f.f = 10;
    std::cout << b << std::endl;    
}

prog.cc:14:18: warning: variable 'b' is uninitialized when used here [-Wuninitialized]
std::cout << b << std::endl;
^
prog.cc:13:10: note: initialize the variable 'b' to silence this warning
int b;
^
= 0
1 warning generated.
-496600312
-846379136

https://wandbox.org/permlink/d1Ze86bbLjwOetzf

@TheCalligrapher · 09.04.2020, 21:46

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

Недетерменированность - лежит случайное непредсказуемое значение. Нестабильность - значение изменяется.

Повторяю в сотый раз: языки С и С++ не гарантируют стабильности недетерминированного значения. Недетерминированное значение в С и С++ нестабильно.

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

С чего ему вдруг изменяться самому по себе в течение жизни объекта?

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

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

В это время в эту же память никто другой писать не может.

Может, разумеется )) Я уже привел вам очевидный пример. Когда возникает неопределенное поведение - можно все.

---

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

так?

Интересно, кстати, поступает Clang

C
1
2
3
4
5
6
7
8
#include <stdio.h>
 
int main()
{
    int f;
    printf("%d\n", f);
    return f;
}

http://coliru.stacked-crooked.... bdc38799e2

Видя, что значение f неинициализировано, он просто в конце main генерирует tail call к printf через jmp. В результате в качестве возвращаемого значения main подставляется возвращаемого значение printf. То есть печатается одно "значение" f, а из main возвращается совсем другое "значение" f )))

@Fulcrum_013 · 09.04.2020, 21:46

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

Когда возникает неопределенное поведение - можно все.

Когда возникает неопределенное поведение программа по определению не валидна. Поэтому грамотные копиляторы отказываются ваш пример компилять напрочь.
1>------ Build started: Project: ConsoleApplication7, Configuration: Debug Win32 ------
1>ConsoleApplication7.cpp
1>C:\Users\fulcr\source\repos\ConsoleApp lication7\ConsoleApplication7.cpp(19): error C4700: uninitialized local variable 'b' used
1>Done building project "ConsoleApplication7.vcxproj" -- FAILED.

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

@TheCalligrapher · 09.04.2020, 21:52

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

Когда возникает неопределенное поведение программа по определению не валидна.

Так мы про это и говорим. Доступ к indeterminate value - неопределенное поведение (кроме доступа к unsigned char)

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

Поэтому грамотные копиляторы отказываются ваш пример компилять напрочь.

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

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

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

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

Как я уже сказа выше, изобретать свои доморощенные теории вам никто не запрещает. Но навязывать их кому-то под видом канона вам никто не даст.

Croessmah · 09.04.2020, 22:02

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

Интересно, кстати, поступает Clang

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

C++
1
2
3
4
5
6
#include <stdio.h>
 
int main()
{
    return 546654;
}

94

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

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

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

Нет, не оно.

Assembler
1
2
3
4
5
6
main:                                   # @main
        mov     edi, offset .L.str
        xor     eax, eax
        jmp     printf                  # TAILCALL
.L.str:
        .asciz  "%x\n"

Почему-то я пропустил ваш текст с jmp.

@TheCalligrapher · 09.04.2020, 22:03

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

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

Нет, в данном случае хорошо видно, что сделал Clang: https://godbolt.org/z/CrU6VB

То есть возвращаемое значение - это не последний байт "мусора", а именно количество символов, выведенное printf.

@Fulcrum_013 · 09.04.2020, 22:04

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

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

C++
1
2
3
4
5
6
7
8
9
10
#include <iostream>
template <class T> struct foo {
    T a = T();
};
 
int main()
{    
    std::cout << foo<int>().a << std::endl;
    
}

И что же тогда происходит в 3-ей строке? Если нет конструктора (хотя бы тривиальной заплатки) то почему не генерится соответсвующая ошибка?

Croessmah · 09.04.2020, 22:09

TheCalligrapher, да, да. Я протупил и как-то умудрился пропустить первое предложение после вашего кода. Не серчайте.

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

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

И что же тогда происходит в 3-ей строке?

Не поверишь, но это не вызов конструктора вне зависимости от используемого объектного типа.

Выражения Type() - это Explicit type conversion (functional notation). В твоем случае, это приводит к direct-initialization с опущенным expression-list. Ну а чтобы понять что там будет, читай правила прямой инициализации.

P.S. Это я конкретно о T(), а не о T a = ....

Новые блоги и статьи Все статьи Все блоги /
интеграция AnyLogic с самописным REST API и переход на Odoo anaschu 03.07.2026 Успешная интеграция AnyLogic с самописным REST API и переход на промышленную Odoo WMS Сегодня проделал огромный путь от простой симуляции физических процессов до построения полноценной. . .	Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .	Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .	rest api anylogic - выполнение модели на своём русском сайте anaschu 02.07.2026 Как подружиться с AnyLogic Cloud API, победить провайдеров и развернуться Java-бэкенд в Docker на бесплатном хостинге: Двухдневный лог борьбы Всем привет! Хочу поделиться свежим (и довольно. . .
Где деньги лежат kumehtar 02.07.2026 Это - японская подводная лодка I-52 (тип C2, кодовое имя Momi) вышла из Японии в марте 1944 года с миссией в оккупированную немцами Францию (Лорьян). Это была одна из «Янаги»-миссий по обмену. . .	Krabik для WoW 3.3.5a, многоязычный AmbA 02.07.2026 Допилил бота, думаю что окончательно. Изменения: - добавлена многоязычность - добавлено снятие скриншотов - добавлено поддержание бафов хождения по воде (для жреца, дк и шамана) - и так, по. . .	Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .

Croessmah
	09.04.2020, 19:59
	Не по теме: TheCalligrapher, эти господа так просто не сдадутся. Сейчас будет сказ про уток, кряканье и unsafe c++ и еще много интересного. Ждем. 0