И какое лучше и на что влияет?

В яндексе забанили?

сложно придумать более идиотский вопрос...

(2)а ты ответь на него, а то все такие умные

http://msdn.microsoft.com/en-us/library/aa294323(v=vs.60).aspx

(4) Хрень

http://delphiworld.narod.ru/base/com_automation.html

и что это за хня в (4) для VB 6.0??

http://www.learncpp.com/cpp-tutorial/124-early-binding-and-late-binding/

(7)Там объясняется как вообще участвует связываение в процессе построения исполнимого модуля.
P. S. Ты же такой умный, что спрашиваешь? Сам все должен знать.

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

там речь вообще о вещах довольно отдаленных

Вообще-то, если мы выполняем изготовление (компилляцию, ассемблирование и т.п.) исполняемого модуля программы, то есть той его части, которая загружается в сегмент кода и выполняется процессором, но у нас возникает потребность в общении с операционной системой, так как мы как-то должны вводить и выводить данные.
Также есть желание использовать кучу уже написанных и отлаженных функций, которые находятся в библиотеках или других исполняемых модулях.
Конечно, если у нас есть текст самой функции, то мы можем изготовить из него кусок исполняемого кода и добавить его в нашу программу.
Это будет статическая библиотека.
Преимущества такого подхода в том, что весь код у нас в одном файле и не требуется никакой установки программы для того, чтобы код начал исполнение (кроме размещения программы на диске).
Однако, размер программ в этом случае становится достаточно большим (хотя, размеры современных винчестеров это хорошо переварят).
Но, как только мы хотим выполнять какие-то функции операционной системы, у нас возникает желание воспользоваться опосредованными вызовами функций, чтобы не изучать устройство самой операционной системы и не иметь проблем при смене версии. В этом случае у нас функции будут жить в отдельном загружаемом модуле - обычно такой модуль имеет расширение dll (хотя, для современной системы не важно имя даже самой программы, так как в функции запуска просто указывается путь до файла, который должен иметь правильный формат, а его расширение - это просто дань традиции).
Если функция находится в DLL, то напрямую мы её вызвать не можем, так как мы не знаем, во-первых, в какое место будет загружен код DLL, а во-вторых, где в DLL находится сама функция. Поэтому, был придуман специальный механизм, который позволяет находить функции в DLL.
Это можно сделать двумя путями - самый простой, это запомнить положение функции в DLL по смещению от начала сегмента. При загрузке dll в память эта величина не поменяется, как бы не менялся адрес самой dll в адресном пространстве процесса.
Такой подход называется "раннее связывание", то есть мы должны заранее знать положение функции в DLL, причём ещё на этапе изготовления нашей программы. Также программа будет очень чувствительна к изменению версии dll, так как положение функции может поменяться. Однако, это ограничение всегда обходят, создавая в начале сегмента dll "переброски", то есть таблицу заранее заданных адресов функций, указывающих на реальное положение функции в dll. В этом случае нам нужно просто знать номер функции в таблице, и всё становится просто и ясно, за исключением лишнего вызова (но современному процессору лишний вызов - не помеха).
Второй способ - это поиск функции по заранее заданным критериям. Обычно по имени функции. Это позднее связывание. На этапе сборки программы мы знаем только имя нашей функции, то есть некоторую строку, однозначно определяющую функцию в dll. При загрузке Dll в память, мы создаём таблицу соответствий, примерно также, как в предыдущем случае, только в таблице мы указываем не все функции из dll, а только необходимые нам, а также указываем их имена - далее, в таблице dll ищутся наши функции, и выполняется установка адресов на реальные положения функций в dll уже с учётом всех размещений. Минус этого метода в том, что надо хранить таблицу имён функций как в dll так и в нашем процессе, которая будет занимать адресное пространство нашего процесса. А плюсом является то, что мы можем не знать ничего, кроме имени нашей функции, чем даём свободу разработчику dll, который может добавлять новые функции и не заботится об однозначном размещении их в таблице по номерам. Конечно, один лишний вызов также остаётся, так как нам нужно запрашивать адрес функции из таблицы (или из переменной, если мы получили его в момент исполнения через GetProcAddress). Однако, самое главное, что запрос по именам позволяет использовать dll даже на другой системе, главное, чтобы не менялось имя функции и не менялся список её параметров.

(12) Вроде как это еще не все

В раннем связывании поскольку на этапе компиляции известны типы параметров, при вызове фнкции они передаются как есть. При позднем они всякий раз преобразутся к VARIANT

(13)Это применительно к какому языку программирования?

Этот вопрос применительно к C++ больше задавался. Хотя можно и в общем.

(13) Это про OLE-объекты и VTBL внутри интерфейсов - то есть различие в использовании IDispatch вызовов и ITypeInfo - в первом случае нет информации о вызываемой функции, и передаём всё как массив параметров Variant и вызываем по имени, а во-втором случае - можно вызывать по индексу функции в виртуальной таблице класса.
Но, это уже связывание объектов в компонентно-объектной модели программирования. То есть когда мы вызываем не функции из чужого кода, а создаём в своём виртуальный объект, имеющий задокументированный набор функций (интерфейсов) и работаем через эти функции или методы. В этом случае сам объект может находиться даже на другой машине, а подсистема OLE будет прозрачно (интерфейс IMarshal) переносить наши данные из адресного пространства нашего процесса в процесс, в котором живёт нужный нам объект через различные механизмы удалённого вызова процедур.

+(13) Типы параметров заданы на этапе проектирования интерфейса. Если мы хотим использовать объект более чем в одном приложении, то мы должны или выбрать один из стандартных интерфейсов или написать свой (тогда ещё и библиотеку типов).
Если же мы хотим просто вызывать функции объекта, то можно воспользоваться прямым вызовом функций из DLL по их адресу - тогда действительно должны быть известны все параметры функции, так как при ошибке произойдёт краг программы, а не ошибка вызова интерфейса. Но, вызов функции напрямую - это не есть использования подсистемы общих объектов. Хотя, если мы передаём указатель на класс, то первым параметром в нём будет таблица виртуальных функций (VTBL), по которой мы смело можем делать вызовы. Однако, никакого переноса данных между границами процесса нам не светит.

(2) >> сложно придумать более идиотский вопрос...
+1
тем более без контекста. Эти термины не в одной области применяется.

(18)Контекст C++. Суть в том, что есть что-то общее у всех этих терминов.

(19) Я владею с++. Но телепатией не обладаю.

(20)и сколько ты получаешь?

ну в смысле хорошо ли ты владеешь

(20) На Си++ надо писать, а не владеть (компилятор-то, покупать не обязательно :-)

(23)типо сексом надо заниматься, а не говорить о нем.