» Вопросы по Embarcadero RAD Studio XE3

Нет и не будет. Или это уже не Дельфи будет.

Люди и так накосячить умудряются, а ты им еще ромбов на дорожку подкинуть хочешь...

Цитата:

Возможность множественного наследования появилась или нет ?

Я читаю литературу по программированию С++. О множественном наследовании говорят, что это зло. В качестве удачного применения приводят библиотеку MFC, но тут же говорят, что это исключение. Может множественное наследование реально не нужно?

как пишут в википедии "В список языков, поддерживающих множественное наследование, входят: ... Delphi (благодаря Class Helpers)" (:

LG Team

Цитируя официальную справку: «Helpers are a way to extend a class without using inheritance...», тем более, что присутствует ряд ограничений таких, как:
- один хелпер на один класс/запись в пределах одной области видимости
- нельзя таким образом добавлять новые поля в структуры (разве что поля класса, но они как бы глобальные переменные с ограниченной областью видимости)

Ну и: «...but they should not be viewed as a design tool to be used when developing new code. For new code you should always rely on normal class inheritance and interface implementations.»

Так что неправильно пишут. Не читают справку )

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

exteris, множ. наследования в Делфи действительно нет. Во всяком случае в том виде в каком оно есть в С++. Однако, программируя на этом языке более 5 лет, я понял, что в нем очень много других возможностей, и порой не менее удобных, чтобы реализовать все что я только могу себе представить. Изучайте этот глубокий и емкий язык и поймете о чем я говорю.

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

limarukraine

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

В общем, крайне полезный механизм, настолько, что Nick Hodges призывает использовать ТОЛЬКО интерфейсы. Проект Spring4D и блогозаписи про него дают общую картину возможностей!

limarukraine

Цитата:

возможности реализации множественного наследования не было.

И слава богу

Цитата:

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

Имея не меньший опыт, полностью вас поддерживаю
Оно это наследование мне никуда не упало.

exteris
Почти все отказались от множественного наследования. От него проку не много, но вот код он запутывает порядочно и суппорт просто ужасен.
С интерфейсами все прозрачно и красиво. Тот же Microsoft отказался в C# от множественного наследования.

salexn1

Цитата:

Тот же Microsoft отказался в C# от множественного наследования.

А по-другому и быть не могло ... ведь C# был создан тем же человеком, что и Delphi: Хейлсбергом. За что ему огромный респект .. и Вирту тоже.

Но ведь дело не только в Хейлсберге и DotNet.
возьми Яву - в Скале нет множественного наследования, а есть "обычаи" - traits.

Не нравится managed - возьми компилируемые языки - например D, "наследник" C++ - то же самое.

Ромбическая проблема всех задолбала и люди пришли к выводу, что родитель нужен один. А остальные куски кода либо должны заново реализовываться ( Interface + delegation) либо подмешиваться на подчинённых ролдях не перебивая основного родителя (mixins)

http://dlang.org/template-mixin.html
http://ru.wikipedia.org/wiki/Примесь_(программирование)

Arioch1
Да, не только в нём, но он повёл C# в правильном направлении и теперь этот Delphi-like с синтаксисом от С и парой-тройкой фич язык вызывает у всех nerdgasm'ы и восторги, и пипл хавает

Что касается множественного наследования, то тут я соглашусь: Не очень удобный подход, если он применяется в крупный проектах и очень часто. Разобраться что к чему вообще невозможно. И правильно делают, что отказываются от него.

Eternal_Shield

Цитата:

парой-тройкой фич

Ну это вы перегнули палочку то... До С# дельфе еще ого-го и еще немного. Так конечно можно все свести к ассемблеру: подумаешь к асму добавили пару фич и получили Дельфи

salexn1

Ну - а какие фичи в C# есть супротив дельфей? await/async? (про GC не надо) - еще?

Правда - любопытно чек-лист составить!

нормальные дженерики работающие с числами, строками и т.д.
В Delphi нельзя сделать


Цитата:

function<T> MultAdd(const a,b,c:T):T;
begin
Result := A*B+C; end;

Еще интересно что там вместо класс-хелперов было ?

Arioch1

Ну - что то похожее есть:

_http://docwiki.embarcadero.com/RADStudio/XE3/en/Operator_Overloading_(Delphi)

deks

Цитата:

await/async?

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

salexn1

Цитата:

До С# дельфе еще ого-го и еще немного.

Я про идею и дух языка говорил и вот от C# (в своём изначальном варианте, без "расширялок") несёт Делфёй за версту. Да и было бы странно, если дитятко (C#) не превзошёл бы родителя ... если вас коробит такое определение, то читайте это так: "русский ребёнок родился в США и теперь говорит по омереканске, но от этого его русский гений не только не пострадал, а стал ещё лучше"

Цитата:

на новую "фичу" это не тянет

само то, что это позволяется через язык - фича.
в OTL это имитируется - но выглядит по другому.

Для сравнения, в Скале using(ресурс){...} из C# ввели через библиотеку.
Сам по себе using - не фиша языка. А во то, что язык повзолил библиотеке так вмешаться в синтаксис - это фишка.


Цитата:

Operator_Overloading

ты предлагаешь авто-боксинг реализовать ? во-первых это скоре всего будет дико тормозить. во-вторых я сомневаюсь, что это сработает. type inferring в Дельфи хреновый (не знаю сильно ли лучше в шарпе - но в Дельфи точно хреновый) - может приджется явное преобразование сделать.

О! вот недавно пробегало, кстати!

Цитата:

procedure<T> Append(const value: T; const container: TArray<T>);

Или что-то подобное.

Попытки вызвать не компилировалось с совершенно дикими сообщениями об ошибке.
Хотя казалоь бы по первому параметру можно было вывести и тип процедуры и тип второго параметра.

Добавлено:
Кстати, меня бесят кложуры в Delphi - синтаксис красив но дико не практичен, лучше бы сделали как C++
Некрасиво ,но удобно

Цитата:

Кстати, меня бесят кложуры в Delphi - синтаксис красив но дико не практичен, лучше бы сделали как C++

Лаконичность можно было бы повысить убрав необходимость по месту объявления ещё раз описывать сигнатуру: все равно до этого тип анонимного метода уже объявлен в секции type.

а если там несколько типов допустмы через overloaded ?

нет, там просто должен быть максимально лаконичный синтакс и type inferring внутри сложура.
Если Result := 10 - то значит тип сложура какое-то число, скорее всего целое.

Делать инферринг по типу параметра, как вы предлагаете, может в рпинципе помочь, но не всегда и не везде. Это уже вторичная, уточняющая инфа.

Eternal_Shield
я согласен, что БЕЗ расширения - читай БЕЗ СИНТАКСИЧЕСКОГО САХАРА - это Дельфи!!!
Если взять первый шарп - то тут ваще идеалогией Дельфи пропитано все насквозь!
Но шарп сильно убежал дальше.... и намного!!!

deks
>Ну - а какие фичи в C# есть супротив дельфей
из крутых фич языка - linq, yield (итераторы).
еще удобны инициализаторы типа (new Obj { param = val }),

salexn1

Цитата:

Но шарп сильно убежал дальше.... и намного!!!

Не удивительно, ибо M$ не Borland/Inprise/CodeGear/Embarcadero, там умные люди работают, а не мосьё! жё не манж па сис жур голодранцы с большого проспекту ...

[OFFTOPIC]
Господа инсайдеры, что-нибудь слышно про Update 1 или все силы (3.5 человека) брошены на SMS (или как там его)?

Eternal_Shield
Свежие утечки можно почитать здесь:
_http://delphihaters.blogspot.com/2012/11/tea-leaves-new-product-manager.html
Если кратко: з/п у разрабов никакие, работать некому, почти все сеньеры разбежались.

GlavBuh
Мда.... пичалька однако...

GlavBuh
Аминь, опять всё катится в ж*&у. Бедная среда, всю дорогу ей с разработчиками не везёт. У ем-ро был шанс основательно поднять на ноги сабж, но они этот шанс проср*ли, ибо язык не был готов к кросс-платформе. Не знаю что и делать ....

Понятно, что за день-месяц-год Delphi не отомрет окончательно, но все идет к тому, что останется только C# и Java...
Пичаль, но что делать...

Пока все это - слухи!

Ну и вы про Objective-C забыли))

Eternal_Shield
У менеджмента, который остался со времен Борланда, не хватает ни силы воли, не желания довести до конца ни один проект. Файрманки мог бы выгореть, если работать над ним не покладая рук, вкладывая средства по крайней мере несколько лет. Но руководству нужна отдача уже сейчас. Они не способны на долговременные вложения с непонятным концом.

Хотя... а вдруг в этот раз оно закрутится как надо. Подождем. В любом случае у нас остается Delphi for Win32, и ему в этой сфере нет равных. Для .NET можно вполне использовать Oxygene. Никаких функциональных ограничений по сравнению с С# там нет. Наоборот, только дополнительные плюшки. Посмотрим, выйдет ли у них что с Android и iOS.