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

@streamc · Регистрация: 23.11.2010

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

Engine.h

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
namespace Engine
{
    class ICE
 
    {
    public:
        
            std::vector<int> M_init;
        std::vector<int> V_init;
 
        ICE(std::vector<int> M_init1, V_init1;)
 
        {
            M_init = M_init1;
            V_init = V_init1;
 
        };
    void print()
        {
            for (int i = 0; i < M_init.size(); i++) 
            {
                std::cout << M_init[i] << " "; 
                std::cout << V_init[i] << " ";
            }
                
        }
    };
 
}

C++
1
2
3
4
5
6
7
8
9
10
11
int main()
{
    
    std::vector<int> M1_init = { 20, 76, 100, 105, 74, 0 };
    std::vector<int> V1_init = { 20, 76, 100, 105, 74, 0 };
    Engine::ICE ICE_Inst(M1_init, V1_init); //not work empty
 
    double time_cnt = Dyno::Engine_Init<Engine::ICE >(ICE_Inst, Temp_Env).Engine_Work();  
 
    
}

Dyno.h

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
namespace Dyno
{
 
template<class T>
    class Engine_Init
    {
    public:
        T engine; 
 
        Engine_Init(T engine, double Temp_Env);
        double Engine_Work(bool flag);
 
    };
    
    
        Engine_Init<T>::Engine_Init(T engine, double Temp_Env)
    {
        T_Engine = Temp_Env;
        this->Temp_Env = Temp_Env;              
    }
    
}

No appropriate default constructor available
Есть класс Engine с конструктором из двух параметров. Но по какой то причине функция из другого неймпспейса
Dyno::Engine_Init<Engine::ICE >(ICE_Inst, T_Env).Engine_Work(1) в главном меню не использует векторы V_init, M_init из main-функции, задаваемые в Engine_Init извне.
Да, могу поменять ICE(std::vector<int> M_init1 , std::vector<int> V_init1 ) {} на ICE(std::vector<int> M_init1={1,2,3} , std::vector<int> V_init1={1,2,3} )
И он будет использовать именно эти числа, а не то, что я передал из main-функции.
Кстати, функция print выдает, как нужно именно, значения из main

IGPIGP · 02.06.2019, 20:04

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

На данном примере исправляю на

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

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

Хотя шаблоны это не меняют.

меняют. Но нужен опыт для того чтобы определить интерфейс и отделить его от наборов частных параметров так, чтобы в обобщённых алгоритмах не было необходимости обращаться к этим частностям. Пока вполне достаточно было бы не шаблонного класса содержащего поле ICE. Что толку в шаблоне пока вы не видите десятка разновидностей, - дизель, карбюраторный, инжекторный, роторный (Ванкеля, например), электрический, комбинированные (семейство), пропеллерный, реактивный, фотонный и пр. И в следствие, не видите для них обобщения в контексте решаемой задачи. В хорошем проекте, чтобы понять его структуру и уточнить техзадание, полезно сначала решить в конкретных типах. Тогда уже легче будет параметризовать.

@streamc · 02.06.2019, 20:21 **[ТС]**

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

и снова нет использования параметра enginex. Значит поле останется не инициализированым.

Не понял

C++
1
2
3
4
5
6
Engine_Init::Engine_Init(Engine::ICE  enginex_, double T_Env) 
    {       
        enginex = enginex_;
        T_Engine = T_Env;
        this->T_Env = T_Env;                
    }

А это что? Нет, тут, как раз не опечатка
Опечатки касались вещей не главных.

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

интерфейс и отделить его от наборов частных параметров так, чтобы в обобщённых алгоритмах не было необходимости обращаться к этим частностям

Ох, еще и интерфейс, но да, это основная цель шаблонов, кто ж спорит то.

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

пока вы не видите десятка разновидностей

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

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

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

Да, согласен. Скажем, тот же ДВС разделить на несколько типов и подтипов (дизель, ванкель, Аткинсо, Отто, .... , обычный, обычный с турбиной, , а потом уже добавлять. И даже марки могут быть разные у двигателей или некоторые версии одного двигателя.

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

полезно сначала решить в конкретных типах

Очень хорошо.

IGPIGP · 02.06.2019, 22:10

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

А это что? Нет, тут, как раз не опечатка

У вас со зрением как? В посте где вы пишете:

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

На данном примере исправляю на

вы показываете код:

C++
1
2
3
4
5
Engine_Init::Engine_Init(Engine::ICE  enginex, double T_Env) 
    {       
        T_Engine = T_Env;
        this->T_Env = T_Env;                
    }

а теперь пишете: -"не понял". И код:

C++
1
2
3
4
5
6
Engine_Init::Engine_Init(Engine::ICE  enginex_, double T_Env) 
    {       
        enginex = enginex_;
        T_Engine = T_Env;
        this->T_Env = T_Env;                
    }

после того как вас ткнули а то что enginex так и не был инициализирован. А ещё удивляетесь, что для того чтобы вам объяснить что-то нужно по десять раз повторять. А потом еще десять раз. Про константные ссылки и списки инициализаци, видимо и 100 раз недостаточно.

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

Ох, еще и интерфейс, но да, это основная цель шаблонов, кто ж спорит то.

Не охайте. Интерфейс и при наследовании - главная задача, но решается иначе. И в простом классе тоже. Проблема не в конструкторе и не в том, что задача вам не понятна. Проблема в этом вашем

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

Ох

Остальное, технически преодолимо.

@streamc · 03.06.2019, 04:40 **[ТС]**

enginex был инициализирован в посте 40 и архиве поста 39. Пока я писал пост 39 цитируемый вами, убрал спецом инициализацию из одного места и хотел в другое перенести, но возможность редактирования пропала. Вот и всё. Поста 40 не было бы , будь возможность редактирования поста 39.

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

Не охайте. Интерфейс и при наследовании - главная задача, но решается иначе. И в простом классе тоже

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

IGPIGP · 03.06.2019, 10:33

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

Пока я писал пост

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

но возможность редактирования пропала. Вот и всё.

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

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

Да, интерфейс, как общий класс, без конкретного исполнения, вы писали про это.

Это программная реализация идеи интерфейса (концепции интерфейса как такового), называемая абстрактным классом. Базируется на механизме наследования. Не путать с т.н. реализацией интерфейса (очень неудачный термин бытующий сегодня). Под реализацией интерфейса предлагается понимать - внутренние механизмы которые обеспечивают решение задачи под управлением данного интерфейса. Лучше бы назвать это как-то вроде "исполнительный механизм". А сами интерфейс в программном смысле есть и у функций и у классов. У функций он реализован набором параметров и типом возврата, например. А у классов его можно реализовать открытой для доступа частью. А вот обобщения интерфейсов для групп классов, можно реализовать по разному. Можно создать группу классов ни чем не связанных, но реализующих один и тот же интерфейс. Например метод void Do() , Использовать его трудно, но можно. Для упрощения есть механизмы наследования и шаблонов. Они реализуют предоставляемые интерфейсы по разному. Это программная (внутренняя часть вопроса).
Важнее всего понять сначала предметную, - внешнюю часть - объектную модель. Именно там, все удачные решения останутся незамеченными неблагодарными потомками, но каждая неудача станет настоящей болью. То есть, есть группа родственных объектов (физических носителей данных которые будут отображены в программные объекты). Есть задача - модель в который данная группа будет описана. Теперь нужно понять, какие характеристики и свойства поведения (операции) указанных объектов, являются общими в данной задаче (в моделях, а далее и алгоритмах которые описывают всю задачу как объект) . Это интерфейс внешний, он должен быть предоставлен объектами и принят алгоритмами задачи. Его нужно выразить (реализовать). Если вы обоснованно хотите это сделать шаблонами, то задача грандиозна (имхо). Это значит что там придётся комбинировать все виды полиморфизма. Однако, вероятно, она потребует ряда эскизных решений в простых типах. И станет ясно, что у парусных и реактивных двигателей нет ни частоты ни крутящего момента. Следовательно, попытка зашить в ~~обобщенный~~ ~~параметризованный~~ шаблонный класс (это не класс, но неудачные термины - фишка математики, - это шаблон классов) обращение к методам с частотой и крутящим моментом вызовет необходимость специализаций. Тут есть пути решения, но сначала нужно убедиться в том, что данные конкретные отличие нельзя спрятать от обобщения внутрь (путём наследования скажем).
Но сначала имеет смысл научиться работать с простыми классами и их композициями. Уровень подготовки не должен отличаться от уровня решаемой задачи на порядок и более. И тогда вопросы будут лаконичнее и четче. О том что писать нужно аккуратнее - отдельный разговор. Для того чтобы задать вопрос нужно самому по отвечать и тогда легко можно поставить себя на место отвечающего. Вот и всё, как вы говорите.

@streamc · 03.06.2019, 10:44 **[ТС]**

IGPIGP, спасибо.

IGPIGP · 03.06.2019, 11:36

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

IGPIGP, спасибо.

Если, это вам поможет, - пожалуйста. Чем черт не шутит? Я в каком-то смысле, хоть и сдержанный, но оптимист.

Новые блоги и статьи Все статьи Все блоги /
Саморегулирующийся социальный контракт для сервера cross-section. Hrethgir 14.08.2026 С кодом конечно таких глубоких размышлений пока не было, впрочем я уже привык к алгоритмизации. Суть предмета записи: снова в диалоге с нейросетью (я взял пока себе ник для учётки админа - Rector). . . .	Часы электронные Uhbif79 12.08.2026 Выкладываю программу часов. Программа позволяет: 1. Использовать системное время и дату, 2. Есть возможность вводить время и дату вручную. 3. Реализованы 2 будильника: начало и конец рабочего дня. . . .	Часы с будильником на основе класса QLCDNumber Uhbif79 12.08.2026 Всем добрый день, выкладываю программу часов с будильником на основе класса QLCDNumber. Здесь я пробовал самостоятельно создавал классы, впервые столкнулся с видимостью переменной одного класса из. . .	Установка MinGW GCC 16.2 и CMake 8Observer8 10.08.2026 VK Видео: https:/ / vkvideo. ru/ video-240781534_456239017 YouTube: eY5-5PyI9NM Текстовая версия
Неделя из жизни имитационной модели склада: мои кривые руки растут, откуда надо anaschu 10.08.2026 Неделя из жизни имитационной модели склада: как я почти написал неправильную логику и что с этим делать Работаю сейчас над учебно-рабочим проектом: строю в AnyLogic имитационную модель процессов. . .	Калькулятор для расчета родства russiannick 07.08.2026 1. Задача: Создать калькулятор для расчета родства. Родственных связей существует 8 ступеней, такие как: p - отец P - мать q - муж Q - жена b - брат B - сестра s - сын S - дочь	Мир по моей воле kumehtar 07.08.2026 Когда-то кажется, что всё просто. Ты весь такой светлый. Причиняешь добро. Борешься за справедливость в этом тёмном мире. Потом начинаешь замечать одну неприятную вещь. Почти каждый хороший. . .	Кредитный калькулятор Maks 05.08.2026 Решение задачи по прикладной информатике средствами 1С. Задача: Напишите приложение-калькулятор, которое помогает рассчитывать параметры кредита для аннуитетного и дифференцированного видов. . .

@streamc 1 / 1 / 0 Регистрация: 23.11.2010 Сообщений: 136
	03.06.2019, 10:44 [ТС]
	IGPIGP, спасибо. 0