- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
private void cb_activated(TreePath path, TreeViewColumn column) {
Totem.Object t = (Totem.Object)this.object;
uint selected = path.get_indices()[0];
uint current = t.get_playlist_pos();
if (selected > current) {
for (int i = 0; i < selected - current; i++)
t.remote_command(RemoteCommand.NEXT, "");
} else if (current > selected) {
for (int i = 0; i < current - selected; i++)
t.remote_command(RemoteCommand.PREVIOUS, "");
}
}
Vala. Тормозит эта хуйня жутко, так как Totem открывает все файлы в плейлисте, пока не доберётся до выбранного.
Follow us!
Тут смысл не в ЯП, а в ущербности биндингов.
Нету команды для перехода к i элементу плейлиста?
>кастовать можно что угодно во что угодно
Есть еще unionы и void*
И если юнион таки удобная и годная штука, void* (да-да-да, в сишке есть не только автовывод типов, но и генерики).
См также: "очень полезный тип указатель", "единственно верный тип данных массив"
Ну типа все что угодно это указатель на какой-то char?)
да, в си достаточно слабая типизация. Но именно это и было нужно так как программист должен управлять памятью. Например, он знает что в памяти лежит 2 байта определенного формата, и кастит int с этими байтами в структуру).
Понятное дело что писать бизнес-логику на этом грустно. Но это не говнистость, а особенность ЯП для конкретных задач. Иначе можно сказать что и ассемблер говнист.
>>Отсутствием инкапсуляции.
Инкапсуляция прекрасно достигается в сях! static функции + opaque types.
>> Плохо продуманый синтаксис.
да, синтаксис мог бы быть и по-лучше, согласен.
>> Куча каких-то безумных и ненужных правил работы со знаковыми / беззнаковыми числами.
Каких это?
Блин, как я люблю когда человек не понял зачем нужен инструмент, не осилил его и начал рассказывать про говнистость.
Молоток это говно! Им неудобно накалывать макароны (в той же вилке это в тысячу раз лучше решено!!). Им очень легко сломать себе ногу, если по ней ударить (заметьте: ни палка для селфи, ни мочалка такими проблемами на обладают!) и наконец молотком совершенно неудобно чесаться
Как я люблю, когда языки программирования сравнивают с отвёртками и молотками!
> Молоток это говно!
Конкретно у этого молотка могла бы и не отваливаться ручка через раз.
Сишка могла бы быть проще и удобней.
Не втыкать все эти неявные касты, упростить синтаксис, предоставить вменяемую альтернативу макросам, изначально продумать модульную систему (теперь-то мы модулей уже никогда не увидим) и т.п.
Касперски как-то приводил пример: ему нужно было повторить код N раз. Причем именно один и тот же код (не цикл, не вынос в функцию итд). В сях это почти никак не сделать, а в MASM делается макрос, коий параметризуется кол-вом повторений
BOOST_PP
но вообще нахуй такие упражнения
и сразу же сам сравнил:
>>Конкретно у этого молотка могла бы и не отваливаться ручка через раз.
Причем заметь: я в своем сравнении указал на конкретную глупость: товарищ ждет от инструмента не того, для чего он был задуман.
А о чем говорит твое сравнение? что такое "ручка отвалилась"? что-то перестало работать? компилятор упал? что такое ручка?
>>Сишка могла бы быть проще и удобней.
Разумеется!
А теперь скажи мне: есть-ли такой язык, который идеален и не мог бы вот уже быть проще и удобней?
>>упростить синтаксис, предоставить вменяемую альтернативу макросам, изначально продумать модульную систему
Тогда это будет уже другой язык, правда?
А что вы все доебались до модульности? Что не так с модульностью то?
Неймспейсов нет, это плохо, а еще что?
вы о том что знание о депенденсах пишется 2 раза: сначала в виде импорта, затем в виде ключика в Make файле?)
Ну так это намеренно, чтобы было понятней, как херово выглядят подобные размытые аналогии.
> А о чем говорит твое сравнение?
А что означает накалывать макароны молотком? Что здесь макароны?
> Что не так с модульностью то?
Её нет. Ваш кэп.
Извольте соблюдать ODR ручками, надейтесь, что обезяны, написавшие какую-нибудь библиотеку, не используют те же символы, что и ты, или те же символы, что другие обезьяны.
Ну и текстовые инклюды с перекомпиляцией хедеров раз за разом - это божественно.
Вы правда не поняли моей аналогии? Глупо ждать от "переносимого ассемблера" строгой типизации, правда?
Серьезно, говорить что минус сей в том, что "кастовать можно что угодно во что угодно" может только человек, который совершенно не понял зачем си нужны, и когда их нужно использовать.
>>, не используют те же символы,
да, в сях нету неймспейсов и это плохо. Но эту проблему решают префиксами. И, в целом, она решается.
>>Ну и текстовые инклюды с перекомпиляцией хедеров
А есть percompiled headers вообще-то.
Пляски с include guards это правда оцтой, но например в Objc эту проблему решили конструкцией #import (не путать с VCшным #import).
>>Её нет. Ваш кэп.
Дайте пожалуйста определение модульности.
Нет, не глупо. Слабую типизацию сделали исключительно потому, что создателям было лень писать явные касты руками.
> А есть percompiled headers вообще-то.
Костыль.
стоп! Так претензия в _неявном_касте_ или в физической возможности скастовать поинтер в int _в_принципе_ ?
Это важно. Потому что если проблема в неявности, то я согласен (хотя и так компилятор выдаст варнинг)
>>Костыль.
все, короче я понял чего вы хотите
Вот этого:
https://stoneofarc.wordpress.com/2013/06/25/introduction-to-objective-c-modules/
да?
> стоп! Так претензия в _неявном_касте_ ... ?
читать умеешь, гест?
> (хотя и так компилятор выдаст варнинг)
Не всегда. Нуль, к примеру, прекрасно кастится к указателю даже в плюсах, на это запросто можно наступить.
> все, короче я понял чего вы хотите
Хотим модулей хотя бы в том виде, в котором они реализованы в D.
Посмотри выше.
Хочется верить что в 2016м году попытка его разыменовать приведет к ошибке в большинстве сред)
резюмируя:
В сях много говнистости (неявные касты, модульность реализуемая в полуручном режиме, путаный (в сложных случаях) синтаксис). Это правда.
Но ни ручное управление памятью, ни возможность кастить что угодно во что угодно *НЕ* являются проблемами сей, ибо это именно то, ради чего они были сделаны.
Ну и инкапсуляция, очевидно, так же не является особенностью языка (это особенность кода)
Язык задаёт тон. Или плясать с гирей на ноге, или с ленточкой. Конечно, это особенность танцора, но гиря мешает.
В том же жс можно так спрятать функцию в функции, что даже её имя никто не узнает, не то что вызовет. Можно разделить задачу на мелкие части и вкладывать функции в функции так, чтобы более мелкие куски из одной подсущности не знали своих двоюродных братьев, не имели к ним доступ без воли бабушки. В C для такого же эффекта (точно такого же? если в 2х файлах одно и то же имя неэкспортируемой сущности, не бомбанёт?) нужно создавать несколько файлов.
Нет. JS, вообще говоря, не самый удачный пример модульности :) Образцом я лично считаю StandardML.
Даже за импортить модуль в языке нельзя, нужны левосторонние либы.
инкапсуляция есть сокрытие внутренней структуры с использованием публичного интерфейса
в сях это прекрасно работает, это те самые opque types о которые я уже изык разбил
HANDLE в w32api
ну чем не инкапсуляцы?
> ну чем не инкапсуляцы?
Инкапсуляция, не спорю.
Но в JS инкапсулировать легче. function в function через function и уже не то, что в одном и том же файле, в одной и той же функции питушня сокрыта.
Точнее сказать язык дает инструменты.
Сишечка позволяет модульность, но модули нужно поддерживать руками:
1) в .h файле
2) в .c файле
3) во всех местах испольхования
4) в сборщике (передать нужные опции линкеру и компилятору)
5) следить за ODR
6) следить за неймингом
В сях не бомбанет если две функции статик
Инкапсуляция нуждается в инструментах, для того, чтобы ее можно было реализовать. Возможно, авторы Си не представляли себе необходимости писать большие / модульные программы, вот они и не заморачивались этим вопросом.
>> Практических бонусов каких-то от этой фичи нет.
Нет.
В спецификации вот даже на IBM PC есть знания о том, по каким адресам в памяти доступен, например, BIOS.
Очевидно что в си именно для этого можно пойти в память по определенному адресу.
>>Инкапсуляция нуждается в инструментах, для того, чтобы ее можно было реализовать.
И снова: В Win32API _прекрасно_ реализована инкапсуляция. И не только в нем.
Она есть, я не спорю. Но реально она решается путем конвенции: давайте функциям префиксы, и все будет работать.
Инкапсуляция прекрасно реализуется без неймспейсов. Разгребайте уже кашу в голове
Ну так-то сишка на удивление мультипарадигменный язык. При должном усердии и внимании, в нем прекрасно реализуется модульность, инкапсуляция, полиморфизм, наследование, обобщённое программирование, функциональное программирование и даже автоматическая сборка мусора!
Во-вторых неймспейсы это просто способ нейминга, к инкапсуляции он отношения не имеет.
В ObjC нету неймспейсов, а инкапсуляция в Cocoa прекрасная.
В PHP 6 есть неймспейсы, а инкапсуляции обычно никакой нет.
Именно поэтому он не вышел в релиз?
когда там у вас эти спейсы появились?
Он не т в 5.4 трейты появились неймспейсы значит еще раньше в 5.3. а это 9 год.
А как мне обратиться к пачке memory mapped регистров по адресам 0xEFFF0000 .. 0xEFFF0007?
Друг с другом их и не дают складывать. Только с числом. И умножать-делить не дают. Только вычитать ещё можно (получается знаковое число). И указатели в числа и обратно не кастуются, если явно этого не захочешь...
Вот у меня есть адрес начала блока 32-битных регистров. Как мне получить адрес i'го регистра в блоке? Кроме как прибавить число к адресу?
вот у тебя есть знание о том, что волшебное яйцо лежит по адресу 0x1234.
Как тебе по этому адресу обратиться не используя int? Ведь литерал 0x1234 будет иметь тип int, а значит придется int кастить в pointer!
А вот от арифметики над адресами один хуй никак не избавиться. Ну и от желания указывать адреса в конфигах, собирать их из байтиков по кускам и творить прочие непотребства...
В любом случае нужно прибавлять не число, а расстояние от одного адресса до другого. Как именно это сделать - проблема компилятора. В итоге это все-равно будет сложение чисел, вот только смысл будет другой с точки зрения программиста.
Просто числа в Си плохие изза того, что их решили использовать для представления памяти, ну а потом поняли, что может это было не самым удачным решением, но поезд уже ушел.
К слову об замечательных инкапсуляциях в ВинАПИ: чет у них не очень получилось заинкапсулировать способ адрессации памяти, и врезультате такой замечательной инкапсуляции, 32-битные программы будут еще очень долго поддерживаться отдельными костылями.
>> не очень получилось заинкапсулировать
Очевидно что дело тут в кривых руках пользователей. Если не использовать знание о размере поинтера, то проблем нет.
cl.exe: error C2110: '+' : cannot add two pointers
gcc: error: invalid operands to binary + (have ‘char *’ and ‘char *’)
Знаешь, почему я не рассуждаю об истории Суахили?
Потому что ничерта в ней не понимаю.
Ну тогда возвращаемся к первому вопросу:
>>лол, какие есть способы описать некое расстояние не прибегая к числам?
А в Vala типа не ручное? Там ещё хуже - если в сишке понятно, что за всё сам отвечаешь, то с валой надо понимать, где какой сишный код сгенерится, что там управляемое, а что нет.
Пытался ради интереса посмотреть эту порнографию, но уж лучше на C++ писать, и с "биндигами" проблем не будет.
Даже Canonical забросил эту унылую Vala и фигачит новые проекты на Qt.
с другой стороны, кто в нынешние времена вообще что-то новое на gtk писать начинает? все нормальные люди давно на WxWidgets или Qt пересели.
https://www.youtube.com/watch?v=ON0A1dsQOV0
например тот же reference counting легко организовать и в C, и например в ObjC (до ARC) люди прекрасно себе жили с полуручным управлением
о чем ты?
ты видел как RefCount сделан с COM или Objc?
зачем пользоваться очевидно нестабильным, сырым, и при этом не развивающимся инструментом?
конечно, ЯП за 10 лет прошедший путь от 0.0 до 0.3 быстро развивающийся
Цифры версии вообще ничего не значат. Могут три мажорные версии поменять и поправить два минорных бага. А могут с 0.1 дойти до 0.2 и поменять вообще всё.
Цифры. Цифры ничего не значат.