Kolyaj,
ты не прав.
ничего он не переиминовывает-сам выбирает какую применить-это да. но по сути дела бормалей вынес выбор действия в зависимости от аргументов в тело функции-за неимением у скрипта этого механизма. с таким же успехом он мог сделать одну функцию общую-где в зависимости от типов и колва аргументов шел бы переход на другие функции с разными именами-чем не механизм реализации перезагрузки функций. после компиляции с++ ведь не к именам функций будет обращаться а к адресам и введёт в код тотже механизм определения действия
http://programmersclub.ru/13/

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

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

Ссылка не по теме. Там описывается как использовать, а не как реализовано.

по сути - это перегрузка, а реализация - да, разная. И спор этот из серии "у кого круче уровень абстракции"...

x-yuri насколько я помню в первой книге Рейсига подобная реализация перегрузки. По сути же перегрузка в привычном понимании - это создание нескольких функций с одним именем (через класс допустим...) с указанием типа возвращаемого значения и параметрами. Иными словами, каждое переопределение функции должно иметь разные типы параметров или их количество.

#include <iostream>
using namespace std;

int foo(int i, int j);
char foo(char i);

int main(){
	count << foo(10, 20) << '\n';
	count << foo('str');
	return 0;
}

int foo(int i, int j) {
	return i;
}

int foo(char i) {
	return i+j;
}

А что касается из серии... то это больше похоже на обсуждение реализации классов в JS :D

хотя, может, и по сути - не перегрузка. А B@rmaley.e><e просто симитировал ее средствами js. А так как от перегрузки больше вреда, чем пользы, то непонятно, чего мы вообще об этом спорим ;)

я имел в виду, что можно смотреть на вопрос с точки использования и с точки зрения реализации, например. Абстракция имеет смысл не только в контексте ООП, ага... ;)