Компания Apple анонсировала (http://www.apple.com/live/2015-june-event/9d2ad033-d197-4009.../) скорое открытие наработок, связанных с языком программирования Swift. Кроме iOS и OS X инструментарий для разработки на языке Swift будет поставляться и для Linux. Других подробностей пока не сообщается.
Язык Swift наследует лучшие элементы языков C и Objective-C, и предоставляет объектную модель, совместимую с Objective-C (Swift-код может смешиваться с кодом на С и Objective-C), но отличается использованием средств автоматического распределения памяти и контроля переполнения переменных и массивов, что значительно увеличивает надёжность и безопасность кода. Для обеспечения высокой производительности Swift-программы компилируются в машинный код, выполняемый в 1.3 раза быстрее кода на Objective-C.
Реализация Swift построена с задействованием технологий свободного проекта LLVM. Вместо сборщика мусора Objective-C в Swift используются средства подсчёта ссылок на объекты, а также предоставляемые в LLVM оптимизации, такие как автовекторизация. Язык предлагает множество современных методов программирования, таких как замыкания, обобщенное программирование, лямбда-выражения, кортежи и словарные типы, быстрые операции над коллекциями, элементы функционального программирования.URL: http://www.apple.com/live/2015-june-event/9d2ad033-d197-4009.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=42389
почти что RUST только без поддержки windwows
> почти что RUSTв Swift есть семантика владения и одалживания?
или это ты просто написал наобум?
а ты, надо думать, написал все слова что знал о rust? для тугих: "почти что" не означает "соответствует 1:1".
> для тугих: "почти что" не означает "соответствует 1:1".а то что ни фига не похоже -- это случайно не обозначает? :-)
и вообще -- я просто спросил про Swift .. я же не знаю какое там оно..
просто напиши, друг, Аноним, -- есть ли там это (семантика владения и одалживания) в Swift или нет этого в Swift. не выпендривайся!
> а ты, надо думать, написал все слова что знал о rust?
да!
а теперь ты, друг, Аноним, можешь написать все слова которые ТЫ знаешь о Swift .. не стесняйся :-)
Аноним смотрит на тебя как на каку
Извините, я ничего не знаю ни про Swift, ни про Rust, но вот это вот:
> семантика владения и одалживаниячто это за зверь такой? Я поискал в Google сначала русское описание оного, потом английский аналог - как-то туманно.
Мне кажется, что это какое-то новое модное название guards, но я не уверен. Подскажете точное описание сабжа? Можно со ссылкой на Swift, я не против просто поглядеть на этот язык, особенно на сильные стороны.
> почти что RUST только без поддержки windwowsОсновные значения слова "rust" - "разложение", "гниение", "коррупция", "коррозия", "ржавчина". В лучшем случае - "окисление".
Кто-нибудь знает, почему язык Rust назвали именно так?
Да, еще есть какое-то значение из области керамики.
Это как с "fiasco". Оказывается это вовсе не "пипец", а такая особая бутылка для вина.К Свифту вроде таких претензий нет.
>то-нибудь знает, почему язык Rust назвали именно так?Руководителем проекта была Ванга...
в честь грибка https://www.reddit.com/r/rust/comments/27jvdt/internet_archa.../
Вот когда переведут, тогда пусть и объявят, а обещаний нам, анонимусам, не надо — мы и сами кому угодно что угодно пообещать можем.
Адепт Клоуна?
Может это будет получше чем rust и go?
Go и так очень неплох в своей нише, а вот Rust может о рипнуться.
Толстовато, батенька. Худеть вам надо.
>> Go и так очень неплох в своей нишеИ это правда. Язык состоялся и движение многих серьезных веб-проектов на него это уже данность.
ЗЫ
Как ни парадоксально, но GO может сильно потеснить PHP. Возможно, что будущее мейнстрима будет за связкой Swift-GO или Rust-GO вместо C/C++-JAVA/PHP
Смешались в кучу все... кони, люди.
Алё! Прикладное программирование от системного отличаем, да?Зыж
Вот пусть го и теснит пыхпых и иже с ними.
Тут, в этой нише, плюс/минус 100500 языков (уже!) не играет значения.
Это будет получше, чем язык Васик для компьютера Ириша.
Тем, что хотя бы одну современную ОС оно поддерживает.
Правда, на этом достоинства заканчиваются, потому что достоинства, ограниченные одной операционкой, за ее пределами никому не уперлись.
Плюс подсчёт ссылок - техника несколько спорная для многопоточного софта блокировками. А в свифте отнюдь не акторы с сообщениями.
> Плюс подсчёт ссылок - техника несколько спорная для многопоточного софта блокировками.подсчёт ссылок -- это скорее не техника, а ОТСУТСТВИЕ техники :-) ..
точнее говоря -- отсутствие сборщика мусора.
Это одна из техник управления памятью. На сборке мусора свет клином не сошёлся. Но у каждой техники свои границы применимости.
> На сборке мусора свет клином не сошёлсяэто -- да.
> Это одна из техник управления памятью. На сборке мусора свет клином не
> сошёлся. Но у каждой техники свои границы применимости.что самое смешное — RC/ARC как раз и есть сборщик мусора. тупице‐оппоненту это можно не знать, но тебе‐то?
Можно подумать, сборщик мусора полезен для многопоточного софта.
Сборщик мусора для многопоточного софта работает не хуже (а часто и лучше, если достаточно хитрый), чем для однопоточного. При этом если памяти хватает он может запускаться довольно редко, или не запускаться вообще. А вот для подсчёта ссылок в многопоточном варианте приходится локи брать для всех шареных объектов, что производительности ни разу не на пользу.
> Сборщик мусора для многопоточного софта работает не хуже (а часто и лучше, если достаточно хитрый), чем для однопоточного.Питон, GIL, ты гонишь.
Расшифруй. Если что - напомнинаю: в питоне подсчёт ссылок и именно за счёт GIL нет нужды использовать для этого локи или атомики.
> Сборщик мусора...ставит раком все треды.
>> Сборщик мусора...
> ставит раком все треды.это только в двух случаях:
1. писан жопой.
2. программа подвязана на glibc и её аллокатор.к сожалению, пункт 2 ставит жирный крест на нормальных gc для языков, активно взаимодействующих с сишными библиотеками. потому что увы, но периодически наступаешь на дедлок в аллокаторе glibc — и всё.
> А вот для подсчёта ссылок в многопоточном варианте приходится локи брать для всех шареных объектовДа неужели?
Мусье вообще слабо поинимает о чм говорит. Параллельные GC в JVM при major collection вообще делают stop the world, что бы разобраться с графом объектов.
> Может это будет получше чем rust и go?Больше похоже на огрызок (ага) того или другого, накачанный синтаксическим сахаром.
Ну это если рассматривать его в контексте их задач.
Для написания приложений под айпады и osx он вполне даже хорош, все так.
так и есть, смотри:«However, the overflow versions of these operators (&/ and &%) return a value of zero if you divide by zero:
let x = 1
let y = x &/ 0
// y is equal to 0»Отрывок из книги: Apple Inc. «The Swift Programming Language». iBooks. https://itun.es/ru/jEUH0.l
И какова практическая применимость этого?
А тебе не надоедает при каждом делении писать?res = ?(y=0, 0, x/y);
Вместо куда более логичного
res = x &/ y;
То, что математическая операция вызывает прерывание выполнения программы - это архитектурная проблема многих ЯП. Слава Путину что хоть переполнение или потеря точности при операция с плавающей точкой проходят всегда, а не выдают exception "выполнение программы прекращено с ошибкой: потеря точности при умножении"
Не надоедает, потому что я так в жизни не писал. Я вообще смысла этого действа не понимаю, и где его применить - тоже, ни в первом, ни во втором варианте. Это банальное нарушение правил операции деления. Зачем мне там нуль, если он не несёт никакого смысла?Для всех практических нужд нуль в знаменателе - признак того, что у нас на входе неверные (непроверенные или не исправленные) данные - то есть классическая причина бросить исключение. Тем более это верно в отношении приведённого примера из книги, где о float - ни слова. А уж целочисленное деление на нуль - вообще за гранью добра и зла.
> Для всех практических нужд нуль в знаменателе - признак того, что у нас на входе неверные данныеТ.е. вы программным исключением проверяете данные на правильность? Вас чем-то обидели условия или вы дали обет прогить 10 лет не написав ни одного "если-то"?
Мда... Всё хуже, чем я думал...
С абстрактным мышлением у вас тоже всё плохо, поэтому попробую объяснить на пальцах.
int res = MAX_INT + MAX_INT;
приведёт к ошибке переполнения, которая будет автоматически обработана и вы об этом даже не узнаете. В асме был бы установлен флаг переполнения, но Си его игнорирует.
Умножение чисел со знаком приводят к ошибкам сопроцессора и переполнениям, которые язык Си игнорирует.
int res = MAX_INT / 0;
int res = 0 / 0;тоже приводит к ошибке, но эта ошибка вызывает в Си прерывание выполнения программы.
Все перечисленные выше ошибки являются ошибками неверных данных для выполнения операции. И на все, в общем случае, нужно было писать "если-то".
Исторически сложилось, что именно деление на 0 вызывает прерывание выполнения, но это не делает её более или менее уникальной, чем любая другая ошибка, связанная с неверными данными.
Правильным (единообразным с другими обработчиками ошибок) поведением было бы считать нулевым результат от деления на 0, что и было реализовано в ЯП Swift.
Ок, объясняю для клоунов.В зависимости от алгоритмики деление на нуль и рпочие переполнения могут быть проблемой логики или исходных данных. В первом случае в код пихаются assert, enforce и подобные конструкции, которые прерывают выполнение некорректной программы. Во втором случае, в зависимости от вероятности возникновения ошибки, можно проверять явно или положиться на исключения - код получается менее загромождён проверками. Ко float всё это, кстати, слабо относится - там вы получите inf, что абсоютно разумно и специфицировано стандартом.
Дальше. Да, в ваших примерах будет переполнение. Именно поэтому более современные языки имеют разнообразные средства для борьбы с этим - от BIGINT до специализированных цисловых классов. Чего вы привязались к Си, который очень беден во многих областях, когда мы говорим о Swift, скорее сравнимом с Go, Rust, C++ или D - я понятия не имею.
И, кстати, в C integer Overflow и division by zero абсолютно консистентны - и то и другое - undefined behavior. В плане реализации креш в подобных ситуациях куда лучше, чем продолжение работы с бессмысленными данными.
Разумеется, было бы лучше, если бы любыу переполнения отлавливались. Но на практике сложение/вычитание (и в меньшей мере умножение) быстры и часто используются, и проверка для каждого из них сильно влияла бы на быстродействие. Поэтому для желающих в том же GCC/Clang есть соответствующие intrinsics - и всё. Плюс на уровне ассемблера сложение/вычитание с переполнением - вполне осмысленные операции, на которых реализуется тот же BIGINT. Деление же используется редко, довольно дорого и вызывает легко отлавливаемое аппаратное прерывание.
Но никто и никогда не выставлял результат операции с переполнением в нуль по причине полной бессмылсенности.
> В зависимости от алгоритмики деление на нуль и рпочие переполнения могут быть проблемой логики или исходных данных.Я видел много логики, где если делитель равен нулю, то и результирующее значение должно быть равно нулю.
Вот, например, пример нормирования:
int Сумма = 0;
foreach(Значение; МассивЗначений) {
Сумма += Значение;
}foreach(ref Значение; МассивЗначений) {
Значение /= Сумма;
}А если "Сумма" будет равна 0, то и "Значение" должно равнятся 0, но такого не будет, т.к. вылезет исключение и поэтому приходится писать условие:
Сумма = Сумма==0 ? 1 : Сумма;
Или:
Значение = Сумма==0 ? 0 : Значение / Сумма;
Если же в данном примере, заместо типа int использовать тип float, то после деления на 0 получится nan, а по логике работы алгоритма должно быть 0, поэтому данный оператор и тут выручит и избавит от сравнения, засоряющего код.
И таких ситуаций я встречал полно в программировании, именно поэтому данный оператор полезен, потому что лень каждый раз писать аналогичные условия и плюс код ещё загромождается. Я с аналогичным кодом сталкивался больше, чем вы можете себе представить и разработчики данного языка, видимо, не спроста придумали эту конструкцию, наверно их тоже достало писать эти условия.
И заметьте, что оператор "&/" -- это не оператор деления, а оператор деления и сравнения, поэтому, где логика другая, там можно пользоваться обычным делением.
Но думаю, что данный оператор нельзя назвать преимуществом языка Swift, т.к. аналогичная конструкция вроде свободна во всех самых популярных языках(из тех, которые я знаю), поэтому она мигрирует потом из данного языка и в остальные, если язык станет популярным, ну или если идея дойдёт до разработчиков остальных языков.
> Я видел много логики, где если делитель равен нулю, то и результирующее
> значение должно быть равно нулю.Но не неявно же. Это очень специфический случай. То, что ты ниже критикуешь, как раз правильно -- ибо явно.
> И заметьте, что оператор "&/" -- это не оператор деления, а оператор
> деления и сравнения, поэтому, где логика другая, там можно пользоваться обычным
> делением.Это бред. Твои личные фантазии на тему этого оператора. В доках он называется overflow division, это оператор деления.
> Но думаю, что данный оператор нельзя назвать преимуществом языка Swift, т.к. аналогичная
> конструкция вроде свободна во всех самых популярных языках(из тех, которые я
> знаю), поэтому она мигрирует потом из данного языка и в остальные,
> если язык станет популярным, ну или если идея дойдёт до разработчиков
> остальных языков.Да ты самый умный у мамки, ага. До тебя быстрее всех все доходит.
Она уже мигрировала -- на помоечку, они сами это убрали (см. ниже ссылку на старую версию книжки). Видимо, до них-таки дошло.
> Но не неявно же. Это очень специфический случай. То, что ты ниже критикуешь, как раз правильно -- ибо явно.Я привёл пример, который первый пришёл в голову, и в котором от деления можно вообще избавится, но я видел много другого кода, где от деления избавится было нельзя и точно также приходилось использовать условие для приравнивания нуля.
> Это бред. Твои личные фантазии на тему этого оператора. В доках он называется overflow division, это оператор деления.
Ты не знаешь о моих фантазиях и без разницы, как он называется в доках, я говорил лишь об его машинной реализации. Как по-твоему данный код преобразуется в машинные инструкции ?
Если там операция целочисленного деления, не вызывающая исключения ? Или можно разделить плавающую точку на 0, без генерации nan значения ?
Вряд-ли.
Скорее всего компилятор там вставит условие сам, поэтому и получится деление с условием.> Да ты самый умный у мамки, ага. До тебя быстрее всех все доходит.
Она уже мигрировала -- на помоечку, они сами это убрали (см. ниже ссылку на старую версию книжки). Видимо, до них-таки дошло.
А ты по-нормальному без оскорблений комментировать не можешь ?
Я вообще о данном языке не знаю ничего и о соответствующем операторе узнал из комментариев выше. Мне всё-равно убрали они его или оставили. Но если бы данный оператор прижился, его бы подхватили и все другие.
Я лишь подметил, что при наличии данного оператора, он не добавляет каких-то суперпреимуществ языку и аналогичный оператор легко реализовать в любом другом языке.
Ну хорошо, попробуем в этот раз без оскорблений. Может быть, так получится.(Напоминаю, что ты заявил, что &/ -- не деление.)
"Без разницы, как он называется в доках", "как по-твоему", "вряд-ли", "скорее всего", "я о данном языке не знаю ничего", "если бы"...
Твои догадки по поводу того, как реализуется в машинном или llvm-коде тот или иной оператор, и чем руководствовались разработчики, когда это вводили в язык -- это лишь твои догадки, фантазии, не имеющие к действительности никакого отношения, даже если там действительно похожим образом все устроено. Ты не понимаешь, что спецификация и реализация - это разные вещи, и если даже в компиляторе &/ был реализован через условие+деление, это не дает тебе права называть его условным делением, если он так не назван в _спецификации_ языка. Обычно в этом месте следует контраргумент наподобие "Ну а как еще его реализовать?" Да так, что никто не запретил бы разработчикам взять и компилировать позже, в новой версии компилятора, этот оператор как-нибудь по-другому (например, через ненавистное вам исключение) - то, что что они гарантируют, написано в спецификации, и там он называется overflow division, или "деление с переполнением". Это деление. Точка.
Но результатом деления на ноль является совсем даже не ноль, поэтому по факту это не оператор деления, он не оправдывает своего названия -- поэтому я посмеялся над ним. Ты тоже, видимо, в курсе, что деление так себя не ведет -- но ты решил вместо того, чтобы признать наличие ошибки, просто так взять и переименовать этот оператор (здесь можно увидеть забавную аналогию с самими операторами / и &/). Нельзя просто так взять и переименовать оператор, который уже имеет официальное название.
Непонимание таких вещей выдает твой низкий уровень инженерной культуры. Ты либо тролль (вроде не похоже), либо, так скажем, еще совсем юн.
Короче говоря, если у тебя возникнет желание ответить мне, выдумав новый пучок фактов о незнакомом языке, и попутно привести аналогии из истории Древнего Мира, кельтских мифов, и того, что ты в книге дракона вычитал (хоть в курсе, что это не фэнтези-роман?) -- не стоит. Прочти то, что я уже писал тебе - я повторять по сто раз не буду. Есть замечания по существу предмета - пиши.
Без крепкого словца скучно читать. Если человек болван, то констатировать по факту что он болван - это совсем не оскорбление. В вашем ответе напрашивает диагноз, но вы виляете как собака хвостом, поэтому о вас можно подумать что вы толерантный идараст. Говорите как есть, не стесняйтесь и глядишь под напором наступят времена когда очередной писатель подумает лишний раз прежде чем соберется вывалить свой бред в интернеты.
Не путайте конструктивную критику и толерастию, это совершенно противоположные вещи.
Бороться руганью и демагогией с сетевыми неадекватами бессмысленно, они нам сами фору дадут по этой части.
"Ирония и жалость, ребята! Ирония и жалость!"
Выше я просто пример привёл, но в реальности в том примере будет использоваться тип с плавающей точкой и лучше деление заменить умножением, если код это позволяет(иногда такое нельзя провернуть из-за ошибок округления).
> int res = MAX_INT / 0;
> int res = 0 / 0;
> тоже приводит к ошибке, но эта ошибка вызывает в Си прерывание выполнения
> программы.В Си это undefined behaviour, и в стандарте нигде не написано, что программа должна прерываться. Иными словами, гипотетический Klovan C compiler, у которого деление на ноль равняется нулю, полностью соответствует стандарту языка.
Хуже невежества бывает только воинствующее невежество. Вместо того, чтобы предметно разобраться в вопросе "почему сделано именно так, а не как моему больному рассудку кажется логичным и правильным?", ты тут развел абсолютно бессмысленный флуд. Марш читать умные книжки по архитектуре и организации ЭВМ!
>>В Си это undefined behaviourИ это, кстати, *запрещает вообще* делить на ноль в си и си++.
Хотя клованский компилятор стандарту соответствует, программа, которая на результат деления в таком компиляторе опирается, стандарту соответствовать не будет. Это будет клованская программа для клованского компилятора.Оператор &/ может применяться вместо "/" такими, как клоун, из-за лени, а не ради того самого внезапного нуля при переполнении. И в этом вся проблема.
Кстати, Аномсис, клоун, если вы так влюблены в этот оператор -- никто, кроме здравого смысла, не запрещает вам написать свой взамен усопшему, Swift это позволяет.
> И это, кстати, *запрещает вообще* делить на ноль в си и си++.Запрещать-то никто не запрещает, просто это будет программа, полагающаяся на конкретный компилятор, что плохо практически всегда. Результат "++i + ++i", например, тоже undefined, но от этого программа с такой строчкой не прекращает быть программой на С.
>программа ... стандарту соответствовать не будет
Будет. Она гарантированно скомпилируется и запустится любым сишным компилятором. Но вот как она себя будет вести - совершенно непонятно. Поэтому...
> Это будет клованская программа для клованского компилятора.
Это точно. Хорошей ее назвать язык не повернется ни у одного специалиста, разумеется.
Да, вы правы, я неточно выразился. Я имел в виду, что стандарт явно определяет ее поведение неопределенным (undefined behavior), а не зависящим от реализации (implementation-defined).
> А тебе не надоедает при каждом делении писать?
> res = ?(y=0, 0, x/y);А с какого перепуга результат при долении на ноль равен нулю?
Лучше 0, чем прерывание выполнения и завершение программы.Даже так: лучше что-угодно, чем прерывание выполнения и завершение программы.
А почему не 10? 100? 1000?
Что за дискриминация?
зыж
Лучше руки сразу отбивать, чем давать писать вот такой код, который мало того что маскируется под валидный, так ещё и мешает при отладке.
Ззыж
А если ноль — не единственное ограничение (а так оно и есть, про переполнение не слышали?), тогда как? Какой ещё костыль придумаете? Просто интересно
Предлагаю 666.
Как намек всем, кто не проверяет деление на ноль, что они будут гореть в аду.
> Лучше 0, чем прерывание выполнения и завершение программы.
> Даже так: лучше что-угодно, чем прерывание выполнения и завершение программы.Чушь. Неверно работающую программу лучше всего прибить как можно скорее, пока она не натворила бед. Во всех нормальных языках - от C до Java исповедуется такая логика (где-то падает, где-то исключения). И только в недоязыках грабли заботливо прячут. Видимо, чтобы били больнее.
"Правильность" - это соответствие ТЗ. Если юзер хочет, чтобы 2+2=5, то 2+2=5 - правильно, а 2+2=4 - ошибка.Не зная задачи и ТЗ утверждать что лучше прибить... Смело.
Ок.
А если юзер хочет, чтобы деление на ноль равнялось пи до 10 знака включительно, то какой оператор?
Ну все, сдулся клован. Понял, что на одном дилетантстве техническую дискуссию вести нельзя, начал теперь про "соответствие ТЗ" задвигать.
Но и тут ты не обошелся без формулировок "если бы у бабушки был...". Учись говорить по существу. Какова доля ТЗ, в которых прописывается, что в исключительной ситуации деления на ноль программа должна продолжать работать, приняв результат деления за ноль?
Воспроизведение видео и звука, контроль скорости и температуры, сбор данных, обработка записей в БД и многие другие - лучше пусть они запорят одну итерацию, чем перестанут работать вообще. Если они будут запарывать все подряд - это сразу выявится и клоун за клавиатурой примет решение.Вы не работаете с БД объёмом в миллионы записей для которых десятки регламентных заданий постоянно что-то делают? Принимают заказы, рассчитывают доставки, находят габариты, рассчитывают объёмы. Распределённые базы и обмены гоняют данные, которые могут доезжать неполными и их нужно восполнять.
И если ты ещё не заколебался писать условия и проверки, то мне бы хотелось по максимуму от них отвязаться.
если не ноль, то делить
если не пустой файл, то парсировать
если возвращён не пустой массив, то обрабатыватьВ результате весь код через ж--у.
do
{
mas = parse_data();
if(!mas)break;
doit(mas);
}while(1);или прямая версия, но с повтором кода
mas = parse_data();
while(mas)
{
doit(mas);
mas = parse_data();
};И то, и другое отработает. Но если ты не видишь, что обе конструкции кривые - я с тобой в один цирк не пойду.
> Вы не работаете с БД объёмом в миллионы записей для которых десятк....А вы типа работаете?
Любая серьезная б/д имеет даже для булевых выражений три значения — тру, фалс и нул. При чём нул != нул.
Поэтому не надо пиСдеть.
>Воспроизведение видео и звука, контроль скорости и температуры, сбор данных, обработка
>записей в БД и многие другие - лучше пусть они запорят одну итерацию, чем перестанут
>работать вообще.Это не ответ на вопрос.
>Распределённые базы и обмены гоняют данные, которые могут доезжать неполными и их нужно восполнять.
Компилятор принципиально не может знать, чем, как и когда эти данные нужно восполнять. Не существует универсального рецепта для всех. По крайней мере, принятие за ноль результата деления на ноль - это даже близко не универсальное решение.
Прямая синтаксическая конструкция есть в 1С:Массив = parse_data();
для каждого Элемент из Массив цикл
doit(Элемент);
конеццикла;Вот это правильно: мы тупо перебираем возвращённый массив (список, таблицу, таблицу таблиц, таблицу списков таблиц) данных и не паримся пустой он или нет. Проверки вставит компилятор (в данном случае интерпритатор).
Угу, и вот doit и проверяет (там у себя) чё ему надо. Атомарность, мля.
А не как у тебя.Проверки вне блока только логические, вернее бизнес-логические (например расчет налогов (по закону например) до М — doit, больше М — doit1. Но проверка на 0 (очевидно она до М) внутри doit. При чём в обоих дуитах!!! Потому как мало ли идиотов этим АПИ воспользуются. Налоги изменятся и привет вечерняя смена)
Это азбука.
>Массив = parse_data();
>для каждого Элемент из Массив цикл
>doit(Элемент);
>конеццикла;Клован, у тебя же одно с другим не вяжется. Постом раньше parse_data у тебя в цикле вызывался, теперь - до цикла, один раз. WTF? Ты всех за идиотов держишь, или сам настолько дурак, что даже корректный пример высосать из пальца не можешь?
С делением на ноль аналогично: меньше проверок - и жизнь станет приятнее.Я понимаю, что я тебе сейчас на яйца наступаю. И когда пройдёт возмущение, если не противиться, ты сможешь почувствовать что это удобно и приятно.
А проверку ты можешь написать независимо от того: будет исключение или не будет.
Вау! сколько бреда ты выкатил... И где деление на 0?И самое главное!!!
Где доказательство того, что если твой doit(mas) выдаст 0, то тебе бухгалтерия не надает по шапке? У?Ну например (вы там с лимонными таблицами работаете? Вах! Правда что ли?) — а поставим ка ценник за кило по среднезакупочной (можно по партии).
Ну да, закупку тонны сторнировали, но 0 ведь не ошибка нифига, правда?А пока разраба ловят, купим всем коллективом вскладчину, 0 на десяток точно уж делится.. и не дорого.
Вы все всё дальше уходите от синтаксиса ЯП в дебри собственного бреда.
Придурок, это математика.
Никакой синтаксис её не отменит.
ТЗ к математическим правилам и правилам языка не имеет абсолютно никакого отношения.
(Разъясняю особо одаренным)
Ладно Infinity, ладно NaN какой-нибудь, но какого хера при делении на ноль получается НОЛЬ?! Вы этого вообще не заметили?"Так и есть, смотри" было, разумеется, сарказмом.
Сегодня обнаружил, что и сами Apple уже этот бред убрали, нет больше такого оператора. Если кто думает, что это просто троллинг и его никогда не было: https://books.google.ru/books?id=EAgcCQAAQBAJ&pg=PA273&lpg=P...
>Сегодня обнаружил, что и сами Apple уже этот бред убрали, нет больше такого оператораПосмотрел бы я на лицо клована сейчас. А ведь как защищал, как защищал он своих хозяев на форуме от людей, имеющих начальное образование!..
У меня вообще ощущение, что аппле осознанно стебется над своими клоунами в последнее время. (У самого тоже мак есть - но исключительно ради разработки на том же свифте, а не для повседневного использования)
Что это меняет?Знаешь, на парусных кораблях был не штурвал, а румпель и чтобы повернуть вправо его нужно было поворачивать влево и наоборот. Потом появился штурвал и рулевой на команду капитана "право руля!" отвечал "есть, лево руля!".
В России это отменили только в начале 19-ого века, когда утопили 2 корабля.
Сколько раз программа должна вылететь в самом неподходящем месте (АЭС, спутники, ..) чтобы дошло простая истина: прерывание выполнения из-за параметров арифметической операции недопустимо.
точно, пусть у нас программа продолжит работу, неверно что-то рассчитав, и начислит тебе нулевую зарплату, или взорвет что-нибудь там к х*ям :3или мы будем об этом нуле при нуле таки помнить, клоун?
Представил расчет относительных запуску координат.
Улыбнуло.
Зыж
С другой стороны — айфон с боеголовкой — уже анекдот.
По его навигации некоторые машины водят.
Я кажется догадываюсь как в этом году одна бабуля в ON умудрилась на встречку на хайвее(!!!) выехать! :)
> Что это меняет?Это меняет всё.
> Сколько раз программа должна вылететь в самом неподходящем месте (АЭС, спутники, ..)
> чтобы дошло простая истина: прерывание выполнения из-за параметров арифметической
> операции недопустимо.Господи какой идиот! Эталонный - хоть в палату мер и весов.
PS: Пройди школу снова, начиная с младших классов. Ну там яблочки на уроке подели, может через следующие 10 лет дойдёт.
Проблема, о котором нужно постоянно помнить, рано или поздно приведёт к катастрофе.
> Проблема, о котором нужно постоянно помнить, рано или поздно приведёт к катастрофе.Ты на вопрос не ответил.
> Ладно Infinity, ладно NaN какой-нибудь, но какого хера при делении на ноль получается НОЛЬ?! Вы этого вообще не заметили?А кто тебе сказал, что при делении на 0 получается НОЛЬ ?
Раздели в этом языке, что-нибудь на ноль и тебе выдаст исключение.
Обсуждаемый же оператор -- это не простое деление.
Для простого деления по всем правилам математики есть соответствующий оператор "/".А вот это "&/" означает, что в случае деления на 0 приравнять к переменной 0, а в остальных случаях делить как обычно.
Как описали выше -- эта конструкция("&/") заменяет выражение "Делитель==0 ? 0 : Значение/Делитель".Или по-твоему противозаконно к переменной приравнивать ноль в таких случаях ?
Надо обязательно приравнивать nan ?Это не математика, а программирование и переменные тут многофункциональны.
И ещё -- разве в математике операция деления обозначается таким символом "&/" ?
>Обсуждаемый же оператор -- это не простое деление.Клован, например, утверждает, что это и есть единственно правильный оператор деления, ПАТАМУШТА ОН НЕ КИДАЕТ ИСКЛЮЧЕНИЙ ПРИ НОЛЕ.
Молодец клоун. Я с ним полностью согласен. Побольше бы таких людей.
> Молодец клоун. Я с ним полностью согласен. Побольше бы таких людей.Молодец, конечно, только перелогиниться забыл.
Сам себя не похвалишь - никто не похвалит.Клоун - это не логин.
Клоуном может быть любой. Я все и я никто. Я везде и меня нигде нет. Однажды один из пользователей уже осознал, что это он "клоун Стаканчик" и зарегился под этим логином. Может, вы станете следующим кто поймёт что он клоун, видящий в моих словах отражение своих мыслей?
> Молодец клоун. Я с ним полностью согласен. Побольше бы таких людей.Ну а дрюкни сам себя, да и размножься ... Видео на прон.ру выложить не забудь! :)))
А *BSD в пролёте?
надеюсь
>А *BSD в пролёте?Да, на пятом этаже :)
Код открыт, значит могут портировать.
> >А *BSD в пролёте?
> Да, на пятом этаже :)
> Код открыт, значит могут портировать.Если прибор есть - значит мог изнасиловать!
Ты вначале объясни для чего сей езыГ так уж нужен хотябы в линуксе :)
кабы не windnows с их открываниями, - купертиновцы даже не почесались бы
Да ладно вам. Сейчас сложно выйти на рынок с ЯП, а если он ещё будет и закрытый -- совсем тяжело. У них есть один рычаг: это по умолчанию используется в iOS, но такие методы могут плохо закончится. Вполне логичный шаг.
Простите, а что меняет эта открытость этого языка?
Неужели наконец можно будет запустить самостоятельно написанное на нем приложение на собственном Айпаде без ежегодной проплаты лицензии разработчика Apple?Позволю себе пророчество: да вот хрен-то!
Открытость позволяет познакомиться с языком без покупки яблокомпьютера.
Ну и бесплатная рабочая сила, куда ж без этого.
А на кой хрен с ним знакомиться без яблокомпьютера? Чтобы выпустить приложеньице, он, внезапно, все равно понадобится!
Я вот, познакомившись с этой "экосистемой", предпочитаю С++ с прослойкой из ObjC в случае необходимости. По крайней мере, остальной мой код может быть использован вне зависимости от их капризов.
Затем, что под линукс тоже можно будет приложения писать (это следует из новости, не?). Если это игра, например, то движок вполне может быть и кроссплатформенным. И как по мне, Xcode довольго убог в плане работы с кодом.
Но это неважно, на самом деле. Мне кажется, главное - это пиар и привлечение бесплатных разработчиков.
"Вполне может быть" что угодно.В данном случае открытие ничего не меняет. И бурные несмолкающие апплодисменты говорят лишь о том, что большинство этого не понимает.
Есть такой психологический тест: нужно называть масти карт, которые вам показывают. Показывать будут только червы и пики. Показывают всё быстрее. И человек начинает называть их исходя из цвета, а не из формы.
Радость по формальным признакам - это проще, чем критическое мышление.
> под линукс тоже можно будет приложения писать (это следует из новости, не?).Таки не. Ничего подобного в новости не написано. Надо думать, потому, что ничего подобного Ябло и не обещало. Кроссплатформенный XCode? Да щас, мечтатели...
Во что, по-твоему, будет компилироваться свифт под линуксом, если не в приложения под Линукс (или библиотеки, которые смогут задействовать такие приложения)? В приложения для айпада? Ну тогда-то уж точно он нужен там.У тебя с логикой проблемы? где я написал про кроссплатформенный Xcode?
Я имел в виду, что неплохо было бы иметь возможность кодить в другой, более продвинутой IDE, чем Xcode, и открытость языка этому очень способствует, именно потому, что под линукс нет никакого Xcode.
Боюсь, проблемы с логикой у вас. Вы себе придумали, что на Свифте можно будет писать Линукс-приложения и горячо это отстаиваете. А где Эппл что-нибудь такое написал?
Да нет, у вас! Про портирование Xcode под линукс я действительно ничего не писал, это уже вы себе придумали. К приложениям мой упрек не относился. Что же касается моей "радости" по поводу этой гипотетической возможности -- перечитайте мой пост, там из текста явно следует, что я рассматриваю Swift в первую очередь как язык для разработки iOS-приложений, а будущую линукс-версию -- лишь как еще один (очень продвинутый) playground. Так что мне все равно, и тут вы не угадали.Еще раз, чтобы прояснить: для меня Swift - это, в первую очередь, хороший (да!) язык для разработки коммерческих приложений, под iOS или Linux, открытых или нет -- неважно, главное, что коммерческих. Я не считаю Xcode идеальной средой разработки (и OS X -- самой удобной ОС) и хотел бы, чтобы появилась возможность работать со Swift в альтернативных средах (причем желательно в контексте именно iOS-разработки), чему открытость Swift может поспособствовать. Надеюсь, теперь вам все понятно.
Ну, так приподнимитесь выше по треду - я там как раз говорил, что для коммерческих приложений, и под iOS, и под другие ОС, я предпочту сам и посоветую другим язык, не завязанный на яблочные капризы.
Раз уж вы говорите о коммерческой разработке, думаю, вам не требуется объяснять достоинства реально кроссплатформенного кода и недостатки кода, замкнутого на одну систему.Мне для портирования под iOS практически не требуется париться с XCode - только прописывание ресурсов, обвязка в ObjC для корректного запуска, компиляция и выкладка в магазин... Зачем мне связываться со Swift? Чтобы с меня могли, если вдруг захочется, начать драть еще один яблочный налог? Да пошли они в пень, я на С++ и сейчас, без их подачек, могу писать там, где захочу, и так, как захочу.
Согласен.С другой стороны, вот Qt меня как-то разочаровала, пробовал ее под андроид - девайсы греются на ровном месте, внятной работы на ретина-дисплеях я так и не добился (в первую очередь, чтобы мне удобно было разрабатывать; и не у меня одного такие проблемы, судя по форумам). Я предполагаю, что все же сам неправильно что-то делал, но решил отложить ее пока. Есть желание попробовать PhoneGap и подобное, но верстать не умею.
Еще существуют работодатели, которым требуются знания именно Swift -- это я тоже учитываю (я вижу, что Swift набирает популярность).
То есть тяжело?
Этот язык они создали строго для себя и собственных нужд и им параллельно как у него там будут идти дела на рынке с ЯП. До появления iOS Objective-C был не шибко популярен, но как только стало ясно что на iOS можно очень хорошо заработать,так армия хомячков резко начала писать на нем свои поделия. Та же ситуация будет и со свифтом. Если разработка на нем будет приносить деньги, то абсолютному большинству разрабов будет плевать, открыт он или нет.
Sad but true..., ибо опен сурс это конечно круто и вообще добро, но зарабатывать тоже надо.
objective-c был открыт точно такжеopenstepу это помогло? нет.
точно также и тут - язык без гуи вокруг (а его точно в linux не будет) - не нужен в современном мире. на чём попрограммировать - найдётся.
козе решили подарить баян?
Очередной супер ультра крутой язык, наконец то
Очень любопытно будет увидеть, каким боком они собираются реализовать отладку osx приложений под линуксом.
Под линукс оно будет делать линукс приложения. Ваш капитан.
> Под линукс оно будет делать линукс приложения. Ваш капитан.Ух ты, новый супергерой!
Капитан Наивность!
>> Под линукс оно будет делать линукс приложения. Ваш капитан.
> Ух ты, новый супергерой! Капитан Наивность!Сколько эмоций капитан Тупость, сколько эмоций .... :)
На выходе оно даст:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x9a07906163461e75e58bafd507d587daad819322Рассказать тебе как это дебажить?
PS: А если кто то хочет делать апы под тыблоки - купит мак. Библиотек вокруг - не обещали. :) Так что нужно оно под юниками ... ну только чтоб было ....
Лучше расскажите мне, откуда вы взяли, что оно даст это на выходе.
Мне эмоции и тупость мешают понять, откуда оно здесь взялось.
> Лучше расскажите мне, откуда вы взяли, что оно даст это на выходе.Чтение документации торжественным голосом - 20$/мин.
> Мне эмоции и тупость мешают понять, откуда оно здесь взялось.Так вам не ко мне, а к проктоло^W к дохтуру.
> Чтение документации торжественным голосом - 20$/мин.Что-то дешево за чтение документации по тому, что Эппл только еще обещала.
Предикторы - очень важные специалисты в современном обществе, жаль только, что они куда меньше востребованы, чем им хотелось бы.
> Компания Apple анонсировала скорое открытие [...]Молния! Срочное известие!!! Эппл опять что-то пообещала! Покупайте газету! Срочное известие!
P.S.: Где новость-то?
Не тот ли это Swift, который западные страны хотят запретить в России?
Увы не тот, но его тоже могут запретить :)
...или "импортозаместить" местным 1С :)))))
В iBooks уже книжки по Swift 2 есть
Администратор iBooks, зайдите под своим именем, пожалуйста.
очередной пропиетарщик огласил концепцию подготовительных работ по разработке плана открытия под непонятной лицензией непонятного продукта сомнительной необходимости. маркетоиды привычно брузжут слюной доказывая нам, как нам всем остро необходим этот гoвн^W высер пропиерастов.
без удобной GUI библиотеки будет еще один не нужный новомодный ЯП
>Вместо сборщика мусора ... используются средства подсчёта ссылок на объектыВот так и в жизни - вместо того, чтобы убрать мусор, все предпочитают его "посчитать", потыкать в него пальцами и ничего не делать
З.Ы. подсчёт ссылок бесполезен для объектов с циклическими ссылками
Как насчет гибридного сборщика на основе нейросети?
> Как насчет гибридного сборщика на основе нейросети?Хорошо. Правда 95% времени исполнения твоей программы она в этом сборщике и проведёт :)
> З.Ы. подсчёт ссылок бесполезен для объектов с циклическими ссылкамиТаким объектам без должного присмотра уже никто не поможет.
рядовой сборщик мусора прекрасно с ними справляется
> рядовой сборщик мусора прекрасно с ними справляетсяДа неужели?
>> рядовой сборщик мусора прекрасно с ними справляется
> Да неужели?Ну ... если жабский считать рядовым - то да.
PS: жабу не люблю, но истина дороже! :)
>>> рядовой сборщик мусора прекрасно с ними справляется
>> Да неужели?
> Ну ... если жабский считать рядовым - то да.
> PS: жабу не люблю, но истина дороже! :)Гм. Почему-то считал, что как раз в джаве он этого не умеет. Видать, допилили.
Вообще-то техники, решающие эту проблему, есть. Но конкретно в objective C не применяются, насчёт Swift - не знаю.
Не уверен, что ЭТО так уж стоит нашего внимания.
Вот хоть режьте меня, но технологически этот Swift не очень впечатляет.
Многие вещи сделаны из расчета, чтобы кодер уровня "только сел писать" не прострелил себе ногу, для этого породили вагон странных сущностей, которые по моему только мешают и запутывают.
Там хотя бы синтаксис адекватный, в отличие от обжси. И классы сделаны без новомодных извращений. Что там мешает и запутывает, расскажи мне?
"Там хотя бы синтаксис адекватный, в отличие от обжси." - очередной школьный фанат свифта
Вас ребята почитаешь, так как будто бы сборище неадекватов одних в комментах отмечается, обиженных на весь мир.
В мире где продать можно только первую копию программы, а остальные ты обязан раздавать бесплатно, выживают только лжецы, завистники и лицемеры.Спорим, что этот комментарий тоже удалял?
Вовсе не потому, что я заработал в прошлом месяце 370 т.р., а тот, кто его удалит, только 30.
И не потому, что я завтра улетаю на Болеарские острова, а он даже не знает где это.
Хотя... Может именно поэтому :-). Если бы у него каждый месяц появлялись 350+ штук и он мог позволить себе поехать на недельку на далёкие острова - он бы и ненавидел весь мир.
> В мире где продать можно только первую копию программы, а остальные ты
> обязан раздавать бесплатно, выживают только лжецы, завистники и лицемеры.Странное дело. В красивом мире где подают одну и ту же программу 100500+ раз, да ещё и запрещают другим сделать такую же, по кловану - в мире с розовыми понями и радужными флагами ... живают всё те-же лжецы, завистники и лицемеры :(
Вот так кидок ... :)> Спорим, что этот комментарий тоже удалял?
Мусор нужно чистить. У вас в хлеву заведено по другому, ну люди не живут не живут по ноздри в *овне. Становятся сначала клованами, а потом ... :(
> Вовсе не потому, что я заработал в прошлом месяце 370 т.р., а тот, кто его удалит, только 30.
Конечно по этому! Не стесняйся! Ведь ты в 12.333 раза лучше! :-))))
Деццкий сад. "А зато мой папка - алигарх!"> Хотя... Может именно поэтому :-). Если бы у него каждый месяц появлялись
> 350+ штук и он мог позволить себе поехать на недельку на
> далёкие острова - он бы и ненавидел весь мир.А если бы вокруг жили розовые поники вместо мерзких людишек ...:)
Кстати мудрость предков утверждает что кто о чём а лысый - о кудрях. Сколько раз ты там о 320 тыЩЩах прокукарекало?
Походу пошла оптимизация затрат в M$ $tudent$ :))) Оставят только самых агресивных.
Так что готовьтесь народ - скоро придётся смотреть крысиные бои без правил на выживание среди этой публики. Кста - ставлю на клована пол батончика снукерс :)
Не мешайте клоуну чесать ЧСВ. Его выше уже макнули, пусть хоть здесь душу отведет.
Больше языков хороших и разных. Если ещё и под MIT/BSD опубликуют - вообще хорошо будет.
Ишь ты как корпорасты заоткрывались!
Железо в зондах, базы в центре - софт можно и открыть.Лет через 5, когда население прочипируют, наличку запретят и сети возьмут под полный контроль - можно будет и на Open Hardware переходить.
У корпорастов не забалуешь - они яички сапиенсов всё равно не отпустят.
Ты как бестолковый арендатор жилья: ведут тебя в убитую квартиру за 33 тыщи, затем в убитую за 35 тыщ, затем в хорошую, но за 45, затем опять в убитую за 36 и ни копейки не скину. Ещё несколько раз по ходу спектакля вызванивают и договариваются о встрече, но потом перезванивают - сорвалось. Один разок ты даже приехал, но уже поздно, буквально перед самым носом хорошая квартирка ушла за 37 после 2-часового торга. И вот чудо, сам Путин улыбнулся тебе и появилась неплохая (ну так себе, но жить можно) квартирка всего за 34 тыщи.А спектакль в том, что цены квартиры на рынке 26-30, а всё в чём ты поучавствовал (заплатив за это риэлтору) - развод для... для тебя :-).
> в чём ты поучавствовал (заплатив за это риэлтору) - развод для... для тебя :-).Твои "things for living" всем понятны. Непонятно, зачем это нам здесь. Обратись к специалисту уже. </переименуйте его в говорящую табуретку>
> </переименуйте его в говорящую табуретку>Я - против! Клован - это брэнд! :)
> а всё в чём ты поучавствовал (заплатив за это риэлтору) - развод для... для тебя :-).Душещипательные мемуары! Донцова начала волноваться :-))))
Bradley M. Kuhn "Why Greet Apple's Swift 2.0 With Open Arms?"
. http://ebb.org/bkuhn/blog/2015/06/15/apple-is-not-our-friend...