Delphi

Ну да, ну да. Макрос на макросе макросом погоняет. И не стыдно «библиотекой классов» называться. Некоторые почему-то OWL предпочитали этой твоей MFC.

И не просто паскаль, а с костылями, реализующими ООП, указатели на функции
указатели на функции

указатели на функции только в С кошерные, остальное - костыли?
ды ты упоролся!

Большинство программ на нём очень своеобразно кривы.

сотни пруфов кривизны программ на делфях и прямизны поделок на C++ вижу я в этом треде

Че правда? У меня почему-то хедеры все были плюсовые.

#include <vcl\vcl.h> //Паскалевские хидеры такие паскалевские

Если не было хедера к какой-то левой библиотеке - он дописывался руками по выхлопу dumpbin, например.

Повторное использование кода на основе компонентных моделей было модно в те времена (Майкрософт, например, впаривала из года в год новые сорта развесистого OLE под новыми торговыми марками «COM», «ActiveX» и называло это «визуальным программировнием», хотя без траха с макросами в С++ там было нельзя, а самый Ъ-визуальный из продуктов офтопика VB тупо не умел делать новые компоненты - только комбинации из старых, написанных на C++). А RAD считалось вполне прогрессивной технологией, достоинства которой, неверно понятые 95%, сыграли с ней злую шутку.

Че правда? У меня почему-то хедеры все были плюсовые.

А ты загляни, какие хидеры подключает этот «плюсовый» хидер, ну и поглубже - тогда увидишь.

Вижуал барсик долго не умел компиляться в нативный код, а до 5-го, кажется, включительно, не умел создавать новые компоненты на самом себе. Так что сравнивать можно, наверное, щас... (6-й был по отзывам торт) Но он изначально имел кучу сбивающих с толку диалектов VBA, VBS (последний относится к VB, как JS к С++) с похожим синтаксисом, но разными возможностями и несовместимостями между версиями, а VB.NET - это практически другой язык поверх .NET. :)

указатели на функции только в С кошерные, остальное - костыли?

Покажи мне не костылевую реализацию указателей на функцию, кроме С. //Я, конечно, могу чего-то не знать, но то, что сделано в делфи - убогие костыли.

ды ты упоролся!

Новую фразу выучил?

А твои «изкоробочные» плюсы изначально были «Си с классами».

Тем не менее, это стандарт. А делфивский код только делфи соберет.

А зачем? Лезть в кишки библиотеки, заигрывая с intrinsicами среды и недокументированными функциями извращение само по себе. Есть интерфейсный заголовок - пользуйся. А копаться в подверженном изменениям промежуточном слое, ориентированном на compiler magic, который от версии к версии может меняться - сомнительное предприятие. К сторонним либам на паскале просто дописывался обычный плюсовой заголовок по описаниям структур и сигнатур функций.

Дельфы были одни такие на одной платформе - стандарт явочным порядком. :) Потом появилась Kylix с вполне портабельной библиотекой CLX, но у хозяев борланда случился ФГМ. А правильно написанный код щас и Lazarus может собрать. (Если на C++ не придерживаться кое-каких правил, на которые с радостью забивают многие «программисты на С++» - никто кроме их родного компилятора этот код не соберет.)

Покажи мне не костылевую реализацию указателей на функцию, кроме С

а в чем разница с паскалем, если не секрет? ну кроме чуть более компактной записи

Новую фразу выучил?

ага, петросянить пытаюсь

Загибается от устаревания вроде.

Ну да, вот это:

type TProc  = procedure();

var p: TProc;

procedure X;
begin
 WriteLn('Hello dieing world!');
end;
begin
 
 p := X;

 p;

end. 

конечно, куда как костыльнее тучи мозговыворачивающих скобочек вроде этого чуда:

double (*(*f)(double(*)(double)))(double)

А что? VB был вполне себе неплохой RAD средой для разработки всяких (не)сложных программок для учёта и автоматизации. Многие идеи которого, кстати, перекочевали в .net

Самое смешное, наверное, что многие дельфовые идеи перекочевали в .Net вместе с главным разработчиком.

в .net идеи много откуда в итоге перекочевали.

Ага. Только Хейлсберг у руля был всю дорогу.

А собственно какая разница? инструмент получился весьма удобный. Как по мне, так удобнее чем ява или C++

Ты щас про что? Про .Net? или... про сабж? :)

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

Покрайней мере честный ответ)

Знал бы побольше, ввязался бы в троллинг :) а так бессмысленно, сольюсь же почти сразу. :)

Ну, .Net удобнее во многих отношениях... Только если не сталкиваться с ограничениями дотнета :)

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

Ну почему не верно и сразу вкорне. Если похерить разом весь унаследованный код (к котрому как бы относится то, что спрятано под зонтичной торговой маркой «Windows DNA») никто щаслив не будет. С++/CLI умеет экспорты из сборок, а C# нет. И весь P/Invoke с интеропом становятся похожи на бочку меда^W^Wсинтаксического сахара, разбавленную осознанием, что для того же, что на синтаксически вычурном C++/CLI получается только фпуть, но отвратительно выглядит, на C# нужен IL-хак (чуваки даже патчилку сборок писали на промежуточном коде).

отличный пример плюсового мышления. Экспортить функции из дотнетовских сборок занятие неблагодарное. Не забывай, что там managed код, а он за собой много чего тянет, поэтому реализовать экспорт - занятие неблагодарное, для этого есть managed C++.

Дотнетовские сборки это верхняя часть логики и если её требуется экспортить «вниз» - значит в консерватории что-то не так.

Странно тогда зачем и ЧЕМ живут ещё эти языки.

Десятками тысяч уже написанных на них приложений.

Зачем мне, например, изучать С++/CLI (та еще надстройка над нормальными плюсами!), если я, например, знаю С#, но есть необходимость сопрягать .Net c реальным внешним миром, а не с розовой мечтой об удобной платформе (которая, кстати, традиционно тяготеет к «монокультуре», а не открытым стандартам)? Могли сделать все доступным на C#, но не сделали - ЧСВ помешало, хитрый план по монополизации рынка («жаба подвинься!» (ТМ)) или «очки запотели»? При этом для IL-хаков осталась полная свобода :) Надо - ипитесь сами. А оправданий можно много всяких придумать, почему видите ли всем и сразу надо отбросить «отжившее наследие темных времен» и пойти за дудочкой маркетолухов :)

возьми моно да напиши что надо в компилятор байткода :)

Изначальная идея была как раз в том, что .net это вещь в себе, которая умеет использовать неуправляемый код, но ограниченно(pinvoke в частности). Это я так понял было одной из черт дизайна.

И да, ИМХО, практически любая «удобная платформа» начинает тяготеть к монокультуре.

Ну да. Проходили поднимание WCF на нативной проге с API плагинов :) Не хотелось париться с сопряганием микрософтовского понимания SOAP и нюансами других реализаций (велосипедный парсер WSDL, который пришлось бы изобрести, или перепилить «почти готовый» сторонний, ничем не лучше IL-хака, тот хотя бы заметно сэкономил время, хотя плохим тоном от этого быть не перестал). Тут понимаешь все в малости заключается, которая огороживает удобства интероперабельности каким-то нелепым, маркетинговым скорее всего, забором. Технически-то ничего сложного в такой фиче нет. В плюсах впилили (изуродовав плюсы) - и это во благо? :)

К сторонним либам на паскале просто дописывался обычный плюсовой заголовок по описаниям структур и сигнатур функций.

А я о чем?

а в чём смысл поднимания wcf на нативной проге?

тучи мозговыворачивающих скобочек вроде этого чуда:

Я рад за это чудо, но какое оно имеет отношение к С++? Как финальный аккорд, переведу ваш же пример на С++:

typedef void(*TProc)();

TProc p;

void X()
{
 printf("Hello dieing world!\n");
}

int main()
{
 p = X;
 p();
 return 0;
}

Покажи мне не костылевую реализацию указателей на функцию, кроме С. //Я, конечно, могу чего-то не знать, но то, что сделано в делфи - убогие костыли.

Ололо, откуда взялся С++, если вы ратовали за С? Delphi (комментарий) А если приведенный пример - это пруф того, что разницы нет - тогда раскройте суть утвержденя об «убогой костыльности» указателей на функцию где-либо, кроме С. В чем костыльность? В чем убогость? Бремя доказывания на утверждающем ;) Иначе получаются /0 и параграфы, а «финальный аккорд» не подтверждает - а полностью опровергает первоначальное утверждение. (Либо в дельфи не костыльные, либо в С/С++ не лучше. Или вам операторы @ и ^ просто не нравятся? :))

В использовании одинаковой инфраструктуры middleware с минимальными издержками.

О паскальных заголовках VCL, которые вам чем-то мешают жить.

какое оно имеет отношение к С++?

Так таки никакого? Если мы тихо отставили бескостыльность указателей на функции в C (ничем не обосновав это утверждение) и внезапно перешли к обсуждению С++... Только не говорите, что в С++ синтаксис вроде

 double (*(*f)(double(*)(double)))(double) 

невозможно встретить :)

Только не говорите, что в С++ синтаксис вроде double (*(*f)(double(*)(double)))(double) невозможно встретить :)

Именно это я и хочу сказать.

Именно это я и хочу сказать.

И зря, потому что 4.2. http://tinyurl.com/bol8p6h Пример как бы канонический. Так что насчет убогости/костыльности указателей на функции в Delphi? не надо на С++ съезжать (про него тут полно желающих объяснить про костыльность-убогость, да и как «С с классами» его использовать никто не запретит)

Ладно, скомпилировалось (после объяснений, что оно должно делать). Тем, не менее, КГ/АМ, ибо по-хорошему оно будет выглядеть так:

typedef double (*dfunc)(double);
dfunc (*f)(dfunc);

Ведь типа данных «dfunc» наверняка понадобится и дальше, и не в одном месте.

КГ/АМ КГ/АМом, но чем этот КГ/АМ лучше(бескостыльнее? благодатнее?) записи

type TProc = procedure();
     TProc2 = procedure(p: TProc);
     PProc = ^TProc2;
var p1: TProc;
    p2: TProc2;
procedure x;
begin
 WriteLn('Hello bogus world!');
end;
procedure y(p: TProc);
begin
  p;
end;

 var pp: PProc;
begin

  p1 := x;
  p2 := y;
  pp := @p2;
  TProc2(pp)(p1);
end. 

вот чего мне непонятно :) Это не считая того, что в Delphi при правильном использованиии очень редко могут понадобиться указатели на функции, но если очень чешется - обработчики пристегивать или экспорты либ каких дергать надо - то почему бы и нет.

Код не распарсил. В частности, что означает тип «PProc»?

Это не считая того, что в Delphi при правильном использованиии очень редко могут понадобиться указатели на функции

В _любом_ ЯП при правильном использовании указатели на функции почти не нужны (кроме событийно-ориентированного программирования).

Ну речь не о любом) Мы тут С с Delphi сравниваем и только в отношении к указателям на функции (раз уж они кривые). Торадицийонно, в паскале запись вида type PType = ^Type; - указатель на объект типа Type :) Появилась задолго до самих дельфей. В книжках Вирта встречается много где, а Фаронов В.В. так и вовсе злоупотребляет :)

Ага, так ^ в паскале - указатель, а @ - разименовывание? Остается она неясность: допустим, у меня есть функция без аргументов, которая возвращает указатель на функцию (тоже без аргументов). Как мне получить и вызвать последнюю одной строчкой в паскале?

@ - взятие адреса вообще-то. Некий аналог &
Разыменование аналогично ^, только справа от указателя на объект
.

По существу вопроса:

//Для процедуры
type TProc = procedure();
     PProc = ^TProc2;
procedure x;
begin
 WriteLn('Hello bogus world!');
end;
function xx: PProc;
begin
  Result := @x;
end;

begin
  TProc((xx));
end. 

если нужна именно функция «одной строчкой» где-то в выражении:

//Для функции
type TFunc = function: boolean;
     PFunc = ^TFunc;
function x: boolean;
begin
 WriteLn('Hello bogus world!');
 Result := true;
end;
function xx: PFunc;
begin
  Result := @x;
end;

begin
  if TFunc((xx)) <> false then X; //(в условии выполняется то же, 
                                  //что и в блоке)
end. 

а обзывают его вон «язык общего назначения»

Вроде как Delphi - это средство RAD, а язык называется - «Object Pascal» (видоизменённый Borland Pascal).

С Delphi 7 также стал называться и борландовский диалект Object Pascal'я. В FPC есть даже специальная переключалка между OP и Delphi ( {$mode Delphi} vs {$mode objfpc} ).