- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
#include <time.h>
#include <string>
#include <iostream>
#include <functional>
using namespace std::placeholders;
class F
{
int inc;
public:
F( int inc_v ): inc( inc_v ) {};
int calc( int x )
{
return x + inc;
};
};
F a1( -10 );
F a2( 11 );
int f1( int x )
{
return x - 10;
};
int f2( int x )
{
return x + 11;
};
struct my_ftor
{
F *obj;
int (F::*meth)(int);
int operator()(int x)
{
return (obj->*meth)( x );
};
my_ftor() {};
my_ftor( F *x, int(F::*y)(int) ) : obj(x), meth(y) {};
};
template<typename functor_type>
void test( std::function<functor_type(int)> filler, char *name )
{
const int size = 1000;
const int iters = 10000;
int beg_time, end_time;
functor_type funcs[ size ];
beg_time = clock();
for ( int i = 0; i < iters; i++ )
{
for ( int j = 0; j < size; j++ )
{
funcs[ j ] = filler(j);
}
};
end_time = clock();
float creation = ((float)(end_time - beg_time) / CLOCKS_PER_SEC);
beg_time = clock();
int res = 0;
for ( int i = 0; i < iters; i++ )
{
for ( int j = 0; j < size; j++ )
{
res = funcs[ j ]( res );
};
};
end_time = clock();
float execution = ((float)(end_time - beg_time) / CLOCKS_PER_SEC);
std::cout << name << " creation time: " << creation << " execution time: " << execution << " result: " << res << "\n";
}
int main(int c, char * * v)
{
test<int(*)(int)>( [](int i) {return i % 2 ? f1 : f2; }, "simple &function test" );
test<std::function<int(int)>>( [](int i) {return i % 2 ? f1 : f2; }, "functor &function test" );
test<std::function<int(int)>>( [](int i) {return i % 2 ? std::bind( &F::calc, &a1, _1 ) : std::bind( &F::calc, &a2, _1 ); }, "functor &object test" );
test<my_ftor>( [](int i) {return i % 2 ? my_ftor( &a1, &F::calc ) : my_ftor( &a2, &F::calc ); }, "obj->*meth struct test" );
std::cout << "END\n";
return 0;
}
Нужно знать дофига.
У истоков Си стоял ассемблер. Любое выражение на Си порождало красивую последовательность ассемблерных инструкций. Программист писал на Си и видел процесс созидания кода. C++ стал закономерным продолжателем Си. Он сочетал в себе мощь ООП, сохранив возможность Видеть. Писать на C++, но видеть машинный код!
А во что превращают язык теперь? Его обмазали синтаксическим сахаром, обвешали бесполезной мишурой. На каждое очередное извращение безумного программиста вводится очередная сахарная хрень, решая очередную бессмысленную задачу. Люди перестали видеть код, они видят только классы, методы, свойства, делегаты. Стыд! Стыд и позор.
Я считаю, что вам всем давно пора вернуться к истокам. Научиться видеть машинный код. И учиться заново, сначала ассемблер, потом Си, а уже после C++2003. Это единственный путь к мудрости. А C++11 сжечь.
'5' - 3 = 2
Самое говно в JS - это сравнение. [,,]==','
Но если такой питуизационный багор, всегда можно избежать говна. Арифметические операторы использовать только с числами (кроме плюса, который ещё и для строк и только них), сравнивать только через === (кроме сравнения с null), не писать полиморфные функции (кстати, это поможет v8 сгенерить годный код), явно приводить переменные к нужному типу. Можно ещё JS выучить - говорят, помогает.
В жабе это - единственное исключение из правил строгой типизации. А жс - это одно сплошное исключение. Почитай wtf тред на stackoverflow, там половина про js.
>Арифметические операторы использовать только с числами
А как ты узнаешь, что в переменной? Типизация-то динамическая!
Да я читал wtfjs.com, думаю, я представляю масштаб бедствия.
> А как ты узнаешь, что в переменной? Типизация-то динамическая!
Только, если это необходимо, человек плохо жнает жс или у него бугурт от динамический типизации.
Главное - чтобы программист знал, что в переменной может оказаться (число; строка; объект X; ...; всё, что угодно) и корректно обрабатывал, не сравнивая переменные с неизвестным типом через ==.
> Слабая типизация не нужна!
Люблю сишку и жс, воспринимаю как оскорбление чувств верующих.
От слабой.
Просто слабая типизация создает столько костылей (вспомните таблицу сравнения php), что что бы она не приносила - оно того не стоит.
>и корректно обрабатывал, не сравнивая переменные с неизвестным типом через ==.
Иначе говоря - отказ от слабой типизации, явная конвертация.
Это помогает компилятору генерировать более оптимальный код.
Что касается системы типов в ж.скрипте - она просто плохо продумана. Почему-то даты стали отдельным типом, строки и "массивы" не являются чем-то похожим, и вообще ближе к числам в плане обращения с ними. Есть мистический "класс" Math, который вроде и не класс, а вроде и класс. Регулярные выражения - иногда функция, а иногда объект. Нет возможности нормально проверить относится ли объект к определенному классу (подчерк, например, парсит результат от toString, instanceof не работает иногда изза проблем безопасности, сравнение прототипов - аналогично, isPrototypeOf - аналогично.
Еще раз: проблема совсем не в том когда определяются типы, а в том как построена система их взаимодействия и каке у программиста есть возможности по отладке и конструированию.
Т.е. typeof Date(12345) == "string"
разница двух дат станет той ещё головной болью
самое благоразумное хранить внутри даты число в виде счетчика от какой-либо эпохи + отдельно обрабатывать понятие временной зоны
и насколько я понимаю, внутри оно так как раз и есть - счетчик миллисекунд (хотя в том же Oracle дата-время (date) хранит представление в числе с плавающей точкой, где целая часть - дни, дробная - дробная часть дня - т.е. время).
> var x = new Date();
undefined
....
> var y = new Date();
undefined
> y - x;
6953
> Number(new Date());
1391760234169
> String(new Date());
"Fri Feb 07 2014 12:06:40 GMT+0400 (Московское время (зима))"
что не так?
нет более удобных функций преобразования Date(), хранящего счетчик, в строку?
А то, что минус так работает для дат - это та же жопа, что и плюс для строк. Сэкономили на спичках, потеряли на покупке машины: то, что минус не работает так, как работает математическое отнимание делает работу компилятора неефективной, т.как многиe оптимизации становятся невозможными. При чем это делает работу неефективной не для дат, а для всего остального, что использует минус.
ЗЫ. String(new Date()) - говнокод по определению, упрощается до Date().
> делает работу компилятора неефективной, т.как многиe оптимизации становятся невозможными.
А это не проблемы динамической типизации вообще?
(питушня) (оператор) (питушня) в любом случае будет работать медленнее, чем (известный тип) (оператор) (известный тип). По-моему, если известно, что (число) - (число) или (строка) - (число), то можно сгенерировать оптимальный код (во втором случае сделав (Number(строка)) - (число), где минус оптимален), а если (питушня) - (питушня), то нет.
Честно говоря, они и так достаточно похожи. А если хочется изменяемых строк, можно использовать Buffer из node, или работать с массивами.
> Есть мистический "класс" Math, который вроде и не класс, а вроде и класс.
Чем Вам Math насолил?
> x=Math.sin
function sin() { [native code] }
> x(3)
0.1411200080598672
> typeof Math
"object"
Нормальный объект. Или Вам не нравится, что надо писать "Math.sin", а не "sin", и для избавления от этого нельзя написать простое "using namespace Math"?
Динамической типизации не существует, это некорректное выражение. Есть только время, когда типы выводятся. И это только в контексте лямбда-кубических типов, а не любого подхода к типам. То, что минус работает не как минус, а как какая-то неведомая херня - это недостаток системы типов, вернее, АПИ языка, которые 1. позволили реализовать такое недоразумение, 2. реализовали такое недоразумение.
Это по стандарту нет, или в какой-то реализации?
У меня в Chrome 32 есть:
Зато вот, еще вспомнил, магический класс arguments.
Правда, с учётом наличия геттеров/сеттеров/прокси магия arguments уже не так сильно шокирует.
Вот undefined и Infinity - это да. Во-первых, почему тогда true, и null не lvalue? Во-вторых, раз теперь их не изменишь, почему присваивание не вызывает ошибки?
Мне всегда грустно из-за того, что arguments - не массив. Когда срабатывает очередное Array.prototype.map.call(document.queryS electorAll('div.ok'), function ...);, умирает котёнок начинаешь думать, что они просто троллят со своими массивоподобными объектами.
консолька хрома выдает следующее
function ttt(){ this.n=1}; console.log(ttt());
undefined VM135:2
undefined
function ttt(){ this.n=1}; t= new ttt(); console.log(t.n);
1 VM165:2
undefined
Хотя действительно не ругается молча отдает.
function ClassName(){
this.x = 3;
return 42;
}
var a = ClassName(); // a == 42
var b = new ClassName(); // b == {x: 3}
console.log(a,b);
42 ClassName {x: 3}
Хотя, если б даже можно было, никто не запретил бы сделать ClassName.call(new AnotherClassName) и испортить уже не глобальный объект, как в моём примере выше, а переданный.
По-моему, лучше как-то так:
В strict mode в этой ситуации он будет как раз undefined.
Ах тыж ебаный ты нахуй
ЗЫ. А как ж.скрипт поможет с типизацией во время компиляции?
ЗЫЫ. "Динамическая типизация" в этом контексте - разговор ни о чем. Обычно под "динамичностью" понимают, что определение типов (что бы мы типами не называли) откладывается на какое-то время. В ж.скрипте никто не запрещает вывести типы и потом его скомпилировать (тот же Юнити так и делает, например).
http://www.gamedev.ru/flame/forum/?id=185727&page=4#m55
Да там какие-то извращения в моде. Девушек наверн нет у них.