Каким должен быть С++? , Ваше мнение

1. Недавно прочитал мнение о том, что this должен быть ссылкой, а не указателем.
2. Давно читал о том, что оператор "->" можно ( нужно ) заменить на ".".
3. От себя добавлю, что конструкции struct и class во многом совпадают, поэтому можно либо что-то из них убрать, либо сделать их более разными ( например, запретить в struct функции-члены ). Я думаю, что лучше оставить один class. А ещё лучше заменить его на type.
Что ещё можно поменять?

Сообщение отредактировано: prografix - 28.03.14, 05:37

Для начала стоит взглянуть на D. Может быть все уже убрано до нас.

Совместимым с C++1x

Цитата prografix @ 28.03.14, 05:37

Что ещё можно поменять?

Ничего из вышеперечисленного. Нет обратной совместимости.

Цитата

Нет обратной совместимости.

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

Цитата prografix @ 28.03.14, 12:37

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

Тогда это будет не С++, а какой-нить E или какие там буквы остались еще свободны?

Вот так D и получился.

Все три известных мне улучшения С++ ( Java, C#, D ) на мой взгляд оказались ухудшенными вариантами С++. Хотя по идее там должны быть и удачные изменения. Какие? Сам я давно смотрел эти языки, деталей не помню.

Java и C# никогда не позиционировались как «улучшенный C++».

Цитата prografix @ 28.03.14, 05:37

Что ещё можно поменять?

Думаю, что очень важна хорошая/удобная визуализация. Примеры:
1.Вместо писанины y = sqrt(x) мы бы видели рисования корня над 'x' и далее, если надо.
2.Чтобы в записи "y = ++p[i];" был понятен=виден порядок действий.
3.Всякие goto рисовались бы полукруглыми путём со стрелками, если недалеко ведут.
4.Чтобы в for'е можно было написать: "for(a=0, int i=2; i<9; a++)"
5.Чтобы можно было: a[2..4] = {7,1,-5}; Ну или как-то так.
6.Чтобы неравенство можно было рисовать значком уникода ≠, а не городить непонятное многим "!=".

Славян, пп.4,5 поддерживаю. Хотя в п.4 имеется некоторая неоднозначность. Как понимать такую запись?

for (int i = 0, j = 10; i < j; ++i)

обе переменных объявлены внутри цикла, или только i? Кстати, а сейчас так писать можно?

А остальное можно средствами среды организовать.

Цитата Славян @ 29.03.14, 14:04

Вместо писанины y = sqrt(x) мы бы видели рисования корня над 'x' и далее, если надо.

Цитата Славян @ 29.03.14, 14:04

.Всякие goto рисовались бы полукруглыми путём со стрелками, если недалеко ведут.

Цитата Славян @ 29.03.14, 14:04

Чтобы неравенство можно было рисовать значком уникода ≠, а не городить непонятное многим "!=".

И как ты себе представляешь редактирование такого файла?

Добавлено 29.03.14, 15:23

Цитата amk @ 29.03.14, 15:21

Кстати, а сейчас так писать можно?

Можно, объявляются обе.

Славян, тут язык обсуждают вообще-то.
amk, обе. Имя типа делает первое выражение заголовка for() определением, поэтому , интерпретируется как разделитель определяемых сущностей, а не как операция ,.

Сообщение отредактировано: Qraizer - 29.03.14, 15:27

Тогда пункт 4 будет противоречить существующему синтаксису. А вот групповое присваивание не помешало бы. И может присваивание части массива. Привык уже в питоне без временных переменных обходиться:

a, b = b, a # Обмен значениями
a, b = b + a, a # при вычислении чисел Фибоначчи
a, b = b, a%b # алгоритм Эвклида
x, y = x*c - y*s, y*c + x*s # поворот вектора

Сообщение отредактировано: amk - 29.03.14, 15:33

Цитата Qraizer @ 29.03.14, 15:24

Славян, тут язык обсуждают вообще-то.

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

Цитата amk @ 29.03.14, 15:31

Тогда пункт 4 будет противоречить существующему синтаксису. А вот групповое присваивание не помешало бы. И может присваивание части массива. Привык уже в питоне без временных переменных обходиться:

a, b = b, a # Обмен значениями
a, b = b + a, a # при вычислении чисел Фибоначчи
a, b = b, a%b # алгоритм Эвклида
x, y = x*c - y*s, y*c + x*s # поворот вектора

Тут тоже будет противоречие. Т.к. сейчас в

int x, y = foo();

результат foo не имеет никакого отношения к x, а инициализирует только y.

Цитата OpenGL @ 29.03.14, 15:22

Цитата Славян @ 29.03.14, 14:04

1.Вместо писанины y = sqrt(x) мы бы видели рисования корня над 'x' и далее, если надо.

Цитата Славян @ 29.03.14, 14:04

3.Всякие goto рисовались бы полукруглыми путём со стрелками, если недалеко ведут.

Цитата Славян @ 29.03.14, 14:04

6.Чтобы неравенство можно было рисовать значком уникода ≠, а не городить непонятное многим "!=".

И как ты себе представляешь редактирование такого файла?

Очень плохо представляю, даже отвратительно. Согласен, что тут "красота для глаз" сталкивается в войне с "удобством для рук".

Цитата D_KEY @ 29.03.14, 15:59

Тут тоже будет противоречие.

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

{a, b} = {b, foo(a)};

И в объявлениях множественное присваивание смысла обычно не имеет.

Цитата Славян @ 29.03.14, 14:04

Вместо писанины y = sqrt(x) мы бы видели рисования корня над 'x' и далее, если надо.
...
Чтобы неравенство можно было рисовать значком уникода ≠, а не городить непонятное многим "!=".

Ты сначала вспомни зачем были введены диграфы и триграфы.

Цитата amk @ 29.03.14, 15:31

Тогда пункт 4 будет противоречить существующему синтаксису.

Да. Выражение может быть или обычным, или определением, но целиком либо тем, или иным. Делать или нет определениями отдельные его операнды синтаксис выражений не позволяет. Но ты можешь произвольное выражение_не_определение замешать в инициализирующее значение выражения-определения:

for (int i = (j = 10, 0); i < j; ++i)

Та надо вообще отказаться от for в текущем виде и добавить интервалы =)

// вместо
for (int i = (j = 10, 0); i < j; ++i)
// это
for (int i = 10 in [0..j = i])
 
// вместо
for (int i = 0; i < j; i+=5)
// это
for (int i in [0..j] by 5)

Та оставить for как есть, бог с ним. Лучше выпилить switch, тот вообще неструктурный даже.

switch(...)
{
  case ...: if(...){/* ... */
  case ...:         /* ... */
  case ...:;} else {/* ... */
  case ...:         /* ... */ break;
  case ...:         /* ... */}
}

Цитата prografix @ 28.03.14, 05:37

1. Недавно прочитал мнение о том, что this должен быть ссылкой, а не указателем.

В Java с C# прочитал?

Цитата prografix @ 28.03.14, 05:37

2. Давно читал о том, что оператор "->" можно ( нужно ) заменить на ".".

Зочем? -> это для указателей, . - Для обычной семантики по значению. Если Заменить -> на . то как работать с указателями? Или выбросить их?

Цитата prografix @ 28.03.14, 05:37

3. От себя добавлю, что конструкции struct и class во многом совпадают, поэтому можно либо что-то из них убрать, либо сделать их более разными ( например, запретить в struct функции-члены ). Я думаю, что лучше оставить один class. А ещё лучше заменить его на type.

Структура более лаконична, если нужно написать интерфейс. Не нужно пихать всякие public, и смотрится красиво. Не нужно. и type в топку.

Serafim, держи. Смотреть надо на функцию main. То, что выше - это "пережитки" C++11. В C++14 код будет сильно проще.

Цитата Flex Ferrum @ 17.04.14, 20:35

Serafim, держи. Смотреть надо на функцию main. То, что выше - это "пережитки" C++11. В C++14 код будет сильно проще.

Но это ведь маразм ради какой то сахарной фичи городить такой огород ))

Сообщение отредактировано: Wound - 17.04.14, 20:54

Цитата Wound @ 17.04.14, 20:54

Но это ведь маразм ради какой то сахарной фичи городить такой огород ))

Так вот я и говорю - в C++14 будет много проще.

Цитата Flex Ferrum @ 17.04.14, 20:57

Так вот я и говорю - в C++14 будет много проще.

А сейчас как выходит стандарты? Каждый год? Или у них просто есть конечная цель и они ее реализуют? А то раньше както редко выходили новые стандларты. А щас чуть ли не каждый год-два

Цитата Wound @ 17.04.14, 20:59

А сейчас как выходит стандарты?

Сейчас вот "баг-фикс" в виде C++14, а потом будет С++17 c блэкджеком полиморфными аллокаторами и лайт-концептами.

Цитата Flex Ferrum @ 17.04.14, 21:03

Сейчас вот "баг-фикс" в виде C++14, а потом будет С++17 c блэкджеком полиморфными аллокаторами и лайт-концептами.

А есть компилятор уже с полностью реализованым стандартом что они приняли в 11 году? Пусть даже с какими то багами? А то я както давно уже пропустил тему.

Добавлено 17.04.14, 21:05
gcc последний например ? Или это они его все пилить до 17 года будут?

Сообщение отредактировано: Wound - 17.04.14, 21:06

Цитата Wound @ 17.04.14, 21:05

gcc последний например ?

Full-featured C++11 - это gcc 4.8 и, ЕМНИП, clang 3.3. clang 3.4 поддерживает уже почти все фишки C++14.

Ясно, спасибо. Надо пощупать. А то у нас на работе все на старом сидим. Единственное что до студии 12 проапгрейдились.

Цитата Flex Ferrum @ 17.04.14, 20:35

То, что выше - это "пережитки" C++11

только 98, только хардкор! Во имя void main

Добавлено 17.04.14, 21:27

Цитата Wound @ 17.04.14, 20:54

Но это ведь маразм ради какой то сахарной фичи городить такой огород ))

Между прочим сахарный огород начинает потихоньку вытеснять обычный

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

Намёк на JS vs Coffee

Цитата Serafim @ 17.04.14, 21:26

только 98
void main

Взаимоисключающие параграфы.

Цитата D_KEY @ 17.04.14, 21:32

Взаимоисключающие параграфы.

int main и 98 взаимоисключаются, а void как раз самое оно

Serafim учит D_KEY C++

MyNameIsIgor, естественно, яж плюсов не знаю, самое время учить

Цитата Serafim @ 18.04.14, 00:31

int main и 98 взаимоисключаются, а void как раз самое оно

Серьёзно?

Цитата

3.6.1 Main function [basic.start.main]
...
2 An implementation shall not predefine the main function. This function shall not be overloaded. It shall
have a return type of type int, but otherwise its type is implementation-defined. All implementations
shall allow both of the following definitions of main:

           int main() { /* ... */ }

and

           int main(int argc, char* argv[]) { /* ... */ }

...

Serafim наверное считает так из-за влияния древнего vc6.0, который умудрялся на int main() выдавать варнинг а-ля "main должна возвращать void"

нет, Turbo С++, ну да ладно

В C++ мне недостает ровно одной вещи: GUI-либ на уровне стандарта
Прямым кандидатом на эту вакансию я вижу Qt. Кто знает, может, после буста очередь дойдет и до него

Цитата B.V. @ 18.04.14, 12:50

Прямым кандидатом на эту вакансию я вижу Qt.

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

Цитата B.V. @ 18.04.14, 12:50

GUI-либ на уровне стандарта

Нет уж, не надо.

Добавлено 18.04.14, 13:18

Цитата B.V. @ 18.04.14, 12:50

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

Ну так используй Qt, зачем в стандарт гуй пихать?

Добавлено 18.04.14, 13:21
У Страуструпа, кстати, в относительно новой книге для новичков про гуй рассказывается. Но там не Qt, там fltk

Цитата B.V. @ 18.04.14, 12:50

В C++ мне недостает ровно одной вещи: GUI-либ на уровне стандарта

Зачем GUI на микроконтроллерах?

Цитата Мяут-Настоящий @ 18.04.14, 18:11

Зачем GUI на микроконтроллерах?

Ну как же, как! Чтобы открываем мы системник или ещё какой блок, а там в каждой микросхемке микроэкранчик и показывает ТТХ или другую DEBUG-инфу. Лепота ж! Согласны?

Цитата Serafim @ 17.04.14, 18:28

Та надо вообще отказаться от for в текущем виде и добавить интервалы =)

// вместо
for (int i = (j = 10, 0); i < j; ++i)
// это
for (int i = 10 in [0..j = i])
 
// вместо
for (int i = 0; i < j; i+=5)
// это
for (int i in [0..j] by 5)

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

for (int i in [0..j) by 5)

prografix в программировании обычно двумя или тремя точками обозначается =)

Добавлено 19.04.14, 07:11
Если в языке есть интервалы конечно

Добавлено 19.04.14, 07:11
Насколько помню это Python, Ruby, Delphi, Coffee

В Python нет интервалов, там есть генераторы:

for i in range(20, 80, 10):
  print i

Но Flex Ferrum нечто подобное выше уже выложил

#include <boost/range/counting_range.hpp>
 
using namespace boost;
 
...
 
for (auto i : counting_range(0, 10))
    ...

Мяут-Настоящий, вообще-то range в Python вовсе не генератор, а обычный контейнер. Во 2-х это функция, возвращающая список значений, а в 3-х отдельный класс, являющийся неизменяемым контейнером, содержащим этот список. В Python активно применяются итераторы, являющиеся по сути генераторами, перебирающими объекты контейнера. И существуют виды,

А на счёт диапазонов ты верно подметил, в Python'е их действительно нет и не предвидится.

Да, я вечно его с xrange путаю. Последний как раз-таки генератор.

Оффтоп:
Я вот одного в Python'е не понял, почему срезы (slice, a[b:e:s]) не сделали отображениями.

Цитата amk @ 19.10.14, 17:22

почему срезы (slice, a[b:e:s]) не сделали отображениями.

А как их сделали? И что значит "сделать срезы отображениями"?

korvin, срез с синтаксисом - это не отображение, а копия списка. Хотя сами объекты копируются по ссылке, похоже.

Цитата Мяут-Настоящий @ 20.10.14, 10:21

Хотя сами объекты копируются по ссылке, похоже.

"Копируются" и "по ссылке" -- взаимоисключающие вещи. =)
Но в целом, я вроде понял о чем ты.

Копируется ссылка, конечно.

• Расширенный RTTI, чтобы в рантайме можно было получить информацию о методах, указатели и т.д., возможность проверки соответствия сигнатуры, на деле займет место в сегменте данных, но никак не должно отразиться на производительности, по сути Read-Only информация, да еще возможность создания объекта, но никаких модификаций объектов не надо.
• Аттрибуты подобные .NET, по сути расширение предыдущего пункта дополнительной метаинформацией
• Уже наконец-то полноценные концепты, а не костыли на SFINAE.
• Да и уже избавиться от include и от разбития по .h/.cpp файлам))). И заменить это на аналог using .NET или import JAVA. Чтобы библиотека содержала всю необходимую информацию для своего использования.

Цитата Axis @ 30.10.14, 09:42

Да и уже избавиться от include и от разбития по .h/.cpp файлам))). И заменить это на аналог using .NET или import JAVA. Чтобы библиотека содержала всю необходимую информацию для своего использования.

N4214

Цитата Axis @ 30.10.14, 09:42

Уже наконец-то полноценные концепты, а не костыли на SFINAE.

N4205

Цитата Axis @ 30.10.14, 09:42

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

N4111

Цитата Axis @ 30.10.14, 09:42

Аттрибуты подобные .NET, по сути расширение предыдущего пункта дополнительной метаинформацией

N3984

Мой список

1. Нормальные мультиметоды. Библиотеками такое не реализовать, тем более эффективно.
2. Концепты. Тут всё ясно и все давно ждут
3. Сопрограммы. В смысле нормальные stackfull сопрограммы, а не мелкомягкие предложения а-ля уродский async/await, который по семантике stackless, ибо не нужно. И крайне желательно, чтобы Стандарт требовал (или настоятельно рекомендовал) реализациям использовать линкер с разделяемым стеком а-ля gold.
   Ну, а если уж всё же останавливаться на предложении мелких и мягких, то Стандарт должен требовать, чтобы реализация не выделяла дополнительной памяти, а не как в примере реализации - теневой стек непонятного размера, выделенный непонятным аллокатором.
4. Контракты. Тоже хочу

Да, по поводу рефлексии - никакого run-rime, всё должно быть compile-time, imho.

Сообщение отредактировано: MyNameIsIgor - 30.10.14, 16:40

Цитата MyNameIsIgor @ 30.10.14, 11:14

Сопрограммы. В смысле нормальные stackfull сопрограммы

Как вариант: N4244.

Цитата Flex Ferrum @ 30.10.14, 11:23

Цитата MyNameIsIgor @ 30.10.14, 11:14

Сопрограммы. В смысле нормальные stackfull сопрограммы

Как вариант: N4244.

Я не читал, а быстро пролистал, и мне кажется, что они stackless, как у Криса в asio на макросах.

Цитата MyNameIsIgor @ 30.10.14, 11:14

всё должно быть compile-time, imho

Это не всегда возможно. Каким образом процедура test может получить фактический класс значения переменной x из статической информации о ней?

Сообщение отредактировано: korvin - 30.10.14, 11:53

Цитата korvin @ 30.10.14, 11:52

Цитата MyNameIsIgor @ 30.10.14, 11:14

всё должно быть compile-time, imho

Это не всегда возможно. Каким образом процедура test может получить фактический класс значения переменной x из статической информации о ней?

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

Цитата MyNameIsIgor @ 30.10.14, 11:58

Ну, а test в данном случае можно сделать шаблоном

Каким образом это поможет, если я захочу применить ее (в цикле) к коллекции [Parent*], в которой могут находиться элементы любого дочернего класса?

По-моему было бы неплохо иметь возможность создавать (локальные, временные) расширения классов без необходимости в рантайме создавать копию коллекции (в отличие от использования субклассов), типа того:

extension Test
{
    class Parent
    {
    public:
        virtual void describe()
        {
            ^describe(); // вызов оригинального метода Parent::describe
            cout << " extension Test";
        }
    };
    
    class Child
    {
    public:
        virtual void describe()
        {
            cout << "Child extension Test";
        }
    };
};
 
void
test(vector<Parent> xs)
{
    extend xs : Test;
    for (auto x : xs) {
        x->describe();
        cout << endl;
    }
}

Только я не представляю как это можно (или насколько сложно) сделать потокобезопасно.

Сообщение отредактировано: korvin - 30.10.14, 12:26

Цитата korvin @ 30.10.14, 12:25

Каким образом это поможет, если я захочу применить ее (в цикле) к коллекции [Parent*], в которой могут находиться элементы любого дочернего класса?

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

Цитата korvin @ 30.10.14, 12:25

По-моему было бы неплохо иметь возможность создавать (локальные, временные) расширения классов без необходимости в рантайме создавать копию коллекции (в отличие от использования субклассов), типа того:

Должен сказать, что не осилил что это и о чём ты хочешь сказать :-)

Цитата MyNameIsIgor @ 30.10.14, 11:14

Контракты. Тоже хочу

Ссылка, насколько я понимаю, не туда.

Цитата MyNameIsIgor @ 30.10.14, 13:40

Должен сказать, что не осилил что это и о чём ты хочешь сказать :-)

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

class Parent
{
public:
    virtual void describe()
    {
        cout << "Parent";
    }
};
 
class Child : public Parent
{
public:
    virtual void prefix()
    {
        cout << "\t";
    }
    virtual void describe()
    {
        cout << "Child";
    }
};
 
void
test(Parent *x)
{
    // синтаксис условный
    if (RTTI::supports(x, RTTI::class<Child>()))
        RTTI::cast<Child>(x)->prefix();
    x->describe();
    cout << endl;
}

что с точки зрения ООП как бы не очень хорошо, ведь для такого и существуют классы (точнее ad-hoc полиморфизм и data directed programming), чтобы специализированный код выбирался автоматически по типу данных без всяких if'ов.

Вообще более общий случай -- проверка наличия метода void prefix(), но не будем усложнять.

Можно создать субкласс Child

class ChildExt : public Child
{
public:
    virtual void describe()
    {
        prefix();
        Child::describe(&this);
    }
};

или прокси

class ChildProxy : public Child
{
private:
    Child *original;
public:
    virtual void describe()
    {
        original->prefix();
        original->describe();
    }
    virtual Child* getOriginal()
    {
        return original;
    }
};

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

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

extension Test
{
    class Child {
    public:
        virtual void describe()
        {
            prefix();
            ^descibe(); // original
        }
    }
};

Тогда бы test осталась бы максимально простой, никаких "дум" где и как вставить преобразование объектов Child к ChildExt или ChildProxy, почти никаких накладных расходов на рантайм

void
test(Parent *x)
{
    x->describe();
    cout << endl;
}
 
    ...
    extend Test; // область действия определяется как и для всего остального -- по области видимости
    for (Parent *x : xs)
        test(x);
    ...

Вообще это похоже на динамические переменные CL, только применяется к классам.

Цитата MyNameIsIgor @ 30.10.14, 11:14

Библиотеками такое не реализовать, тем более эффективно.

Я попробовал. Два полиморфных вызова на каждый позднесвязываемый параметр. Думаю, ещё эффективнее не выйдет.

Добавлено 30.10.14, 15:12
Ладно, будет сам мой дембельский аккорд. Всё равно за три дня не успею под C++11 перенести, раз до сих пор так и не собрался. А скоро уже и не надо будет, ибо будут испаропки.

Цитата D_KEY @ 30.10.14, 14:19

Цитата MyNameIsIgor @ 30.10.14, 11:14

Контракты. Тоже хочу

Ссылка, насколько я понимаю, не туда.

Исправил.

Добавлено 30.10.14, 16:44

Цитата Qraizer @ 30.10.14, 14:40

Я попробовал. Два полиморфных вызова на каждый позднесвязываемый параметр. Думаю, ещё эффективнее не выйдет.

Я помню их - там необходима регистрация в одном месте, что неприемлемо. Это во-первых.
Во-вторых, если мы оставляем подобную регистрацию, то эффективнее можно по тому же принципу, что описан у Страуструпа.

Эффективнее можно при поддержке языка. Я говорил о библиотеке.

Цитата Qraizer @ 30.10.14, 17:47

Эффективнее можно при поддержке языка. Я говорил о библиотеке.

Я тоже. Таблицу, про которую пишет Бьярн, можно сформировать, если регистрация всего происходит в одном месте.

korvin, правильно ли я понимаю, что таким "расширением класса" ты в данном случае говоришь "для всех Child в этой коллекции вызови prefix перед describe"?

Цитата MyNameIsIgor @ 31.10.14, 08:29

правильно ли я понимаю, что таким "расширением класса" ты в данном случае говоришь "для всех Child в этой коллекции вызови prefix перед describe"?

Да.

Цитата korvin @ 31.10.14, 09:31

Цитата MyNameIsIgor @ 31.10.14, 08:29

правильно ли я понимаю, что таким "расширением класса" ты в данном случае говоришь "для всех Child в этой коллекции вызови prefix перед describe"?

Да.

Ну, тогда это возможно реализовать. По семантике это как раз предложение от Страуструпа и Ко по мультиметодам

void test(virtual Parent* p)
{
  p->describe();
}
 
void test(virtual Child* p)
{
  p->prefix();
  p->describe();
}
 
for(Parent* p : vector)
  test(p);

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

Цитата MyNameIsIgor @ 31.10.14, 10:35

По семантике это как раз предложение от Страуструпа и Ко по мультиметодам

Да, думаю, так лучше.

Цитата MyNameIsIgor @ 31.10.14, 10:35

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

Ну, мой огород этого тоже не позволяет, но само по себе решение этой небольшой проблемы с test покрывает 99% случаев использования рантайм-рефлексии, ИМХО.

Добавлено 31.10.14, 10:43
Вообще для упрощения можно было бы ограничиться для начала не мультиметодами, а просто "внешними" методы.

Цитата korvin @ 31.10.14, 10:42

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

Имеешь в виду возможность добавления в класс методов без его изменения? Типа этого? Просто это рассматривается как изменение на уровне синтаксиса. А документ по мультиметодам скорее сосредоточен на способе их реализации, и для одного параметра вызов foo(bar) полностью эквивалентен существующим виртуальным методам bar.foo()

Создал тему с мультиметодами в Общих вопросах. Кому интересно, прошу милости.

Цитата MyNameIsIgor @ 31.10.14, 11:03

Имеешь в виду возможность добавления в класс методов без его изменения?

В целом да, только локально, а не глобально, т.к. иначе это будет не адекватно работать в многопоточном коде.

Цитата MyNameIsIgor @ 31.10.14, 11:03

Типа этого?

По беглому просмотру -- да, типа этого.

Цитата korvin @ 31.10.14, 12:18

В целом да, только локально, а не глобально

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

Цитата korvin @ 31.10.14, 12:18

иначе это будет не адекватно работать в многопоточном коде

Ну, у нас не динамика типа CL и Ruby На самом деле никаких структур данных, относящихся к классу, во время исполнения изменяться не будет, всё это происходит при компиляции/линковке - вставка адресов невиртуальных функций и заполнение таблиц виртуальных функций.

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

Цитата Qraizer @ 02.11.14, 03:50

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

У Комитета нет почтового ящика для приема заявок от населения? =)

Цитата Qraizer @ 02.11.14, 03:50

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

Эммм.... Если возьмёшься переписать свой текст на англицкий - могу забросить в список рассылки ACCU. Там более-менее серьёзные товарищи тусят.

Когда ж мне этим заниматься? Я на этот-то русский потратил 9 часов