Мне хватило услышанного, чтобы я понял, что с С++ я вообще никаких дел иметь не собираюсь! И если у меня вдруг возникнет нехватка ООПщины, то я приму галоперидола и успокоюсь.

Ну да. Соглашусь.

Проприетарного кода на крестах поболее будет

А если сюда ещё приплюсовать такое адское поделие как managed c++, точнее C++/CLI, то...

Только С++ это весьма условно и... Ну, в общем, сложно всё. Не будем плюсовать. ;)

На С ООП тоже можно.

А у галоперидола, как говорят, неприятные побочные эффекты. =)))

Не стóит

На С ООП тоже можно

В этом случае может вырасти дебильный уродец вроде glib. Нет уж, чтобы уродов не сбрасывать со скалы, лучше их не зачинать!

В ядре целая подсистема...

Именно так, «в стиле ООП» и написана. VFS. Ничего, работает вроде. Расширяемая, удобно.

А по временам это здорово экономит время и усилия и ресурсы. goto cleanup: и всё почистили.

Удивительная хрень. Нет чтобы просто добавить что-то типа. defer, но ведь тогда код получится не Ъ-тру. И это тупизм, уже и писак стандартов, и Си поклонников. Нормальную очистку можно только через goto реализовать. И единственный адекватный выход — это defer. Даже есть ГНУ-расширение, реализующее этот дефер. Но оно настолько же тупое как Си. И единственная причина, по которой дефера нету в стандарте — это все программисты Си, боясь, что их засмеют, назовут не ь-трю, раскрыть свой реальный уровень интеллекта, не пишущие об этом нигде.

Зато у них есть норетёрн, какое достижение. Если учесть, что ГСС (кстати правильно ГГС, т.к. Си — это говно) в состоянии распознать вызов exit-ов, то необходимость сего решения ещё сильнее возрастает.

Нормальный ЯП делается сообществом с любовью и при модерации бородатых дядек. Си — это общий сортир, куда каждый срёт, и дядьки те просто сортируют говно.

И эта философия пропитывает каждого программиста Си до мозга костей.

Мне хватило услышанного, чтобы я понял, что с С++ я вообще никаких дел иметь не собираюсь!

Это ты правильно понял. Твоих 8-битных мозгов не хватит на кресты. Сиди лучше в своей песочнице и не высовывайся.

Глядя на объёмы стандартов...

Си — это общий сортир, куда каждый срёт, и дядьки те просто сортируют говно.

С++ это общий сортир, куда каждый срёт...

Поправил. Не благодарите.

В остальном — позвоните Оккаму. Пусть он Вас побреет. У него есть бритва. =)))

А у галоперидола, как говорят, неприятные побочные эффекты.

У Си ООП тоже. И предшевствующие неприятные тоже. И сопутствующие.

Нет уж, чтобы уродов не сбрасывать со скалы, лучше их не зачинать!

А ты крепкий.

Ничего, работает вроде.

Угу. Про пространство имён тактично умолчи.

Спасибо, посмеялся.

Владимир 123456

Поправил. Не благодарите.

И не буду.

Владимир 123456

Привет копрофилам вселенной.

Есть два подхода в программировании — а точнее к программированию это вообще отношения не имеет, но не суть — это когда компилятор делает всё возможное, и программист просто пишет свой код. И второй. Второй выбор для тех кому не хватает ума открыть для себя GNU Assembler и играться с камнем пока это не осточертеет. Потом закрыть его и больше к нему не возвращаться. Нормальный программист в курсе, что такое стек, регистры. И прочее. Как там всё устроено. Потому что хавает низы в первую очередь, а потом приправляет это хай-левлом, постепенно поднимаясь с каменного дна.

Есть и другой подход. Это вообразить себе, что Си — это лов-левел и ниже только дно. Думать о себе много. При этом желание поиграть с камнем никуда не денется. Вот они и играются. Но мозгов спуститься пониже уже нету.

Как итог, первый тип программистов решает, что всё что может делать инструмент, должен делать инструмент. И инструмент этот должен обрастать инструментами для помощи.

Программисты второго типа — этакие дворовые мальчишки с пирочинным ножём, которые думают, что у их ножа сразу 500 функций, и в то числе и втирать зад.

Программисты второго типа — этакие дворовые мальчишки с пирочинным ножём, которые думают, что у их ножа сразу 500 функций

Чем-то напомнил спор про раст и с/с++ с анализаторами. Одни всё суют в язык, другие считают что

всё что может делать инструмент, должен делать инструмент. И инструмент этот должен обрастать инструментами для помощи.

Он никогда не был стройным. Это часть его философии. Не указывать программистам, как им писать. Вам не нужно знать весь C++, чтобы писать на нем программы. Тем более, если речь про стандартную библиотеку. Не нравится фича оттуда - не используйте.

Ну т.е. конструктивного ответа не будет? Жаль.

А по временам это здорово экономит время и усилия и ресурсы. goto cleanup: и всё почистили

RAII сэкономит время, усилия и ресурсы еще лучше. При этом вы от него ничего не теряете. Ничего.

Не нравится RAII(деструкторы, видимо), но хотя бы with/using/try-with-resource или defer был бы полезен даже в Си.

Чем-то напомнил спор про раст и с/с++ с анализаторами. Одни всё суют в язык, другие считают что

Я не разделяю, если ты не понял, язык и плагины. Так что твоё «напомнил» — неудачное отклонение от сути.

Ну все кандидаты у тебя уже в списке. Что хотел-то?

Человеческая замена C для своих задач

IMHO, современному программисту необходимо и достаточно знать три языка:

• C++
• Kotlin
• JavaScript (современный Python)

Если ты не программист, то достаточно Kotlin или JavaScript (в зависимости от твоих задач). Kotlin - кроссплатформенный.

Если не пугает jvm, то kotlin. Если пугает, то только C++. Можно попробовать D.

С D все разумные люди, которые на него смотрели, давно сбежали (бесполезный для практики язык, который сам создатель до сих пор не может объявить стабильным), остались только самые упертые велосипедисты.

Kotlin Native работает без всякого JVM, кроссплатформенно.

Это подсчет средней ширины строк на stdin-е.

Если ты так топишь за D, почему ты сам его не используешь? Или для тебя это «тема поболтать»?

Ну и там jvm же, а го собирает статически слинкованный бинарь.

Kotlin Native уже пару лет как есть.

трындеть то, конечно могут все, но вот бенчсарки говорят, что С не так хорош. Или насильники отупели ? Ни в одной категории С не взял первое место. https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json

Ну, любители простого язычка, поясните свою илитарность, или только на лорчике трынлеть ?

но вот бенчсарки говорят, что С не так хорош

Плюсам это барахло всегда сливало, но оно даже Go сливает, языку со сборщиком мусора. Если учесть скорость разработки и всё прочее, то Си давно пора слить на днище. Даже как высокоуровневый ассемблер он слишком тупой.

P.S.: а потом говорят, что всякие Расты быстрые, сравнивая его с этой улиткой, лол, кек.

точно! https://github.com/BurntSushi/ripgrep#quick-examples-comparing-tools

точно! https://github.com/BurntSushi/ripgrep#quick-examples-comparing-tools

Скорость grep, кстати, – это целиком заслуга его алгоритма, который грамотно строит регулярку. А Си, видать, выступает в роли тормоза, чтобы слишком быстро не показалось, да ещё и было чертовки сложно добавить поддержку Юникод. Специально для любителей повесить себе наковальню на шею, чтобы легче было идти.

Кстати программирование, дети мои, – это в первую очередь алгоритмы и структуры данных. А язык выбирается под задачу. И нет смысла копошиться в старом хлмае, пытаясь отыскать в этой куче что-нибудь блестящее.

Go известен как очень быстрый компилятор. И очень легко используется в режиме скрипта:

//usr/bin/env go run $0 «$@»; exit package main

import ( «fmt» «os» )

func main() { fmt.Println(«Hello world!») cwd, _ := os.Getwd() fmt.Println(«cwd:», cwd) fmt.Println(«args:», os.Args[1:]) }

На компиляцию, запуск и отработку на мобильном sandy bridge уходит около 300 мс.

Вот по-настоящему быстрый компилятор (luajit):

local lfs = require"lfs"                                                                                                                                    
print("Hello world!")                                                           
print("cwd:", lfs.currentdir())                                                 
print("args:", ...)                                                             

$ time luajit /tmp/test.lua 1 34 56
Hello world!
cwd:    /tmp
args:   1       34      56

real    0m0,002s
user    0m0,000s
sys     0m0,000s
$

На самом деле, конечно, это jit-компилятор.

s/go/rust

Раст инопланетное создание для рептилоидов.

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

А а питоне нет типов?

В каком месте goawk быстрее? Ты его описание-то смотрел? Или просто увидел большие цифры у гнутой реализации?

В каком месте goawk быстрее? Ты его описание-то смотрел? Или просто увидел большие цифры у гнутой реализации?

Я те линк на бенч дал, анонимус, там всё написано. Си посасывает местами, неслабо так, у языка со сборщиком мусора, да с причмокиванием. А какого-то феноменального отрыва там и в помине нету. Ну если только отрыва от Си, этого днища.

Нет. Когда пытаются добавить — получается извращение. Динамический язык должен быть динамическим языком, это хорошая вещь для своих задач.

Всё ясно. Там выше ссылку на ripgrep дали - тебе в самый раз будет

Всё ясно. Там выше ссылку на ripgrep дали - тебе в самый раз будет

Ссылку на то как медленный Си сосёт у медленного Раста? Да, мне было интересно посмотреть на это порно.

«Смотрю в книгу, вижу фигу» (c)

Впрочем, не удивлён

не удивлён

Дыму из собственного сфинктера? Это называется «пукан горит». Всё от неприятия правды, какой бы она не была.

Самая большая проблема любого языка программирования состоит в том, что на 99.99% его используют «остроконечники» и «тупоконечники».

Одни всё суют в язык, другие считают что

Если язык не обеспечивает какое-то свойство программы (отсутствие use-after-free, скажем), то имеем теорему Райса о невычислимости нетривиальных свойств программ. То есть статические анализаторы могут отловить только какие-то частные случаи.

В гномовских проектах и раст видел. Берите раст.

type("")

<class 'str'>

type([])

<class 'list'>

type({})

<class 'dict'>

Нагло врут?

Если честно...

То я удивлён. =))) Как ни странно, но Вы даже почти поняли что именно и с чем сравнивается по приведённой Вами ссылке.

Хорошая попытка но нет, недолёт.

В приведённой Вами ссылке сравнивается реализация grep на rust с тем же GNU grep. И, казалось бы (азохнвей!) С-реализация сливает.

Но. Вообще-то, в rust-реализации использована либа, которая реализует pcre2 и реализует их (регулярки) через SIMD. Почитайте, у Вас в ссылке это написано.

В grep используется своя реализация (внутренняя!) регулярок, которая поддерживает не только Линукс, а ещё и всякие там dos, AIX, ещё полно всякой фигни. Нет, спрашивать запустится ли реализация на rust в AIX, я не буду, т.к. ответ будет «а нам и ненадо». Это не ответ для кроссплатформеного ПО, но пусть будет так.

Для корректного теста следовало бы подчистить код и использовать libpcre2. Эта реализация намного быстрее будет и даже будет быстрее, чем pcre, входящие в состав glibc (это тоже кроссплатформенно, т.к. будет работать там, где есть glibc, в т.ч. и на всяких AIX). Тут можно задуматься ещё и об объёме кода, но кто же в наши времена о таких мелочах думает? =))) Разве что сишники?

Дальше больше и хуже. Проблема в использовании SIMD. Инстриники штука хорошая за исключением нескольких «но». Во-первых, они должны быть в целевом процессоре. Даже NEON-инструкции при схожей семантике имеют слегка другой синтаксис. Так что, Вам стоит переписать используемую Вами либу так, чтобы она работала и на x86_64 и на ARM. Иначе, это как-то выглядит как на хер ненужно в наши времена.

Во-вторых, безумная векторизация это не панацея. Сами по себе инстриники штука хорошая в том же gamedev. Т.е., когда на хосте запущена игрушка, то навряд ли Вы будете на том же хосте считать что-то требующее повышенных ресурсов. Проблема в том, что общая производительность здесь просядет из-за массовых пересылок между основными ядрами проца и сопроцессора. У Вас либо вздёрнется система по шине, либо кеш будет холодным. Так что, я не уверен в том, что использование инстриников где-то за пределами какой-то мультимедии (видео и аудио, тот же gamedev) это полезная штука. Ну либо в каких-то вычислительных задачах (привет тем же матрицам). В поиске регулярок в файле? Да вы там пиз...... эээ... «с ума сошли»!

Я не копал (и не собираюсь) rust глубоко, но если этот подход в rust является массовым, то сделайте милость — спрячьте это и больше ни кому не показывайте. Пока я понял только то, что с огнелисом мне всё таки, придётся распрощаться. Не люблю когда криворукие олени ставят мою систему своим кодом раком.

Спасибо за наводку. Всё стало ясно. Уж лучше самописный браузер (там писать немного) на С с тем же WebKitGtk, чем такая ярая антинаучная херня. Теперь мне стало понятно почему в других тестах rust грузит проц на ~100%.

Для тестов оно хорошо. А вот для практической работы в многозадачной системе... да ну его на хер.

Приветствую секту свидетелей джетбрейнсов.

Владимир

Не понял?

Вам не нужно знать весь C++, чтобы писать на нем программы.

Это что, шутка? Ну в наши времена уже можно говорить о «программировании на Qt» в противовес «программированию на С++», но тогда Ваши же слова можно переписать как

Вам не нужно знать C++, чтобы не писать на нем программы.

Да, в таком случае он не нужен ибо это прямая дорога к костылям, распоркам и подпоркам. Когда вместо использования существующих в языке механизмов я буду велосипедить что-то своё.

Тогда лучше уж грамотно на С, чем кое-как на С++. Хоть не стыдно будет за получаемые за работу деньги.

Для того, чтобы дать ответ...

Конструктивный, я должен Вам напомнить как именно в С происходит работа с ресурсами.

Тогда вот это вот Ваше утверждение:

RAII сэкономит время, усилия и ресурсы еще лучше. При этом вы от него ничего не теряете. Ничего.

Оказывается голословным.

Напоминаю — при запросе на выделение ресурсов, в С дёргается ядро посредством некоего системного вызова, вызываемого через системную функцию, входящую в состав системной библиотеки времени исполнения. Системный вызов либо может удовлетворить запрос программы (есть у ярда запрошенная память или файл может быть открыт), либо возвращает значение, сигнализирующее об ошибке и выставляет соотв. значение errno. Нам остаётся только проверить возвращаемое значение и, если всё плохо, то глянуть errno, что там произошло собственно. Нет памяти или доступ к файлу запрещён/нет такого файла или ещё что.

Всё просто и красиво. RAII не нужен. В С. В С++ иного выхода нет. Почему, собственно, RAII и распространён так широко в С++ и, по сути, больше ни где.

И да, забыл!

Я там бегло глянул код на rust. Сделайте милость — либо jemalloc выкиньте из рустовой реализации, либо тогда уж реализацию GNU с ним же перепишите. В дополнение к выше сказанному.

Просто потому, что сравнивать код нужно по-честному, а не в стиле малолетнего долб..., ну Вы поняли, да? Типа «ахаха! Сишечка сасёт!!11адын-адын».

Мы тут вроде как все собрались в той или иной степени программисты-профессионалы, да? Давайте уж как-то более приличествующе случаю. По-профессиональному? ;)

gambas, очевидно.

А я и вспоминать не буду.

Угу. Про пространство имён тактично умолчи.

Если мне нужен код «в стиле ООП» из-за безусловных удобств записи и использования, то я его получу. Если мне нужен будет «именно ООП», то я и его получу ценой несколько бОльших усилий. Но зачем? Зачем решать несуществующую задачу?

Не всегда программирование это работа с объектами и только.

Так пространство имен не такое уж ООП. Пространство имен же нужно чтобы не было коллизии имен функций и т.п. Разве нет?