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

Я всё-таки не могу понять, зачем это нужно... Именно в таком виде. Зачем? Если нужен обмен произвольными сообщениями между объектами чёрными-ящиками и прочее - так вон, в соседнем разделе регулярно апдейтится библиотека 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