В чём практический профит от слабой типизации?

Глядя на грабли с автоматическим приведением типов в c/cpp мне кажется что это зло.

меньше писать и больше возможностей выстрелить в ногу, но выжать из архитектуры всё если промазал.

Мне кажется ты путаешь слабую типизацию с динамической. И да, все языки со слабой типизацией редкостное говно.

это ты щас сишку говном назвал?

Думал, что это опять анонiмус

// 1234

Выключает практически полностью тормоза на создание очень низко-качественного кода.

Но иногда без слабой типизации невозможно обойтись конструктивно - вся ответственность на разработчике.

Да, незаменимые вещи тоже бывают говном.

Можно писать прототип, когда все условия задачи не ясны до конца, либо часто изменяются. А потом случается так, что прототип проще довести до ума, вместо переписывания на надежном языке.

Впринципе, на википедии все описано. Из главного, pointer arithmetic возможен из-за слабого типизирования.

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

Хорошо, почему такой прототип будет сложнее писать на языке со строгой типизацией? Я не понимаю именно этого аспекта.

Заметил что даже имея возможность запихнуть в метод объект левого типа на практике этой возможностью не пользуюсь.

Ну и вобще не пользоваться чем-то это нормально, эти возможности ведь не только для тебя делали, и может вобще специально не делали, так получилось и решили что это ок.

<holywar>Кажется, кто-то путает слабую типизацию с динамической.</holywar>

Заметил что даже имея возможность запихнуть в метод объект левого типа на практике этой возможностью не пользуюсь.
слабой типизации?

Чет я не так прочитал, добавлять методы на ходу это динамическая типпизация, к слабой оно не имеет отношения.

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

запихнуть в метод объект левого типа

добавлять методы на ходу

это вы опять про свой недоязычок js чтоли? не знал даже что методы можно в классы(объекты?) на ходу добавлять и как, кому и где это может пригодиться, кроме как лалкам от js

Чет я не так прочитал, добавлять методы на ходу это динамическая типпизация, к слабой оно не имеет отношения.

При чём тут добавление методов на ходу?

это вы опять

А где предыдущий раз?

свой недоязычок js

Он не мой, а Айковский.

не знал даже

Я уверен что ты многого не знаешь, не обязательно про это повсюду писать.

Что-то я сегодня совсем плохо читаю, пойду отдохну.

хватило бы простого «да» :)

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

И как часто это становится проблемой?

интерфейсы спасут отца русской демократии

Интерфейсы?

в метод передаётся обьект реализующий чётко заданный интерфейс, и с обьектом работают только через этот интерфейс и ни как иначе

Нет, наоборот. Незаменимые вещи — это как правило говно. Если бы они были заменимыми, их бы уже заменили на неговно.

Бывают бывают. Только сиха к ним не относится. Язык си — это лучшее, что все вместевзятые математики и программисты осилили сделать для компутеров за все время существования этих самых компутеров.

Я знаю что такое интерфейс, я не понимаю как он относится к вопросу, который я задал. Более того, так можно делать имея слабую типизацию, вопрос в том, какой тогда прок от слабой типизации?

И как часто это становится проблемой?

это просто удобно, как синтаксический сахар, например

Си просто попал в струю в свое время, рассматривать его как предел совершенной инженерной мысли могут только тупые фанбои. Это такое же нагромождение уродливых легаси-костылей как и любой другой старый язык.

Только тупые могут понимать предложение «лучшее, что сделали» как «предел мысли». Сходи математике с логикой поучись.

лучшее, что сделали

Собственно тоже может быть говном. Невнимательно прочитал, да.

это просто удобно, как синтаксический сахар, например

Какая радость от сахара если его не использовать/использовать редко?

это уже проблемы того кто неиспользует.

Так я и спрашиваю как часто возникает такая необходимость? Может она случается раз в 100 лет.

Вопрос поставлен не корректно. Слабая типизация это не плюс какого-то языка, это необходимый механизм для эфективной реализации некоторых технологий. Например вы пишите библиотеку у которой внешний API совместим с «C» (соотвецтвенно библиотека может использоватся во многих языках к-е потдерживают подгрузку внешних библиотек - java/python/php/С и тд). Но реализовываете вы ее на C++, соотвецтвенно у вас есть ф-ункции которые создают некоторые C++ объекты которые в дальнейшем будут использованы. Возникает вопрос как возвращать/принимать эти C++ объекты в рамках функций на C ? Можно конечно создать внутри библиотеки внутренюю таблицу таких объектов и возвращать индексы из этой таблицы - но это бывает не всегда эффективно, проще применить «слабое» привидение типов (void*) <-> (MyInternallClass*).

Точно такойже механизм применим и к библиотекам написаным на C но которые не хотят давать возможность работать со своими внутренними структурами на прямую (void*) <-> (MyInternallStruct*).

Если говорит о C то также очень часто слабое приведение типов применяется при работе с бинарными данными (получеными по сети или прочитаными с диска). Если структура бинарных данных зарание извесна то часто для нее создают описание по средствам «struct» и при получении/записи данных вместо десереализации/сереализаци используют слабое приведение типов (void*) <-> <struct DataStruct*>.

Еще наверное стоит отметить привидение классов/интерфейсов в C++. В C++ существует как сильное (dynamic_cast) так и слабое (reinterpret_cast) привидение объектов - хотя первое и является более безопасным - второе более производительно (точнее оно вообще не приводит к генерации какого либо исполняемого кода а просто меняет состояние компилятора).

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

как часто возникает такая необходимость?

зависит от кодера, по его желанию.

Хорошо, почему такой прототип будет сложнее писать на языке со строгой типизацией? Я не понимаю именно этого аспекта.

Если говорить именно о динамических, а не слаботипизированных языках, то просто потому что ты можешь поменять одну функцию и даже как-то запустить её и посмотреть на результат. Пофиг, что в целом всё развалится, зато рефакторить можно по частям. Сравни с каким-нибудь хаскелем, где поменял функцию и правь 100500 мест вызова. Поэтому там на этy тему cпециальныe костыли делают, потому что реально удобно.

P.S. Предпочитаю строгую статическую типизацию.

Вопрос поставлен не корректно. Слабая типизация это не плюс какого-то языка, это необходимый механизм для эфективной реализации некоторых технологий.

Ну я то как бы предполагал что вопрос лежит в плоскости оптимизации выполнения кода а не удобства для разработчика.

В тех трех примерах что я приводил первые два дают какраз и более высокую производительность, и упрощают процесс разработки. Трейтий в принципе влияет только на производительность и имеет смысл при оптимизации.

И да при оптимизации слабое приведение типов используется часто, также часто применяется для реализации какихто хитрых контейнеров (в рамках С/С++). А вот в JavaScript например часто применяют слабую типизацию для примевдения типов, в частности часто встречал приведение флоата к инту через слабое типезирование:

var myInt = (Some Float Var or expr) | 0;

var myString = '' + number;
var myNumber = (myString | 0);

проще применить «слабое» привидение типов (void*) <-> (MyInternallClass*).

Может я, конечно, не совсем правильно понимаю «слабую типизацию», но имхо, если привести можно, но только при помощи «дополнительных конструкций» языка, то она уже не слабая. Если говорить о С++, то void* сам ни к чему не приводится - надо явно намерение показать. В обратную сторону, правда, работает автоматически.

Говорю именно про этот пример, то что в С++ «местами» есть слабая типизация спорить не буду.

Я не претендую на звание знатока в этой области, поэтому могу высказать свое мнение по этому вопросу. Я опираюсь на следующее понятие слабой/сильной типизации (как наиболее понятное для меня):

Cистема типов называется «сильной», если она исключает возможность возникновения ошибки согласования типов времени выполнения.

Это конечно тоже не совсем то что у меня в голове но тем не мение, я сщитаю что то о чем пишете вы - это автоматическое приведение типов в С/С++ а уже само приведение типов может быть как сильным так и слабым. Например:

float int2float(int v) {
   return v;
}

void int2float(int v, void *floatRes) {
   *(reinterpret_cast<float*>) = v;
}

С «C» все немного запутано поскольку там нет синтаксического разделения приведения типов, а вот в С++ есть 2 слабых приведения типов: reinterpret + const. И 2 сильных dynamic + static.

Данная проблема мне видится както так (с точки зрения С/С++). По крайней мере автоматическое приведение типов есть и в Java (первый вариант int2float в ней допустим) - а это язык с сильной типизацией.

«Слабая типизация» - маркетинговый термин. Поделись с нами, что ты имеешь в виду под ней.

И в дополнении - получается что в С/С++ я могу использовать слабую типизацию но я должен это явно указывать специальными синтаксическими конструкциями (операторами приведения типов). Автоматическое же приведение типов в С/С++ (насколько я знаю) всегда сильное (по крайней мере будет варнинг на от компилятора) - что в принципе логично. А вот тотже самый PHP или JavaScript делает слабое приведение типов автоматически без уведомлений разработчика.

Поделись с нами, что ты имеешь в виду под ней.

Очевидно, то что написано в книжках/интернете. В общих чертах описывается статьёй на википедии.

Меня интересует твоё мнение.

Могу вики процитировать.

, я сщитаю что то о чем пишете вы - это автоматическое приведение типов в С/С++ а уже само приведение типов может быть как сильным так и слабым.

Да, был не прав. Впрочем, с практической точки зрения я нахожу это несколько бессмысленным. Ну да, «ошибки согласования типов» в С++ не будет, но от автоматического приведения проблем бывает не меньше, а то и больше. Да и можно подумать, что написав функцию, которая «алгоритмически строит значение требуемого типа на основе значения исходного типа» нельзя допустить лажу.

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

Implicit type conversions and «type punning»
Some programming languages make it easy to use a value of one type as if it were a value of another type. This is sometimes described as «weak typing».

И там ещё много оговорок, в том числе, про арифметику указателей и т.д.

Ну да, «ошибки согласования типов» в С++ не будет, но от автоматического приведения проблем бывает не меньше, а то и больше.

Ошибку можно допустить всегда и везде, вопрос в их минимизации и автоматизации обнаружения (ошибки и/или варнинги компилятора как наиболее распрастраненный инструмент проверки кода на наличии ошибок). Автоматизация же слабой типизации в реалиях C/C++ может повлеч весьма пагубные последствия, например допустим что компилятор будет сам подставлять слабое приведение типа, тогда код такого плана:

void int2float(int v, float *res) { *res = v;};

int main() {
  double d;
  int2float(10, &d);
}

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

Это какраз отражает то что у меня в голове (есще более точно чем цитата которую приводил я). И в рамках С++ преобразований reinterpret и/или const касты какраз позваляют использовать значение некоторой переменной как значение совсем другого типа (они не генерируют никакого кода конвертации, они просто указывают компилятору что вот эту переменню (читай блок памяти) типа TypeA в этом месте стоит интерпретировать как переменную типа TypeB. А вот static и dynamic касты генерируют код который делает реально преобразование типов с сохранением резултата в отдельной ячейке памяти (в явной или не явной/временной переменной).

Могу вики процитировать.

вику тайком по ночам могут редактировать мутаторы истории

Давай. (надеюсь, не русскую)

А мне вот интересно, насколько знание того, что означает "слабая типизация" помогает в погромировании. Я, например, набыдлокодил уже кучу велосипедов, совершенно никакого представления не имея о том, что же такое "сильная типизация" или "слабая типизация".