The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В компилятор языка D добавлена поддержка WebAssembly, opennews (?), 18-Июл-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


5. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от Аноним (5), 18-Июл-18, 10:59 
не вижу смысла в плюсах, когда есть няшная сишка для низкоуровневых (и не очень) дел, не-гиперпереусложненные D/Vala для "си с классами", ну и Java для высокоуровневого надежного энтерпрайз-кода.
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

51. "В компилятор языка D добавлена поддержка WebAssembly"  –1 +/
Сообщение от Аноним (4), 18-Июл-18, 14:41 
Няшная сишка, риали?
Да одно сравнение char* vs std::string / QString показывает всю антиняшность "простого" языка C :)
Ответить | Правка | Наверх | Cообщить модератору

54. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от Аноним (54), 18-Июл-18, 14:57 
А кто-то мешает использовать либы под си? Я вот glib в своих поделках использую.
Ответить | Правка | Наверх | Cообщить модератору

59. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от Аноним (59), 18-Июл-18, 16:02 
Дак сравни char* vs std::string::c_str(). Что ты указатель сравниваешь с объектом?
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

61. "В компилятор языка D добавлена поддержка WebAssembly"  +1 +/
Сообщение от Аноним (4), 18-Июл-18, 16:28 
При чем тут? Сравнивается подход и удобство.
Ответить | Правка | Наверх | Cообщить модератору

63. "В компилятор языка D добавлена поддержка WebAssembly"  +1 +/
Сообщение от Аноним (-), 18-Июл-18, 17:13 
> std::string::c_str()

Это всего лишь один из 'view' для строки, причем read only

> char*

это может быть что угодно. Обычно считается, что это null-terminated строка, но находятся уникумы, что используют это вместо uint8_t*.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

64. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от нах (?), 18-Июл-18, 17:40 
> но находятся уникумы, что используют это вместо uint8_t*

например, сами разработчики языка, которые никакого ^^^ не изобретали.
зато работали на машине, где процессор работал не с байтами, а со "словами", непременно выравненными, а для байтов был отдельный набор команд. Поэтому им понадобился int и char, совершенно не отражающие того факта, что первое для цифр а второе для букв. bcpl обходился типом "byte".

Ответить | Правка | Наверх | Cообщить модератору

69. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от Аноним (69), 18-Июл-18, 18:26 
Точнее, (char * + size_t) vs std::string. Терминированная 0-м строка - давно уже архаизм, хотя и используется повсеместно.
Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

88. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от нах (?), 19-Июл-18, 10:30 
> Терминированная 0-м строка

является фичей почти всех существующих процессоров - если даже не в виде команд, работающих непосредственно с такой строкой, то хотя бы в особенностях инструкций jz/jnz, использующих результат предыдущей операции БЕЗ необходимости отдельно сравнивать его с чем либо.

когда язык C только писали, второе уже было.

как только вы изобретете процессор, работающий с паскалевскими строками столь же эффективно - можно будет считать эту фичу "архаизмом".

Ответить | Правка | Наверх | Cообщить модератору

90. "В компилятор языка D добавлена поддержка WebAssembly"  +1 +/
Сообщение от Аноним (90), 19-Июл-18, 11:54 
>> Терминированная 0-м строка
> является фичей почти всех существующих процессоров - если даже не в виде
> команд, работающих непосредственно с такой строкой, то хотя бы в особенностях
> инструкций jz/jnz, использующих результат предыдущей операции БЕЗ необходимости отдельно
> сравнивать его с чем либо.

Т.е. в вашей вселенной дешевле каждый раз искать конец строки проходом, вместо одноразового запоминания длины? Интересно!

> как только вы изобретете процессор, работающий с паскалевскими строками столь же эффективно
> - можно будет считать эту фичу "архаизмом".

Я вас огорчу, но у нас, для эффективной работы уже давно сохраняют длину строки и тянут ее с собой. Потому что в нашей вселенной загрузить эти данные выйдет быстрее, чем исать 0x0 в куске памяти, даже с помощью SIMD.
Да и std::string для плюсов у нас тоже делали, не послушав опеннетных знатоков.

Ответить | Правка | Наверх | Cообщить модератору

95. "В компилятор языка D добавлена поддержка WebAssembly"  –1 +/
Сообщение от нах (?), 20-Июл-18, 16:24 
в нашей вселенной не нужно вообще искать конец null-terminated строки - именно для этого она null-terminated.

Есть задача с этой строкой что-то сделать, и не уехать за ее край. И вот второе - со времен dec pdp11 - не требует никакой отдельной операции. Просто команда процессора сама перестает выполняться, доперебирав символы до этого нуля.

а процессоры, поддерживающие паскалевские строки, у нас неизвестны.

Ответить | Правка | Наверх | Cообщить модератору

96. "В компилятор языка D добавлена поддержка WebAssembly"  +/
Сообщение от Аноним (90), 20-Июл-18, 19:10 
> в нашей вселенной не нужно вообще искать конец null-terminated строки - именно для этого она null-terminated.

Все может быть. У вас там может и релок дешевый и хип не фрагментируется, так что при вставке или соединении длинной строки можно на каждый чих переаллоцировать. И целого вагона уязвимостей на почве "тут же должен был быть \0! Мы ждали!" у вас там наверное нет. И работать со строками можно не спеша, загружая каждый знак по отдельности. Хорошо вам там.

> Есть задача с этой строкой что-то сделать, и не уехать за ее
> край. И вот второе - со времен dec pdp11 - не требует никакой отдельной операции. Просто команда процессора сама перестает выполняться, доперебирав символы до этого нуля.

Познаково, ага.
Хочешь копировать или искать или еще что-то - можешь загружать за один заход 4-8-16 байтов (переход на 32-бита, появление MMX, SSE и т.д.), но будь любезен проверить все загруженные байтики на наличие 0.
Особенно доставляло  при необходимости выравнивания для чтения в (x)mm - если строка короче, то больше потратишь на высчитывание смещения и прочую подготовку. Особо неверующие и теоретики могут глянуть оптимированные варианты сишных операций со строками.

> а процессоры, поддерживающие паскалевские строки, у нас неизвестны.

У нас с незапамятных времен тот же штеуд умел.
Cтарые добрые repz, loopz.
Это если брать CISC c жирным микрокодом.

Еще, до сих пор работает
mov REG, [strlen]
...
dec REG/sub REG, 4 (8,16,42)
jnz/jnb mysuperloop / CMOVXXX REG, REG


Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру