Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата KILLER @ 17.03.11, 15:45

Потролить ты хател сказать ?

А?

Цитата Астарот @ 17.03.11, 16:01

А?

Та ладно, проехали... а то и так уже тролим..

Цитата korvin @ 17.03.11, 15:57

только я не понял, что за "семантическая проверка" там есть в опциях o_O'

Это проверка стиля. Отступы, пробелы, одинаковое написание идентификаторов... Скажем, открываем любой проект, выбираем в опциях Switches -> Ada -> Style Checks все, что хочется, и проверяем семантику:

Прикреплённая картинка

Все, что желтое - не прошло проверку... А нужно - чтоб не было разнобоя в исходниках...

Цитата volvo877 @ 17.03.11, 16:08

Это проверка стиля. Отступы, пробелы, одинаковое написание идентификаторов... Скажем, открываем любой проект, выбираем в опциях Switches -> Ada -> Style Checks все, что хочется, и проверяем семантику:

Прикреплённая картинка

Все, что желтое - не прошло проверку... А нужно - чтоб не было разнобоя в исходниках...

ну я б не стал называть это семантической проверкой, проверка стилистики по сути =)

Цитата DesweR @ 16.03.11, 07:28

Почему не дошла? Я и Корвин уже высказывались по этому поводу (в принципе добавлять и нечего), но тебя куда понесло...

Только высказывания бредовые, мол, "одноимённые методы разных интерфейсов обязаны стать один и тем же методом, а если нет, то либо авторы интерфейсов индусы, либо я индус".

Цитата DesweR @ 16.03.11, 07:28

Давай ещё раз...

Давай не надо. Плюсы имеют то же поведение. Ты как обычно либо не дочитал того, на что я дважды обратил внимание, либо не понял и постеснялся спросить.

Цитата DesweR @ 16.03.11, 07:28

Внезапно! Я пришёл к выводу, что выполнятся должен не только сигнатурный контракт класса и интерфейса, но и семантический (лукавлю конечно, этот вывод выводится в книге "Сущность технологии COM"). Не знаю кто там с пеной у рта, только вот не надо за меня решать, как я думал и думаю.

Гм. Цитат под носом не хватает? Напомню, изначально разговор зашёл за

Цитата Shaggy @ 14.03.11, 20:37

child наследник parent и оба классы
класс А наследник child
процедура test принимающая в качестве параметра parent
передаём в test экземпляр A, компилируется?

а теперь то же самое для delphi, только child и parent интерфейсы
результат: incompatible types

Я удивился и попросил разъяснений:

Цитата Qraizer @ 14.03.11, 23:32

А почему, кстати? Не в смысле языка, а в смысле логики. ... Теперь если A реализует интерфейс child, почему это он при этом не реализует и интерфейс parent? Иначе с какой стати incompatible types?

Ты начал возражать мне :

Цитата DesweR @ 15.03.11, 06:43

Это отчасти вытекает из идеологии COM'а, ... Тоже самое касается и наследования интерфейсов, должен соблюдаться не только сигнатурный контракт, но и гарантированно семантический, а для этого класс A, должен содержать реализацию интерфейсов и child и parent.

Что я неправильно "за тебя додумал"? Или "...класс A, должен содержать реализацию интерфейсов и child и parent" как раз и надо понимать "...что результат: incompatible types"?

korvin, быстренько набросал на коленке. Да, от кортежей тут почти ничего, получился какой-то compile-time array. Заодно добавил run-time индексирование, вдруг номер элемента придётся вычислять по ходу дела. Сорри за некоторую сумбурность, надеюсь, будет однако понятно.

#include <cstdlib>
#include <sstream>
#include <string>
#include <stdexcept>
#include <iostream>
 
/* Присвоение порядкового номера элементу */
template <typename T, size_t N> struct Item: T {};
 
/* Создание дерева элементов */
template <typename T, size_t N> struct GenerateTree: Item<T, N>, GenerateTree<T, N-1>
{
  typedef Item<T, N> item_type;         // для compile-time индексирования
 
  T& operator[](size_t i)               // для run-time индексирования
  {
   return i == N ? static_cast<typename GenerateTree<T, N  >::item_type&>(*this)
                 : static_cast<         GenerateTree<T, N-1>&           >(*this)[i];
  }
};
/* Последний элемент в дереве */
template <typename T> struct GenerateTree<T, 0>: Item<T, 0>
{
  typedef Item<T, 0> item_type;         // для compile-time индексирования
 
  T& operator[](size_t i)               // для run-time индексирования
  {
   if (i == 0) return *this;
   throw std::range_error(static_cast<std::ostringstream&>(
                                      std::ostringstream() << i << ": index is out of range"
                                                          ).str());
  }
};
 
/* Контейнер */
template <typename T, size_t N> struct Tuple: GenerateTree<T, N-1>
{
  template <size_t I> T& field()        // для compile-time индексирования
  {
   return static_cast<typename GenerateTree<T, I>::item_type&>(*this);
  }
  T& operator[](size_t i)               // для run-time индексирования
  {
   return static_cast<GenerateTree<T, N-1>&>(*this)[i];
  }
};
/* Контейнер длиной 0 недопустим */
template <typename T> struct Tuple<T, 0>;
 
/* Тест */
/* твой класс */
class X
{
  int num;
 
public:
  int  get() const { return num; }
  void set(int x)  { num = x;    }
};
 
int main()
{
  /* делаем 4 элемента */
  Tuple<X, 4> tuple;
 
  /* compile-time индексирование */
  tuple.field<0>().set(123);
  tuple.field<1>().set(321);
  tuple.field<2>().set(456);
  tuple.field<3>().set(978);
 
  std::cout << tuple.field<0>().get() << ' ' << tuple.field<1>().get() << ' '
            << tuple.field<2>().get() << ' ' << tuple.field<3>().get() << std::endl;
 
  /* run-time индексирование */
  tuple[0].set(321);
  tuple[1].set(123);
  tuple[2].set(654);
  tuple[3].set(789);
 
  std::cout << tuple[0].get() << ' ' << tuple[1].get() << ' '
            << tuple[2].get() << ' ' << tuple[3].get() << std::endl;
}

Тут всё открыто, поэтому достать элементы отдельно от контейнера не составляет труда. Могу сказать, что это легко решаемо в новом Стандарте путём перегрузки точки. То же относится и к коду MyNameIsIgor-я, так что "хаков" с auto или ссылками можно не опасаться.

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

Цитата Qraizer @ 19.03.11, 13:22

Только высказывания бредовые, мол, "одноимённые методы разных интерфейсов обязаны стать один и тем же методом, а если нет, то либо авторы интерфейсов индусы, либо я индус".

Концептуально в этом нет ничего странного. Если угодно, можно провести аналогия с концептами...
То есть ты описываешь лишь контракт, поэтому если имя одно и контракт один, то значит и метод один.
А вот для абстрактных классов это уже не справедливо.

Добавлено 19.03.11, 13:49

Цитата Qraizer @ 19.03.11, 13:39

Тут всё открыто, поэтому достать элементы отдельно от контейнера не составляет труда.

Я так понял, что korvin'а это не устраивает. А вот вариант на Ада подошел...

Цитата

Могу сказать, что это легко решаемо в новом Стандарте путём перегрузки точки. То же относится и к коду MyNameIsIgor-я, так что "хаков" с auto или ссылками можно не опасаться.

А будет перегрузка точки? Не слышал о таком(в смысле именно по новому стандарту, сама возможность фигурирует в некоторых книгах, и в D&E тоже упоминается, если не ошибаюсь). Можно подробнее?

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

Добавлено 19.03.11, 13:58
Не уверен, в общем-то. У меня старый драфт нового Стандарта. Там ещё нет. Но слухи ходят, и появились они после того, как я качнул драфт.

Но у тебя же не вызывает опасения схожая ситуация, возникающая при обобщенном программировании:

template<typename T>
void f(const T &obj)
{
    //...
    return obj.mf();
}
 
 
template<typename T>
void g(const T &obj)
{
    //...
    return obj.mf();
}

Можно сказать, что тут для обоих функций неявно объявлен "интерфейс", состоящий из метода "void mf() const". И любая сущность, которая обеспечивает этот интерфейс(точнее предоставляет такой метод), может быть передана в любую из этих функций или в обе вместе.

Тут не вызывает. Они используются по отдельности. При совмещении в единый объект тоже будет вызывать.

Цитата Qraizer @ 19.03.11, 14:12

Тут не вызывает. Они используются по отдельности. При совмещении в единый объект тоже будет вызывать.

В смысле?
Ты в классе определяешь метод

class MyObj
{
public:
//...
 
    void mf() const
    {
        //...
    }
 
//...
};

И передаешь в обе функции:

MyObj obj;
//...
 
f(obj);
g(obj);

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

D_KEY, хм... оформи свои доводы не кодом, а документацией. Уверен, увидишь разницу.

Цитата Qraizer @ 19.03.11, 15:15

D_KEY, хм... оформи свои доводы не кодом, а документацией. Уверен, увидишь разницу.

Разница лишь в явном или неявном задании интерфейса. Разве нет?

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

Цитата Adil @ 19.03.11, 15:23

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

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