Objective C в С++? , Возможна ли смена парадигмы-принципа без смены компилятора?

1. Objective C как язык.

2. Obj C to C++ откуда пришла идея?

3. Общие теоретические принципы:

Скрытый текст

1. Тип можно представить как массив (или список) переменных и функций.

2. Если этот принцип дополнить принципом objective C (он же слот/сигнал, он же «принцип win API», он же рецийвер-рефлектор Иррлихта, он же sf::Event SFML).
То тип уже можно представить как «чёрный ящик» содержащий переменные, управление которыми осуществляется посредством функций.
Это управление осуществляется с помощью единственной ф-ции «reflect» принимающий «события» или «сигналы» и содержащая «отражающую матрицу», то есть массив или список «функций реакции».


3. То есть из 2 первых принципов следует:
а) то, что существует необходимость лишь в массиве функций. Массив переменных уже избыточен;
б) переменные можно представить не массивом, а структурой Си (для облегчения манипуляций с ними как с единым целым, применительно к Иррлихту: вместо Си структуры просто берётся указатель на ноду иди элемент – имеем оригинальный паттерн Proxy);
в) тогда классу C++ останется лишь управление памятью (конструктор/деструктор) и единственная функция:

template <class T, class U>
void reflect ( U & _selfData_, T & _SMessageEvent_ )
{
/// матрица отражающая событие
}

4. Следствия.
а) В отличие от обычного порядка определений ф-ций класса такой подход теоретически позволят «добавлять классу функции налету» (то есть после его определения).

б) Частично отпадает необходимость в вирт. Наследовании и кастах, теперь класс представляет собой «конструктор» состоящий из различных комбинаций элементов, в первую очередь отражающих функций и переменных. Сигнал (message, event, функтор) отделён от слота и может «приниматься» слотами объектов различных типов. Слот может добавляться типу после его определения. Наличие функций и переменных класса можно проверить. Можно идентифицировать класс или получить информацию о нём через наличие опред. ф-ций или их комбинации (для этого даже не нужно знать тип объекта!);

5. Вышеописанное – это принципы. Дальше реализации «технологии».
А реализована она может быть несколькими способами (возможно даже описаны не все):
а) с помощью switch/case (подход из Иррлихта) или определения элемента в массива по ID;
б) с помощью виртуального наследования или [массива + enum-ератов];
в) с помощью частич. специализации шаблонов и списка функторов.

Последний метод:
а) в принципе, быстр, так как ветвление с «выбором класса по типу» переносится на этап компиляции;
б) позволяет добавлять типу ф-ции в любой момент, уже после его объявления;
в) чтобы функтор имел доступ к приватным переменным класса они просто передаются ему Си-структорой или указателем на ноду Иррлихта. В функции reflection класса. То есть ф-тор принимает 2 переменные структуру данных типа и «событие» или «message» – как Си структуру или же другой функтор.

Чутка «флуда» по маршалингу/скриптам, GUI:

Скрытый текст

1. Так как в программировании не существует других данных кроме цифровых и текстовых, то при сведении данных к тексту выгоднее использовать скриптовый порт (что облегчит и сохранение/загрузку данных и их передачу текстовым GUI).

2. И для маршалинга текстовых и для маршаллинга числовых данных удобнее всего использовать потоки C++ (std::stringstream). Текстовые для сведения к текстовым данным, они же предоставляют наиболее удобный инструментарий для парсинга-обработки текста. И числовые для сведения к цифровой форме. Структуры Си содержащие простые Си-данные можно загонять в числовой (например файловый) поток «целиком».

3. Хотя для работы с «сериализованными» данными было бы удобно иметь специальную «потоковую БД», некий «ускоренный/оптимизированный» аналог std::map (по парам ключ-значение). Или что-то вроде этого. Суть – БД (осущ. быструю работу с упорядоченными, универсал. (сведённ. к единой форме хранения) данными).

4. Данные GUI оч. удобно хранить в HTML + CSS (на худой конец XML). Парсинг данных к XML/HTML и обратно (суть сериализовать данные из контролов, записать в HTML БД, потом считать оттуда, записать обратно в контрол) удобнее всего осуществлять средствами скриптов поддерживающих регулярные выражения (или) (Lua, JavaScript: V8, Пайтон (Python) и т. д.)

4. Релизация принципа Obj C посредством частичной специализации шаблонов C++:
(компилировалось minGW 441, code::blocks, winXP SP1, необходима поддержка компилятором частичной специализации шаблонов)
(но в теории должно компилироваться на любом компиляторе)

Файл TObjectiveTFR.h (type functor-reflector MSG)

Скрытый текст

#ifndef TOBJECTIVETFR_H_INCLUDED
#define TOBJECTIVETFR_H_INCLUDED
 
#include <iostream>
#include <sstream>
 
/// сначала создаёт eventmsg. Его задача "соединить"
/// "внутренности класса" с внешним процессом, например ф-цией динамической библиотеки
/// даже если она не содержит переменных структура должна существовать
/// т.к. именно в ней хранится "возвращаемый результат"
 
/// START namespace tfr
namespace tfr /// type functor-reflector MSG
{
/// то, что необходимо всем структурам...
    struct tfr_mini
    {
    ///
        bool isExists;
        void exists ( bool _isExists_ ) { isExists = _isExists_; }
        bool exists () const { return isExists; }
 
        tfr_mini() { exists (true); }
 
        void check ( const char * _file_, std::size_t _line_)
        {
            if ( ! isExists )
            {
                std::cout << "ERR: [tfr_list<T>]: Eventmsg not exist!" << "\n"
                          << "[FILE] = [" << _file_ << "]\n"
                          << "[LINE] = [" << _line_ << "]\n" << std::endl;
            }
        }
    ///
    };
 
 
/// результат сведения данных типа к тексту
    struct SDataAsText : public tfr_mini
    {
    ///
        std::string str;
    };
 
/// получить данны TObjective типа
    struct SGetSet : public tfr_mini
    {
        TObjective::SData data_;
        bool isSet;
 
        SGetSet() { isSet = true; data_ = (TObjective::SData) { 0.f,0.f,0.f }; }
    ///
        void getset ( TObjective::SData & _data_ )
        {
            if ( isSet )
                _data_ = data_;
            else /// get
                data_ = _data_;
        }
    };
 
/// результат операции сложения
    struct SAdd : public tfr_mini
    {
        float result;
    };
 
///
    struct SNull : public tfr_mini
    {};
}
/// END namespace tfr
 
#endif // TOBJECTIVETFR_H_INCLUDED

Файл TObjective.h

Скрытый текст

#ifndef TOBJECTIVE_H_INCLUDED
#define TOBJECTIVE_H_INCLUDED
 
/// Эмуляция-симуляция Obj C типа в C++
    class TObjective
    {
    public:
        struct SData
        { float x,y,z; }; /// все переменные класса
    ///
    private:
        SData data_;
 
    public:
    ///
        template < class T > struct tfr_list /// type functor-reflectors list
        {
        /// default result (if this T not add in tfr_list )
            static void exec ( SData & _data_,T & _eventmsg_ )
            { _eventmsg_.exists( false ); }
        };
    ///
        TObjective() { data_ = (TObjective::SData) { 5.f,10.f,15.f }; }
        ~TObjective() { data_ = (TObjective::SData) { 0.f,0.f,0.f }; }
 
    ///
        template < class U >
        void rf ( U & _eventmsg_  ) // reflect
        {
            tfr_list < U >::exec( data_,_eventmsg_ );
        }
    };
 
#endif // TOBJECTIVE_H_INCLUDED

Файл TObjective.cpp

Скрытый текст

#include "TObjective.h"
#include "TObjectiveTFR.h"
 
///
 
/// START [SDataAsText]
    template<> struct TObjective::tfr_list < tfr::SDataAsText >
    {
        static void exec ( TObjective::SData & _data_,  tfr::SDataAsText & _eventmsg_ )
        {
            std::stringstream s;
            s << "[START TObjective]\n"
              << "[x] \t= [" << _data_.x << "] \t= [float]\n"
              << "[y] \t= [" << _data_.y << "] \t= [float]\n"
              << "[z] \t= [" << _data_.z << "] \t= [float]\n"
 
              << "[MSG] \t= [tfr::SDataAsText]\n"
              << "[MSG] \t= [tfr::SGetSet]\n"
              << "[MSG] \t= [tfr::SAdd]\n"
              << "[END TObjective]\n";
 
            _eventmsg_.str = s.str();
        }
    }; /// tfr_SDataAsText; // в экземпляре можно сконстр. список ф-ций типа
 
/// END [SDataAsText]
 
 
/// START [SGetSet]
    template<> struct TObjective::tfr_list <  tfr::SGetSet >
    {
        static void exec ( TObjective::SData & _data_, tfr::SGetSet & _eventmsg_ )
        {
            _eventmsg_.getset( _data_ );
        }
    };
 
/// END [SGetSet]
 
 
/// START [SAdd]
    template<> struct TObjective::tfr_list < tfr::SAdd >
    {
        static void exec ( TObjective::SData & _data_, tfr::SAdd & _eventmsg_ )
        {
            _eventmsg_.result = _data_.x + _data_.y + _data_.z;
        }
    };
 
/// END [SAdd]

Несколько тестов в main.cpp

Скрытый текст

#include <iostream>
#include "TObjective.cpp"
 
using namespace std;
 
/// при сздании новых файлов заголовок дублируется, менятся лишь имя файла И (!!! внимание !!!) структура-набор данных!)
 
/// несколько тестов напоследок
int main()
{
/// тестовый obj C тип
    TObjective obj;
 
/// создать события
    tfr::SAdd add_msg;
    tfr::SGetSet getset_msg;
    tfr::SDataAsText asText_msg;
 
/// последовательно "отправить" их типу, получить реакцию, отобразить
    obj.rf( asText_msg );
    cout << asText_msg.str << "\n";
 
    obj.rf( add_msg );
    add_msg.check( __FILE__, __LINE__ );
    cout << "result = " << add_msg.result << "\n\n"; // 30
 
    getset_msg.data_ = (TObjective::SData) { 30.f,35.f,35.f };
    obj.rf( getset_msg );
    getset_msg.check( __FILE__, __LINE__ );
    obj.rf( add_msg );
    obj.rf( asText_msg );
    asText_msg.check( __FILE__, __LINE__ );
    cout << asText_msg.str << endl;
 
    getset_msg.data_ = (TObjective::SData) { 100.f,100.f,100.f };
    getset_msg.isSet = false; // get
    obj.rf( getset_msg );
    cout << "x = " << getset_msg.data_.x << "\n"
         << "y = " << getset_msg.data_.y << "\n"
         << "z = " << getset_msg.data_.z << "\n\n";
 
    getset_msg.data_ = (TObjective::SData) { 100.f,100.f,100.f };
    getset_msg.isSet = true; // set
    obj.rf( getset_msg );
    obj.rf( add_msg );
    cout << "result = " << add_msg.result << "\n\n";
 
/* /// ошибка компиляции: всё правильно (проверка на этапе комп.)
    struct SNULL
    {} snull;
    obj.rf( snull );
*/
/// 2 вариант ошибки: посылка необрабатываемого сообщения
    tfr::SNull snull;
    obj.rf( snull );
    snull.check( __FILE__, __LINE__ );
 
    cout << "Press ENTER to exit!" << endl;
    cin.get();
    return 0;
}

5. Реализация принципа Obj C посредством класса как массива модулей периода исполнения:

Скрытый текст

Другой вариант это:
1. Добавление в класс С++ Си-массива SAny * elem_arr имеющего вид:

struct SAny
{
    unsigned t_id;
    char t_name [64];
    void * o_ptr;
 
/// это или а) ф-ция или б) тип C++ c конструктором и его аргументами
    unsigned char f_args; /// вряд ли больше 256 арг...
    SAny * fa_arr;
};

2. Ф-ция reflection () не на шаблонах, а на ID.
3. Т.е. класс - это массив переменных и функций, без различий между перем. и функ.
4. Что позволит "автоматизировать" составление массива перем и функц. (отображ. внутр структ. Obj C класса)
5. Остаётся лишь реализовать рассчёт ID один из возможных вариантов которого:
5.1- На этапе комилляции:
Как добавить ID типу/классу, если изначально ID у него нет?

5.2 На этапе исполнения:

    int t_id = 0;
    SAny type_t;
///
    class T
    {
        SAny & my_type;
    public:
        T()
        : my_type ( type_t )
        {}
    };
 
/// а где-то здесь, уже после опред. класса T,
/// например, в конструкторе фабрики (или
/// конструкторе функтора-вирт конструктора),
/// type_t инициализируется значениями,
/// учитывая определение класса T
/// type_t = (SAny) { t_id++,"T", ...

===================================

Такая вот C++ поэзия. Надо быстрей записать, пока не настигла амнезия.
Жаль об этом всём в книгах C++ ни слова. Ни слова c 1983?
Меж тем трудосберегающий синтаксис Obj C во всю применяется в коммерческих разработках Apple, макинтош, Mac OS.
Как так? Вот незадача.

Возможна ли смена парадигмы-принципа без смены компилятора? Утверждать на 100% не буду, слишком много парадигм и языков. Но удачные примеры есть. Если парочку навскидку:

1) Фреймворк Qt. Расширяет синтаксис "своего" С++ посредством предкомпиляции, используя MOC. Таким образом, к примеру, появляется возможность использования сигналов и слотов, прямо в описаниях и реализации классов.

2) Язык Perl. Изначально - процедурно-ориентированный. Но возможности языка позволяют достаточно нехитрым способом конструировать классы и использовать парадигму ООП там, где ее изначально не было.

Насчёт MOC было бы интересно. Что это и с чем его едят?
Какие существуют способы расширения возможностей прекомпиляции?
Или это свой язык-компилятор писать, что для Qt и осуществлено?
И если так, то зачем? Если уже существует Obj C, где это реализовано?
Не проще ли было воспользоваться возможностями Obj C?

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

Скрытый текст

class T
{
public:
    struct Data
    {
        int x;
        float y;
        double z;
        char pch[64];
    }
 
private:
    Data data_;
 
public:
    T ( T::Data * _newd_ = 0 )
    {
    /// по умолчанию
        data_ = (T::Data) { 15,87.f,150.f,"DefaultS" };
    /// если пользователь инициировал:
        if ( _newd_ ) data_ = (*_newd_);
 
        /// типы созданные с помощью new, malloc, realloc
        /// (тот же std::string) невозможно передавать из dll в dll (разные
        /// адресные пространства), значит в любом случае типы созданные
        /// new, malloc, realloc было бы полезно помечать как "в динамич. памяти"
        /// и в каком адресном протранстве (id dll) к тому же....
        /// на уровне данных объекта? Конструктор-копировщик это вряд ли осилит
    }
};

Скрытый текст

А в учебниках С++ чему учат? Тому, что нужно по 1 переменной "прищёлкивать"? И всё переписывать по 2-3 раза заново, определяя один и тот же класс?
Копировать из тела класса копипастом, заменять точки с запятыми - одними запятыми, потом всё заново: брать каждую переменную в скобочки, двоеточие, потом запятые...
А при описани нового типа - опять всё заново.
Что-то оно как-то.... "есть как надо" что ли? И "есть методы для тех, от кого отделаться надо, а если невозможно, то пусть на неудобъях ломаются и ничего толком в итоге" чтоли?

И вроде бы есть хороший язык... но никто не расскажет как нужно на нём что-то делать, чтобы не просто труд потратить, но и результат получить.
И все говорят о "быстром развитии постоянн. меняющ. совр. технологий", при этом мечтают о типах по void*, а они реализованы в Obj C в 1983... как-то уже, то есть... и это имеет коммерческое применение десятилетиями... но новичкам говорят, что "это не правильно и не нужно"... и программисты Си "с коммерческой точки зрения" никому ненужны, хотя Mac OS, Cocoa, - вот же они.

Какое-то такое впечатление. Непонятное.

Конечный вопрос: Что легче?
Легче взять компилятор Obj C и написать все необходимыепорты к OGL и вообще всему (свой "фреймворк к win/linux")?
Или легче взять Obj C++, подцепить к существующим кодам? Пишут ещё, что расширение файлов Obj C *.m, а Obj C++ *.mm. Но нигде не написано, что нужно сделать чтобы перейти с одного на другое, просто файл переимновать или ещё что-то нужно?

Или проще реализовать принципы Obj C в C++ и пользовать? Пока склоняюсь к последнему.

Цитата SectorbzC @ 11.03.15, 14:49

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

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

Цитата SectorbzC @ 11.03.15, 14:49

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

А теперь перепутай инициализаторы местами в списке. Или пропусти один при подготовке своего _newd_. Или внеси туда агрегат. Вложенный в другой.

Цитата SectorbzC @ 11.03.15, 14:49

        /// типы созданные с помощью new, malloc, realloc
        /// (тот же std::string) невозможно передавать из dll в dll (разные
        /// адресные пространства), ...

С помощью malloc и realloc нельзя создать std::string, можно только зарезервировать место под него. Из dll в dll можно передавать всё, если не нарушается ODR. Если нарушается, то программа неверна сама по себе, без всяких dll или lib. Разные адресные пространства подразумевают наличие нескольких различных программ. Стандарт языка не описывает подобные конгломераты, это должно выполняться посредством API используемых ОСей или в конце концов third-party библиотеками.

Цитата Qraizer @ 11.03.15, 15:34

С помощью malloc и realloc нельзя создать std::string, можно только зарезервировать место под него.

Заранее бъю челом ... вельми понеже, паки-паки, иже херувимы (С) Разве нельзя создать нужную структуру в памяти и произвести приведение типов? Присвоить переменной адрес вручную созданной структуры?

Цитата SectorbzC @ 11.03.15, 14:49

Насчёт MOC было бы интересно. Что это и с чем его едят?
Какие существуют способы расширения возможностей прекомпиляции?
Или это свой язык-компилятор писать, что для Qt и осуществлено?

Qt решили что стандартного С++ им мало, и ввели ряд своих "спецификаторов". Типа сигнал, слот, коннект, дисконнект ... Все это достаточно удобно вливается в синтаксис обычного С++. Но после предкомпиляции MOC-ом (старая дока, но концепцию тянет) получается бог-весть-что. Но это работает, и весьма неплохо. Расширений "предкомпиляции" не существует, QT по сути авторитарно расширили спецификацию стандарта С++. (Кстати минус им - пользуются расширением файлов *.cpp незаконно! Сделали бы *.moc, вопросов бы не было)

Цитата SectorbzC @ 11.03.15, 14:49

И если так, то зачем? Если уже существует Obj C, где это реализовано?
Не проще ли было воспользоваться возможностями Obj C?

Qt - это "надстройка" над C++, Obj C - это "надстройка" над C. ИМХО, понятия близкие, но несовместимые. Хотя верю, если бы разработчики Qt решили за основной инструмент взять ANSI C, то к Obj C они бы и пришли. Но, увы, движение - параллельное.

Цитата JoeUser @ 11.03.15, 18:40

Разве нельзя создать нужную структуру в памяти и произвести приведение типов? ...

О чём вопрос-то? Примерный ответ может быть такой: время жизни экземпляра класса начинается с момента возврата управления из его конструктора, поэтому нет вызова конструктора == нет объекта; и наоборот: создание "нужной структуры" подразумевает вызов и успешную отработку конструктора. Т.к. ни malloc(), ни realloc() о конструкторах ничего не знают, они не могут использоваться иначе нежели для предварительного резервирования региона памяти под объект, но не создания самого объекта. Исключение составляют только объекты с тривиальными конструкторами.

Цитата JoeUser @ 11.03.15, 18:40

... Присвоить переменной адрес вручную созданной структуры?

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

Цитата Qraizer @ 11.03.15, 20:24

поэтому нет вызова конструктора == нет объекта; и наоборот: создание "нужной структуры" подразумевает вызов и успешную отработку конструктора.

Я накидал корявенький, но работающий пример - это тут. Глянь, пожалуйста.

JoeUser, работающий пример чего? Записи/чтения сырой памяти?

Цитата Kray74 @ 12.03.15, 05:58

JoeUser, работающий пример чего? Записи/чтения сырой памяти?

Ну да. Экземпляр класса "работающий" же? Понимаю, примитивно, но разве нельзя таким же образом инициализировать более сложные структуры, не прибегая к конструкторам?

Добавлено 12.03.15, 06:07
Это я к тому, что, если зная секретную кухню std::string, можно и его попытаться таким же образом "сконструировать". Другой вопрос, что это нафик не нужно, но это уже другая песня.

to Kray74

Новую переменную?
Тогда добавить в структуру такой конструкт: (не проверял, но работать должно, т.е. технически это легко решаемо)

Скрытый текст

#include <iostream>
 
#include <stdio.h>      /* printf, scanf, puts */
#include <stdlib.h>     /* realloc, free, exit, NULL */
#include <memory.h>     /* memset, memcpy */
 
using namespace std;
 
class T
{
    struct Data
    {
        int x; // по умолчанию
        float y;
        double z;
        char pch[32];
 
    ///
        short any_count;
        struct SAny
        {
            long id;
            intptr_t ptr;
        } * any_arr;
    ///
    } data_;
 
public:
    T ( T::Data * _newd_ = 0 )
    {
    /// по умолчанию
        data_ = (T::Data) { 15,87.f,150.f,"DefaultS", 0,0 };
 
    ///
        double * new_var = new double (365.563f);
 
        T::Data::SAny new_any;
        new_any.id = 5; // t_list <double>::ID
        new_any.ptr = (intptr_t) new_var;
 
    /// по примеру: http://www.cplusplus.com/reference/cstdlib/realloc/
        Data::SAny * more = (T::Data::SAny*) realloc ( data_.any_arr, data_.any_count+1 * sizeof(T::Data::SAny) );
        if ( more )
        {
            data_.any_arr = more;
            data_.any_count++;
            data_.any_arr[data_.any_count-1] = new_any; /// КОПИРОВАНИЕ, а не...
        } /// else throw ex ("КАРАУЛ realloc НЕ СРАБОТАЛ", __FILE__,__LINE__);
    ///
 
    /// если пользователь инициировал:
        if ( _newd_ ) data_ = (*_newd_);
    }
 
    ~T()
    {
        if ( data_.any_arr )
        {
            memset ( &data_.any_arr,0,data_.any_count * sizeof ( T::Data::SAny ) );
            free ( data_.any_arr );
        }
        memset ( &data_,0,sizeof ( T::Data ) );
    }
 
///
    template <class U>
    void add ( U * _newvar_ )
    {
        T::Data::SAny new_any;
        new_any.id = 10; // t_list <U>::ID
        new_any.ptr = (intptr_t) _newvar_;
 
    ///
        Data::SAny * more = (T::Data::SAny*) realloc ( data_.any_arr, data_.any_count+1 * sizeof(T::Data::SAny) );
        if ( more )
        {
            data_.any_arr = more;
            data_.any_count++;
            data_.any_arr[data_.any_count-1] = new_any;
        } /// else throw ex ("КАРАУЛ realloc НЕ СРАБОТАЛ", __FILE__,__LINE__);
    ///
    }
};
 
int main()
{
/*
char any [ sizeof (std::string) ]; /// malloc( ... );
std::string * pstr = new (&any) std::string(); /// после этого any и pstr могут указывать на разные участки памяти,
/// учитывая "заголовки", табл вирт функ, размер типа, размер массива... всё может быть в заголовке объекта типа...
*/
    {
        T t;
    }
    cout << "Press ENTER to EXIT!" << endl;
    cin.get();
    return 0;
}

+ эту SAny можно создать и вне типа, тогда бесящие двоеточия писать не нужно будет.
+ SAny точно так же можно писать в std контейнер (т.к. не содержит С++ типов затруднений с выравниванием быть не должно, поэтому realloc).
+ Там ещё необходимо предусмтреть доступ к элементу массива
- либо по enum,
- либо по строковому имени,
- либо по структуруе с id,строковым именем и т.д.,
- по "контрольной сумме" из строки (или как оно называется забыл уже, хэш-число)
- или ещё как-то.

to Qraizer

С помощью malloc и realloc можно (нужно же память выделить). Хотя выразился не математически корректно.

Но потребуется доп. помощь размещающего (placement) new
А вообще любой тип C++ можно представить как массив байт (и это, кстати, позволяет создать поток-БД (супераллокатор) с доступом к хранимому в "двоичной форме" элементу по ID типа + серийник экземпляра).

char any [ sizeof (std::string) ]; /// malloc( ... );
std::string * pstr = new (&any) std::string(); /// после этого any и pstr могут указывать на разные участки памяти,
/// учитывая "заголовки", табл вирт функ, размер типа, размер массива... всё может быть в заголовке объекта типа...

только после этого деструктор "вручную" вызывать придётся. (выравнивание не производится.)
Или освобождать память memset(). Вместо деструктора. - Что не даёт гаранти т.к. заголовок или табл вирт функ или ссылка на неё может записаться компиляторам куда угодно и это освобождено не будет. За корректное освобождение всего отвечает деструктор/delete.
Поэтому структуры Си можно создавать/освобождать методами Си. С++ лучше не стоит. Pod/no pod типы.

А тут: http://ideone.com/bpMQps

Это ряд ли. Т.к. невозможно учесть "размер заголовка" и "хвостики", который установит компилятор (разные компиляторы - разный заголовок + в заголовок объета может затесаться заголовок массива, который хранится в заголовке 1 объекта массива...)

Можно копировать с помощью = (знака равенства) или memcpy.
Но не всякий объект можно создать с помощью такого копирования (табл. вирт. функ, "особо изощрённые заголовки" и "дебаговые хвостики", "объекты созданные в конструкторе в динамич памяти" всё может потеряться при таком копировании, зависит от реализации в компиляторе). такой метод лучше применять к Си-сруктурам.
Да и с автоматич. вызовом деструктора что? Тоже не ясно.

Теоретически.

А насчёт DLL. Ну тут разное пишут. (Можно ли пользовать STL(или объекты C++) в DLL?) Т.е. STL нарушает ODR, получается.

to JoeUser

Понятно. Информации очень мало.

Сообщение отредактировано: SectorbzC - 12.03.15, 10:39

Скажите, я правильно понимаю, что у SectorbzC просто приступ графомании, изобретения велосипедов с треугольными колёсами и ярко выраженное незнание плюсов, а остальные здесь "чисто для поржать"?

to MyNameIsIgor

Т.е. вы поняли предназначение ресурса как поржать над теми, кто меньше знает?
Я думаю, что вы поняли не правильно. Если действительно так поняли.
Но я могу ошибаться.

Сообщение отредактировано: SectorbzC - 12.03.15, 11:11

Цитата JoeUser @ 12.03.15, 06:02

Цитата Kray74 @ 12.03.15, 05:58

JoeUser, работающий пример чего? Записи/чтения сырой памяти?

Ну да. Экземпляр класса "работающий" же? Понимаю, примитивно, но разве нельзя таким же образом инициализировать более сложные структуры, не прибегая к конструкторам?

Добавлено 12.03.15, 06:07
Это я к тому, что, если зная секретную кухню std::string, можно и его попытаться таким же образом "сконструировать". Другой вопрос, что это нафик не нужно, но это уже другая песня.

Нет не работающий, согласно конструктору значение поля должно быть равно 10. У вас этот инвариант не соблюдается.

Зная секретную кухню конструктора, придется дублировать инициализацию в каждой точке создания объекта. Можно, конечно, но да, нафик не нужно.

Добавлено 12.03.15, 12:16

Цитата SectorbzC @ 12.03.15, 10:27

Новую переменную?
Тогда добавить в структуру такой конструкт: (не проверял, но работать должно, т.е. технически это легко решаемо)

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

Цитата JoeUser @ 12.03.15, 06:02

Экземпляр класса "работающий" же?

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

Добавлено 12.03.15, 13:35

Цитата SectorbzC @ 12.03.15, 10:27

А вообще любой тип C++ можно представить как массив байт

Это верно только для standard-layout классов. Классы могут содержать свои состояния вне своего размещения (типичный пример – статические члены) или полагаться на характеристики исполнительного окружения (типичный пример – открытие файла в конструкторе и закрытие в деструкторе). Кроме того, некоторые аспекты состояния класса зависят от сторонних факторов, и их битовое представление неподконтрольно даже самому классу (типичный пример – хендл того самого открытого в конструкторе файла).

Цитата SectorbzC @ 12.03.15, 10:27

А насчёт DLL. ...

Все те пункты можно смело зачеркнуть и заменить моим кратким "нарушение ODR". Другое дело, что соблюсти ODR в системе, построенной на DLL, зачастую гораздо сложнее, чем на LIB, но это возможно при должном упорстве.

Добавлено 12.03.15, 13:38
MyNameIsIgor, тема ярко выражена как холиварная. Но перетащить её туда я не могу, SectorbzC не сможет там писать, у него мало тематических сообщений.

Добавлено 12.03.15, 13:39

Цитата Kray74 @ 12.03.15, 12:09

К тому же в C++ всегда была важна производительность...

Скорее принцип нулевой стоимости. Вот кстати да, как с этом у Objective C?

Цитата Qraizer @ 12.03.15, 13:13

тема ярко выражена как холиварная. Но перетащить её туда я не могу, SectorbzC не сможет там писать, у него мало тематических сообщений.

А ты ему банку дай и сможет

Цитата Qraizer @ 12.03.15, 13:13

MyNameIsIgor, тема ярко выражена как холиварная. Но перетащить её туда я не могу, SectorbzC не сможет там писать, у него мало тематических сообщений.

А чего тут холиварного? Что с чем холиварит? Человек тащит идеологию одного языка в другой, при этом реализует всё криво и приправляет графоманскими длиннющими опусами ни о чём.

Сообщение отредактировано: MyNameIsIgor - 12.03.15, 15:14

Ну вот же, MyNameIsIgor, началось же.

Не, нафиг, лучше не надо...

Цитата Kray74 @ 12.03.15, 12:09

Цитата SectorbzC @ 12.03.15, 10:27

Новую переменную?
Тогда добавить в структуру такой конструкт: (не проверял, но работать должно, т.е. технически это легко решаемо)

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

Вы считаете, что не способствует. Аргументируйте.
Например, каким образом производительности будет способствовать перенос с ID + intptr_t на IRootLib (виртуалистику).
Если и то и другое требует сравнения по ID и является периодом исполнения.
При этом виртуальную базу без перекомпиляции библиотеки зачастю изменить невозможно...

P.S. Кстати. Я не знаю, что такое ODR, отвечая понадеялся на компетентность Qraizer.
А вот то, что знаю точно (кстати, у автора данной статьи тоже графомания или кто-то о себе пишет?)
И если это знать с самого начала - может сберечь уйму времени и нервов.
+ Если MyNameIsIgor считает мою реализацию кривой, то пусть покажет свою, прямую.
А воевать с Qraizer он может сколько ему хочется и где ему хочется.

Цитата SectorbzC @ 12.03.15, 16:42

Я не знаю, что такое ODR

One Definition Rule - правило одного определения.
Чтобы все определения какой-то сущности в разных частях программы гарантированно совпадали, эти определения должны быть не просто копиями - они и реально должны быть одним единственным текстом, ссылки на который можно вставлять из разных мест программы. За идентичностью копий сложно следить.

Цитата SectorbzC @ 12.03.15, 16:42

Если MyNameIsIgor считает мою реализацию кривой, то пусть покажет свою, прямую.
А воевать с Qraizer он может сколько ему хочется и где ему хочется.

MyNameIsIgor считает кривой саму идею пытаться в C++ применять неприспособленные для C++ методологии Objective-C. А воевать с Qraizerом он вряд ли будет. В этих вопросах они в основном сходятся. MyNameIsIgor скорее будет воевать с тобой.

Цитата Qraizer @ 12.03.15, 13:13

Добавлено 12.03.15, 13:39

Цитата Kray74 @ 12.03.15, 12:09

К тому же в C++ всегда была важна производительность...

Скорее принцип нулевой стоимости. Вот кстати да, как с этом у Objective C?

Дело не в стоимости (GNU Step вроде как бесплатен). И имеет и такой компилятор и сякой (платны мегафреймворки).
А VC++ не сказать, чтобы совсем бесплатен...
И не в производительности (потому, что если эта производительность за счёт труда программиста, то это отнюдь не всегда производительность, а скорее наоборот).

А в подходах, которые позволяют что-то сделать без неприемлемых трудозатрат, потери времени, переусложнения после которого теряется способность читать код.
Как уже было сказано. То есть в нахождении баланса между читаемостью-доступностью кода, трудозатратами и производительностью.
В целях поиска таких подходов стоило бы изучить и Си и Obj C повнимательнее.
И причём тут я вообще-то? А winAPI - что другой подход? Qt? sf::Event SFML? - Везде сигнал-слот->рефлексия из Obj C/Smalltalk.
Может не единственный подход, но хороший. И гораздо лучше чем без него.

Коротко: трудозатраты должны соответствовать приросту производительности
Иначе получится как в этом диалоге:
http://www.gamedev.ru/code/forum/?id=141595

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

Собирать сцену из кусочков...
Objective-C

software IC. Под этой концепцией понимается возможность собирать программы из готовых компонентов (объектов), подобно тому как сложные электронные устройства могут быть легко собраны из набора готовых интегральных микросхем...

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

Цитата SectorbzC @ 12.03.15, 17:27

Дело не в стоимости (GNU Step вроде как бесплатен).

Имеется в виду не цена в фантиках США. А то, что неиспользованные возможности языка и библиотек не должны загружать процессор и увеличивать размер программы. По возможности. Так в C++ если ты не пользуешься к примеру виртуальными функциями, то анализируя откомпилированный код программы ты даже не узнаешь, что такая возможность в языке присутствует.

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

Цитата SectorbzC @ 12.03.15, 18:09

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

У динамического полиморфизма плата не менее велика. И как ты выразился:

Цитата SectorbzC @ 12.03.15, 18:09

Ложка хороша к обеду, т.е. каждый инструмент к своему случаю.

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

Добавлено 12.03.15, 18:27

Цитата SectorbzC @ 12.03.15, 18:09

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

Никогда не понимал этого аргумента. Да хоть ночь оно будет компилиться - и что ? Это как то повлияет на конечный продукт? Ах да, извините, придется вместо 5 секунд, ждать 20 секунд, это же не приемлимо для "кул-спецов".

Добавлено 12.03.15, 18:30
Вот у меня был продукт, с частью которого я работал - время его компиляции, только клиента занимала около 2-х часов. Шаблонов там не то что бы было много, там их было столько сколько нужно - даже в разы меньше, чем нужно было. И компилилось все это долго не потому что там в каком то файле затесался шаблон, а потому что продукт был большой. Ну было бы там много шаблонов, и че? Пусть будет компилится оно вместо 2-х часов - 3 часа, да я на ночь как ставил компиляцию свежей версии, так и ставил бы, и ничего это не изменило бы. Но всегда найдется профи с геймдева который обязательно укажет на эту ну просто мега великую плату зп шпблоны!!!!111один

Сообщение отредактировано: Qraizer - 12.03.15, 19:13

to KILLER

1. По ссылке-то? А он там и пишет в каких случаях перименяются шаблоны (применительно к системам частиц).
2. Это повлияет на время отладки в случае поиска ошибки, например.
Или знание машинного кода программисту C++ - прилагается по умолчанию?
Но тогда с машинного кода и нужно начинать обучение С++.
3. На время разработки если для записи в файл/чтения из файла или в GUI каждый раз потребуется программист.

4. А почему столько негатива? У вас ваш случай, у него свой. На Obj C с 1983 уже больше 30 лет пишут коммерческие продукты.
Это факт. Меня например слегка удививший. WinAPI вот. Qt (не последнее GUI?) Тоже применяется. Везде применяется и так мало известно что это-откуда это.

5. Новый интересный подход-инструмент, вполне реализуемый средствами языка это же не причина для негативных эмоций?
Побольше бы таких подходов - разработка стала бы более интересным занятием. Новая переменная классу - пожалуйста. Функция - пожалуйста. Идентификация по ID - пожалуйста. Хоть пер. комп., хоть пер. исп. Хочешь - делай быстрым, но статичным на шаблонах. Хочешь не заморачивайся. Нужны ID + void* - intptr_t - вперёд. Ничто не "застатичивает" возможности. Максимальный набор инструментов и возможностей. Обучить новичков простой отладке на исключениях/2-3 макросах препроцессора и их обучение резко ускорится. Без заний машинного кода. А они придут по мере накопления опыта.

Сообщение отредактировано: SectorbzC - 12.03.15, 19:33

Цитата SectorbzC @ 12.03.15, 16:42

А вот то, что знаю точно (кстати, у автора данной статьи тоже графомания или кто-то о себе пишет?)

Первый пример ровно про ODR, второй... не знаю, насколько он сейчас актуален, статья очень старая про настолько древние компиляторы, что они ни одному Стандарту языка не удовлетворяют.

Добавлено 12.03.15, 19:19

Цитата SectorbzC @ 12.03.15, 18:09

Коротко: трудозатраты должны соответствовать приросту производительности

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

Добавлено 12.03.15, 19:26

Цитата amk @ 12.03.15, 18:20

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

Вот, точно. Неиспользуемые в программе возможности языка не стоят для неё ничего. Если я захочу динамический полиморфизм, код потеряет чуть в производительности и разрастётся в размере, но я сознательно на это иду, ибо получаю с этого адекватную, как я оценил, отдачу. Если бы я платил за динамический полиморфизм в программах, его не использующих, то я бы скорее предпочёл Дельфи, там платить за всё сразу и авансом за пять проектов вперёд суть нормальная практика.
Я задавал вопрос касательно принципа стоимости в Objective C. Если я возьму C-программу и откомпилю в Obj-C, сколько придётся заплатить лишнего? А если я не буду расширять интерфейс класса в ран-тайм, насколько более эффективным получится объектный код, если маршалинг сообщений заменить на простые статичные вызовы методов?

Цитата SectorbzC @ 12.03.15, 19:16

1. По ссылке-то? А он там и пишет в каких случаях перименяются шаблоны (применительно к системам частиц).

Применительно к ссылке-то! Он там пишет вообще, а не применительно к системам частиц.

Цитата SectorbzC @ 12.03.15, 19:16

2. Это повлияет на время отладки в случае поиска ошибки, например.

Как?

Цитата SectorbzC @ 12.03.15, 19:16

Или знание машинного кода программисту C++ - прилагается по умолчанию?
Но тогда с машинного кода и нужно начинать обучение С++.

Не совсем понял о чем ты.

Цитата SectorbzC @ 12.03.15, 19:16

3. На время разработки если для записи в файл/чтения из файла или в GUI каждый раз потребуется программист.

Для чего? Я не въезжаю о чем ты. Причем тут шаблоны и статический/динамический полиморфизм?

Цитата SectorbzC @ 12.03.15, 19:16

4. А почему столько негатива?

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

Цитата SectorbzC @ 12.03.15, 19:16

Это факт. Меня например слегка удививший. WinAPI вот.

И чем он тебя удивил?

Цитата SectorbzC @ 12.03.15, 19:16

5. Новый интересный подход-инструмент, вполне реализуемый средствами языка это же не причина для негативных эмоций?
Побольше бы таких подходов - разработка стала бы более интересным занятием. Новая переменная классу - пожалуйста. Функция - пожалуйста. Идентификация по ID - пожалуйста. Хоть пер. комп., хоть пер. исп. Хочешь - делай быстрым, но статичным на шаблонах. Хочешь не заморачивайся. Нужны ID + void* - intptr_t - вперёд. Ничто не "застатичивает" возможности. Максимальный набор инструментов и возможностей. Обучить новичков простой отладке на исключениях/2-3 макросах препроцессора и их обучение резко ускорится. Без заний машинного кода.

Каких негативных эмоций? Где вы их увидели?
Я писал исключительно в контексте того - что процитировал.

Добавлено 12.03.15, 19:38

Цитата SectorbzC @ 12.03.15, 19:16

Нужны ID + void* - intptr_t - вперёд.

Зачем они нужны? Да проще с шаблонами чем с этими ID+void* - intptr_t.

to Qraizer

На счёт этого точно не знаю (сколько заплатить по объёму). Но. Когда компилировал библиотеки под wxWidgets (кроссплатформенные), они все dll, которые лежат в папке win (условно говоря, у неё вроде как свои) линковали к *.exe (т.к. запускаться должно было на любой системе). И получалось окно с *.exe 50-100 мб... или таскать окло 10 dll в папке со всеми ексешниками. А дело было на win XP SP 1, где никаких фреймворков тогда не было (они откуда-то взялись в более поздних версиях win).
Вот я смеялся...

А в Mac OS вроде как некий фреймворк. По аналогии с win. Откуда всё берётся готовое.
Как-то так. Но тут специалист не большой.

Сообщение отредактировано: SectorbzC - 12.03.15, 19:48

Цитата SectorbzC @ 12.03.15, 19:44

На счёт этого точно не знаю (сколько заплатить по объёму). Но. Когда компилировал библиотеки под wxWidgets (кроссплатформенные), они все dll, которые лежат в папке win (условно говоря, у неё вроде как свои) линковали к *.exe (т.к. запускаться должно было на любой системе). И получалось окно с *.exe 50-100 мб... или таскать окло 10 dll в папке со всеми ексешниками.
Вот я смеялся...

А что тут смешного? Есть статическая линковка, есть динамическая. Java программа тоже не будет работать без JVM, А C# программа без .NET Framework. И если первая весит в районе сотни метров, то последней нет предела, можешь тоже посмеятся

Цитата SectorbzC @ 12.03.15, 19:44

А в Mac OS вроде как некий фреймворк. По аналогии с win. Откуда всё берётся готовое.

Ключевое слово тут: вроде как некий фреймворк

Добавлено 12.03.15, 20:04

Цитата SectorbzC @ 12.03.15, 16:42

А вот то, что знаю точно (кстати, у автора данной статьи тоже графомания или кто-то о себе пишет?)

Шырокие у вас познания проблем STL Имеем 2 проблемы - одна высосанная из пальца, вторая устарела морально.

Я всё-таки не могу понять, зачем это нужно... Именно в таком виде. Зачем? Если нужен обмен произвольными сообщениями между объектами чёрными-ящиками и прочее - так вон, в соседнем разделе регулярно апдейтится библиотека SObjectizer. Аккурат для этих целей. То есть если уж писать свой велосипед, то по-взрослому, про акторов и прочее. Это по крайней мере вписывается в современные парадигмы разработки ПО. А в таком виде - нет, не пойму.

В обучающих целях. Как минимум.
К тому же причём тут многопотоковость? Obj C это отнюдь не только многопотоковость. Это стиль программирования, подход, парадигма.

Цитата

А C# программа без .NET Framework.

И понятно откуда идея (Mac OS, Obj C опять). Но громоздкий синтаксис никуда не делся ни в jave-е ни в C# + резко сузились возможности.
Посмотрел код SObjectizer... нет уж, я лучше по старинке. Как-то оно "на устаревшем С++ + Си" попонятнее получается, при почти тех же возможностях.

Что здесь вообще происходит? Есть какой-то смысл в предложении ТС? Есть ли какой-то конструктив в теме? Стоит ли вчитываться?

Цитата D_KEY @ 12.03.15, 22:34

Что здесь вообще происходит? Есть какой-то смысл в предложении ТС? Есть ли какой-то конструктив в теме? Стоит ли вчитываться?

Нет, можешь не терять время зря.

Добавлено 12.03.15, 22:50
Ну хотя можешь первый пост прочитать, но я его не осилил - честно.

Добавлено 12.03.15, 22:52
Просто как то идет - разговор ниочем.

ТС не в курсе, что Apple уже выкидывает Objective C в пользу своего Swift?

Цитата SectorbzC @ 12.03.15, 21:49

И понятно откуда идея (Mac OS, Obj C опять). Но громоздкий синтаксис никуда не делся ни в jave-е, ни в C# ...

... ни в ObjC. Хочешь негромоздкий синтаксис — бери SmallTalk или Io, например, раз так прёт «ТруЪ-ООП». Ruby в крайнем случае.

Сообщение отредактировано: korvin - 13.03.15, 06:42

Цитата korvin @ 13.03.15, 06:41

ТС не в курсе, что Apple уже выкидывает Objective C в пользу своего Swift?

Прям таки выкидывает?

И несколько простых вопросов:
Зачем был нужен этот auto? (в C++911 и выше) Что он даёт? Принципиально?
Если. Типы Си можно представить как массивы и определять по размеру. Средствами компиллятора (и тогда тип может меняться в зависимости от разрядности ситемы -в сторону уменьшения-экономии-оптимизации например):

x[2] = 15, // int, 4 long // любая переменная это массив байт...
y[4] = 87.f, // float
z[8] = 150.f, // double

Или:

x<2<15, // int
y<4<87.f, // float
z<8<150.f; // double
str < std::string < "string";

(т.е. всё свести к кратким потокам)

Тип C++ необходимо указывать явно.
Т.к. можно так

char str [] = "Str";

А можно так:

std::string str = "Str";

И определить "что именно" для конкретного случая не возможно (непредсказуемое для программиста поведение):

str = "Str";

Но.
Если тип указан справа от выражения, то на кой чёрт он слева от него?

str = std::string ("Str"); /// предположим это функция-конструктор

Тогда автокаст можно было бы указать кратко:

myObj * obj = : ptr; /// чтобы уйти от постоянного копипаста

или

myObj * obj < ptr; /// чтобы уйти от постоянного копипаста

Зачем писать эти повторяющиеся auto постоянно? Как public/private в java/C#? И т.д.

Шаблонное же программирование (которое и даёт основной прирост производительности) оно вообще к кастам не расположено (это своеобразный стиль на 90% исключающий любые касты, предполагающий работу со статикой). Это как "несколько языков в 1". Причём даже без синтеза, на уровне перемешивания, причём временами хаотического. (что и влечёт переусложнение кода от "переусложения парадигм" особенно заметное в последних версиях языка)

Резюмирую:
C++ - это язык "много в 1 флаконе", причём не синтез, а временами хаотическое перемешивание. Язык для исследований. С, я бы сказал, нарочито громоздким синтаксисом. Но очень широкими возможностями (возможно максимально широкими). Воспользоваться которыми может позволить понимание верных подходов/приципов/парадигм.
Решения найденные в С++ используются для последующего внедрения успешных решений в такие языки, которые преспособлены для работы.
Задача - приспособить C++ и для дела тоже. Это можно сделать упорядочив хаос по принципам/парадигмам/подходам, один из которых:
Сигнал->слот->отражающая матрица. И фреймворки сверху Obj C из Mac OS. Применяемый в winAPI, Qt и многих других местах, о чём в топе.

Сообщение отредактировано: SectorbzC - 13.03.15, 08:14

Цитата D_KEY @ 13.03.15, 07:09

Прям таки выкидывает?

Ну... Я думаю да. Не резко, конечно.

С последним точно в холивары нужно.

Если честно, читал-читал ТС, но так и не понял Цели ТС. В чем проблема, в чем вопрос?

Понимаю, вернее полагаю (ввиду свеого недостаточного знания плюсоф), что в нынешней реализации явно не хватает поддержки параллелизма "искаропки", если точнее - способов взаимодействия. Это единственный существенный минус. ИМХО. Да, есть функции поддержки многопоточности, но этого мало, ИМХО! Хотелось бы большего, а-ля, "рандеву" языка АДА в синтаксисе языка (Цэ++). ИМХО - весьма симпатичная концепция! И самое интересное - весьма древняя, но актуальная по сей день!
См, описалово (язык Ада, о рандеву):

Скрытый текст

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

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

ЗЫ: Поправьте меня в моих заблуждениях, буду благодарен.

Сообщение отредактировано: JoeUser - 14.03.15, 18:12

В сетевом программировании к сожалению не компетентен (не пришлось как-то). CGI на Си/С++ могу писать, а вот с сокетами-портами почти не знаком. И многопоточностью.

Но вот тут есть какие-то, возможно полезные наработки другого направления. Кому были нужны добавления переменных экземпляру "на лету" - держите. С проверкой по ID типа.

А вот ещё интересное. Что-то вроде заготовки байтного потока. Можно организовать что-то вроде базы данных с доступом по ID.
Может быть пригодится кому-нибудь. (компилировалось-проверялось под minGW 441 code::blocks)

Скрытый текст

#include <iostream>
#include <memory.h>     /* memset, memcpy */
 
using namespace std;
 
/// тестовый
    struct T0
    {
        T0() { cout << "T0 Cstor!" << "\n"; }
 
        ~T0 () { cout << "T0 Dstor!" << "\n"; }
    };
 
///
    struct T2
    {
        struct SByteStream
        {
            char ps [ sizeof(unsigned short) ];
            char pf [ sizeof(float) ];
            char pd [ sizeof(double) ];
            //char pst [ sizeof(std::string) ];
            char pst [ sizeof(T0) ]; /// а ведь их можно объединить в 1 массив... с "отдачей" intptr_t по ID типа, серийнику экземпляра, порядковому номеру в потоке...
        } d_;
 
        T2()
        {
            new (d_.ps) unsigned short ( 105 );
            new (d_.pf) float ( 205.502f );
            new (d_.pd) double ( 1505.5051f );
            //new (d_.pst) std::string( "String string" );
            new (d_.pst) T0();
        }
 
        ~T2()
        {
            //((std::string*)d_.pst[0])->~string(); // вышибает зараза, но для своих типов нужно вызывать...
            ((T0*)d_.pst[0])->~T0();
            memset ( &d_,0,sizeof ( T2::SByteStream ) );
        }
 
        void print ()
        {
            cout << *(unsigned short*) &d_.ps[0] << "\n"
                 << *(float*) &d_.pf[0] << "\n"
                 << *(double*) &d_.pd[0] << "\n";
                 //<< *(std::string*) &d_.pst[0] << "\n"; // работает
        }
    };
 
///
int main()
{
    T2 t2;
    t2.print ();
 
    cout << "Press ENTER to EXIT!" << endl;
    cin.get();
    return 0;
}

Undefined behavior как с куста.

Если это о последнем примере, то он очень сырой. Цель - показать саму возможность-принцип. И лучше брать указатели не на начало массива, а то, что возвращает new. new же возвращает не Undefined behavior? Даже если он "размещающий". А если new взвращает Undefined behavior, то это забавно.

А если в 1, то где именно?
Ну и пометил там, что всё то же самое можно реализовать с помощью С++ контейнеров-массивов std типа того же vector, map.

Сообщение отредактировано: SectorbzC - 15.03.15, 08:31