Delphi vs C++ , Часть 1

Цитата --Ins-- @ 04.03.08, 11:29

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

Да можно, можно. Правда, такая фигня получается...

Цитата

Да можно, можно.

С этого момента - поподробнее, пожалуйста... Я так понял, Вы хотите сказать, что в компиляторы C++ (Builder стоит особняком) встроены лексические анализаторы и компиляторы языка Delphi?

Цитата b-a1 @ 03.03.08, 18:20

Просто нужно хотя бы поверхностно быть знакомым с обоими областями

ну так я знаком и даже не поверхностно, а нормально!
просто я хотел сказать что на Delphi намного проще импортировать функции и писать DLL'ки.

Цитата --Ins-- @ 04.03.08, 12:43

С этого момента - поподробнее, пожалуйста... Я так понял, Вы хотите сказать, что в компиляторы C++ (Builder стоит особняком) встроены лексические анализаторы и компиляторы языка Delphi?

Я же говорю - фигня получается. Это был шютк, --Ins--, расслабьтесь

Цитата Ahilles @ 04.03.08, 12:49

просто я хотел сказать что на Delphi намного проще импортировать функции и писать DLL'ки.

Ок, пишу DLL на С++:

#define EXPORT __declspec(dllexport)
 
EXPORT void foo()
{
  // ...
}
 
EXPORT int x;

В чём здесь принципиальная сложность?

Дальше, пишу прогу, использующую эту DLL:

#include <ostream>
#include <iostream>
 
#define IMPORT __declspec(dllimport)
 
IMPORT void foo();
IMPORT extern int x;
 
int main()
{
    foo();
    std::cout << x << std::endl;
}

А здесь в чём сложность?

Цитата Ahilles @ 04.03.08, 12:49

просто я хотел сказать что на Delphi намного проще импортировать функции и писать DLL'ки.

Пример в студию, ибо неочевидно.

Цитата ch__ @ 04.03.08, 19:57

Пример в студию, ибо неочевидно

Не надоело очевидными вещами перекидываться? На самом деле Вы все неправы, проще всего на асме:

procdesc SQLAllocHandle :DWORD,:DWORD,:DWORD
 
includelib      ".\lib\odbc32.lib"
 
....
        call    SQLAllocHandle, SQL_HANDLE_ENV, SQL_NULL_HANDLE, ebx

Цитата --Ins-- @ 04.03.08, 11:29

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

Нет. Мысль была в том, что это Delphi'стам нужны сишные библиотеки(откомпилиролванные в DLL), а не наоборот. Поэтому Borland и решила решить вопрос библиотек встраиванием некоей конструкции в язык ObjectPascal.

Добавлено 05.03.08, 07:40

Цитата AndNot @ 04.03.08, 21:08

Не надоело очевидными вещами перекидываться? На самом деле Вы все неправы, проще всего на асме:

#pragma comment(lib,"odbc32.lib")
void SQLAllocHandle(int, int, int);
...
SQLAllocHandle(0,SQL_HANDLE_ENV, SQL_NULL_HANDLE);

Цитата trainer @ 05.03.08, 07:38

#pragma comment(lib,"odbc32.lib")
void SQLAllocHandle(int, int, int);
...
SQLAllocHandle(0,SQL_HANDLE_ENV, SQL_NULL_HANDLE);

А проще можешь

extrn SQLAllocHandle
...
        call    SQLAllocHandle, SQL_HANDLE_ENV, SQL_NULL_HANDLE, ebx

Цитата

Нет. Мысль была в том, что это Delphi'стам нужны сишные библиотеки(откомпилиролванные в DLL), а не наоборот. Поэтому Borland и решила решить вопрос библиотек встраиванием некоей конструкции в язык ObjectPascal.

Понятно. Согласен, только там не только под C/С++ подстраиваются, а в общем-то под все, что только может быть. Модели вызова подпрограмм у разных языков свои, где-то параметры через стек передаются, где-то - через регистры, где-то - слева-направо, где-то справа-налево. Где-то принято стек за собой подчищать самой подпрограмме, а где-то - вызывающему коду. На эти различные случаи и предусмотрены директивы вызова, чтобы можно было безболезненно использовать "чужие" библиотеки, даже если правила вызова функций в них не совпадают с принятыми в Delphi правилами. Думаю, вы это и без меня знаете.

Цитата AndNot @ 05.03.08, 09:21

А проще можешь

могу.

void SQLAllocHandle(int, int, int);
...
SQLAllocHandle(0,SQL_HANDLE_ENV, SQL_NULL_HANDLE);

Могу и еще проще

SQLAllocHandle(0,SQL_HANDLE_ENV, SQL_NULL_HANDLE);

Это в расчете на то, что никто из пишущих на C/C++ ассемблера не знает?

trainer, а теперь поясни Не врубился

Цитата AndNot @ 04.03.08, 21:08

Не надоело очевидными вещами перекидываться? На самом деле Вы все неправы, проще всего на асме:
procdesc SQLAllocHandle :DWORD,:DWORD,:DWORD

includelib ".\lib\odbc32.lib"

....
call SQLAllocHandle, SQL_HANDLE_ENV, SQL_NULL_HANDLE, ebx

а FASM'y вообще не нужны *.LIB.
На Delphi порсто пишешь что функция external и всё! больше ничего не надо!
Т.е. я хочу сказать что на Delphi и FASM НЕ НУЖНЫ лишние файлы, только сама DLL и всё!

Сообщение отредактировано: Ahilles - 05.03.08, 10:39

Цитата

только сама DLL и всё!

Строго говоря, сама DLL тоже не нужна. Без нее прекрасно скомпилируется (но не запустится).

PS: Всегда говорил, что C/C++ - это язык дьявола! (см. вложение)

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

Цитата Ahilles @ 05.03.08, 10:37

а FASM'y вообще не нужны *.LIB.

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

Цитата Ahilles @ 05.03.08, 10:37

Т.е. я хочу сказать что на Delphi и FASM НЕ НУЖНЫ лишние файлы, только сама DLL и всё!

А вот мне, под тасм, вообще не нужно расписывать прототипы экспортируемых функций, достаточно указать препроцессору имена DLL и LIB файлов, а он сам их там найдет и подставит в программу. Т.е. я могу пользоваться любой функцией без ее предварительного объявления Так как там Дельфи то?