Модули в C

Многие перешли от плюсов к сишке, какой у них синдром, доктор?

в C был Electron

Толсто.

А вообще можно так:

#include <lua.h>
#include <duktape.h>
...

Я и не планирую, хотя для своего удовольствия я бы попробовал что-нибудь пописать на фортране.

Для удовольствия можно :)

Начиная с Fortran2003 с массивами стало даже приятнее работать. Если в Fortran95 для прибавления к массиву куска другого массива приходилось делать, например, так

program array_reallocation

    implicit none

    real, dimension(:), allocatable :: A
    real, dimension(:), allocatable :: B
    integer :: i
    real, dimension(:), allocatable :: buff

    allocate( A(4) )
    A = (/ (i, i=1,4) /)
    print *, "A:", A

    allocate( B(2) )
    B = (/ 5,6 /)
    print *, "B:", B

    !! действия с массивами
    allocate( buff(size(A)) )
    buff = A

    deallocate(A)
    allocate( A(size(buff) + size(B)) )

    A(1:4) = buff
    A(5:6) = B
    deallocate(buff)
    print *, "A:", A

end program array_reallocation

...
    !! действия с массивами
    allocate( buff(size(A) + size(B)) )
    buff(1:4) = A

    deallocate(A)
    call move_alloc( buff, A ) !! автоматический deallocate(buff)
                 
    A(5:6) = B
    print *, "A:", A

    !! действия с массивами
    A = [A(:), B(:)] !! или просто A = [A, B]
    print *, "A:", A

RC это хорошо, но циклические ссылки остаются.

Ну и страшный он как perl.

В каком месте это ООП?

Многие

Цифры в студию.

Вот говорят, что C устаревает с каждой минутой

не фига он не устаревает. Он хорош в той нише в которой есть, и не стоит ему куда-то меняться* т.к. в той нише он шикарен.

* - он конечно меняется, новые стандарты появляются, но слава Сущему, они не портят язык и не меняют его, например сборщика мусора нет, свобода с указателями и т.п. - это плюсы языка над его «неуспевышими устареть» «конкурентами» :)

Судя по тому, что я понял, строка addon "classes" должна магическим образом добавлять в конкретный компилятор инструкции по парсингу, кодогенерации и оптимизации языка «C с классами» (который является надмножеством целевого языка), и, возможно, рантайм. Каким образом предлагается это делать в рамках сишечки — непонятно.

В каком месте это ООП?

В любом. Это почти то же самое, что происходит в C++ при объявлении класса, только с кишочками типа this наружу. Если C++ не ООП, то вам в клинику.

Если программисту нужны классы, то он например

юзает C++ или ObjC

(fxd)

А теперь сообразите наследование с виртуальными методами + protected + friend.

Если C++ не ООП, то вам в клинику.

С каких пор С++ стал эталоном ООП?

Нда, до чего прогресс дошёл. Действительно заставляет задуматься.

А теперь сообразите наследование с виртуальными методами + protected + friend.

Наследование - определение новой структуры с unnamed структурой предка в качестве «головы», виртуальные методы - никто не мешает сделать obj->method = new_method, protected - пихаются в конец структуры, а для внешнего использования делается укороченная структура без приватных полей, френды - вообще просто обычные функции которые что-то делают с объектом.

Сэр, видимо, полагает, что ООП языки выдают какой-то особенный ассемблер, отличный от того, что выдаёт C. Ну-ну.

Абсолютно всё, что есть в С++ можно реализовать и в С, просто чуть менее удобно.

С каких пор С++ стал эталоном ООП?

А что, уже изобрели эталон ООП, на котором пишут больше полутора человек, и даже есть тот, кто написанное использует?

там же даже приличных многомерных массивов нет

Что такое «приличный» многомерный массив? И где есть «приличные» многомерные массивы, так чтобы скорость выполнения кода от С не сильно отличалась?

А ведь славно вбросил.

Что такое «приличный» многомерный массив?

Индексы в котором не нужно линеаризировать вручную

И где есть «приличные» многомерные массивы, так чтобы скорость выполнения кода от С не сильно отличалась?

Думаю, что в Фортране. В Си++ можно сделать.

Индексы в котором не нужно линеаризировать вручную

Я думаю, при компиляции разница нивелируется. Но если уж хочется синтаксического сахара, то есть GSL.

Индексы в котором не нужно линеаризировать вручную

Я думаю, при компиляции разница нивелируется

Ы? Меня не интересует время компиляции. Я не хочу писать линеаризацию вручную.

Индексы в котором не нужно линеаризировать вручную

Что это? Гугл не помог. Покажите, пожалуйста, на примере.

Я про то, что компилятор сам за тебя всё оптимизирует. Ну или используй GSL для 2d arrays + https://savannah.nongnu.org/projects/marray/

Я про то, что компилятор сам за тебя всё оптимизирует

После того, как я напишу линеаризацию вручную? Это неинтересно.

marray

Я понимаю, как это можно сделать библиотекой, но выше кто-то хотел «так же эффективно».

Индексы в котором не нужно линеаризировать вручную

Что это?

Преобразование обращения к элементу многомерного массива в обращение к элементу одномерного массива:

float a[M][N][K];

assert(&a[i][j][k] == &((float *)a)[i*N*K + j*N + k]);

Абсолютно всё, что есть в С++ можно реализовать и в С, просто чуть менее удобно.

Видел я эту лапшу на макросах в glib - нет, спасибо. Просто зачем писать тонны говнокода на сишке, если можно взять нормальный язык?

А что, уже изобрели эталон ООП, на котором пишут больше полутора человек, и даже есть тот, кто написанное использует?

Java?

А мне в С порой лямбд нехватает. В таких случаях просто использую С++.

P.S. Урезанный С++ рантайм под контроллеры уже давно есть.

Преобразование обращения к элементу многомерного массива в обращение к элементу одномерного массива

Простите мне мою тупость, прошу пояснить ещё очевиднее.

assert(&a[i][j][k] == &((float *)a)[i*N*K + j*N + k]);

Вижу неудобство, но не понимаю зачем это нужно. В общем случае получается что-то вроде:

int arr[x][y];

for (int i = 0; i < x; ++i)
        for (int j = 0; j < y; ++j)
                arr[i][j] = i * 10 + j;

прошу пояснить ещё очевиднее.

Яснее не могу.

не понимаю зачем это нужно.

Напиши (на Си) функцию, которая печатает 3-мерный массив c произвольными размерностями.

Видел я эту лапшу на макросах в glib - нет, спасибо.

glib - совсем не образец для подражания.

Просто зачем писать тонны говнокода на сишке, если можно взять нормальный язык?

А зачем футбол смотреть? Редкостный же дебилизм - наблюдать за тем, как в течении полутора (!) часов 22 не очень умных человека бегают по полю за одним-единственным мячиком.

Захотелось человеку ООП в сишке, ну вот ему ООП. Чего такого-то?

Java?

И назови же мне хоть одно жабоприложение, которое ну хотя бы 70% лоровцев используют у себя на линуксах.

Нету такого? Облом с эталоном, вот ведь незадача.

Допустим:

#include <stdio.h>

void print_arr (int x, int y, int z, int arr[x][y][z])
{
	for (int i = 0; i < z; ++i) {
		for (int j = 0; j < y; ++j) {
			for (int k = 0; k < x; ++k) {
				printf ("%3d ", arr[k][j][i]);
			}
			puts ("");
		}
		for (int j = 0; j < x * 4 - 1; ++j)
			printf ("=");
		puts ("");
	}
}

int main (void)
{
	int x, y, z;
	x = y = z = 5;
	int arr[x][y][z];

	for (int i = 0; i < x; ++i)
		for (int j = 0; j < y; ++j)
			for (int k = 0; k < z; ++k)
				arr[i][j][k] = i + j * 10 + k * 100;

	print_arr (x, y, z, arr);
}

На расте пишешь только ты, если это не так предоставь мне точное число растеров.

Какая разнца что использует лоровец? Рынок требует жабу.

Захотелось человеку ООП в сишке, ну вот ему ООП. Чего такого-то?

Любителям изобретать велосипед на каждый чих не помочь.

Бремя доказательства лежит на утверждающем. ©

у меня была такая тема по мотивам какой-то статьи Очистка памяти после создания двумерного «непрерывного в памяти» массива

там есть пример для непрерывного двумерного динамического массива для C размерностью n*n. Переделать его для трёхмерного руки не доходят. Дело в том, что при традиционной инициализации динамических многомерных массивов (как массивы указателей на массивы указателей), они не обязаны быть непрерывными в области памяти, именно поэтому они обычно создаются в C и C++ как линейные. Это нужно потому, что, например, библиотеки линейной алгебры в качестве аргументов могут использовать только массивы непрерывно расположенные в памяти.

Почему бы тебе тогда лисп не использовать?

Проблема Python в этом случае заключается в неэффективном использовании ресурсов.

И Fortran с OpenCL обходятся в 0 баксов. При этом без CUDA, которая нужна только совсем неумным людям, не сможет стеснять в выборе железа и платформы.

Какая разнца что использует лоровец? Рынок требует жабу.

Рынок иногда такую херню требует, что фэйспалмами можно синяков наделать. Раньше похапе и флеш требовал, теперь вот node.js или что там нынче модно.

Любителям изобретать велосипед на каждый чих не помочь.

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

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

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

Да, только тот же tensorflow не поддерживает OpenCL.

VLA - это C99; в С11 они опциональны. Напиши это на стандартном С89, без расширений.

Программисту нужно ООП? Пишет #addon «OOP».

Программисту нужна программа? Пишет #addon "программа".

Ну это плюсплюс тут выступает велосипедом

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

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

Оно там с рождения завелось, что-ли? :) Если ты не в курсе, то С++ сначала назывался «C with classes».

Так что да, именно С++ таки велосипед произошедший напрямую от С, а не наоборот. Даже само название об этом говорит.

Вы явно потеряли нить разговора.

Вы явно потеряли нить разговора.

Вы явно переоцениваете ООП вообще и C++ в частности. Пока не изобретут новую архитектуру реальных железных процессоров, всё это ООП всего лишь синтаксический сахар над банальным C/asm.

Как будто что-то плохое.

И назови же мне хоть одно жабоприложение, которое ну хотя бы 70% лоровцев используют у себя на линуксах.

ЛОР.

Пока не изобретут новую архитектуру реальных железных процессоров, всё это ООП всего лишь синтаксический сахар над банальным C/asm.

Семантический сахар. И кстати, сам Си - тоже семантический сахар над ассемблером.

всё это ООП всего лишь синтаксический сахар над банальным C/asm.

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

Я начал понимать куда вы клоните, но не понимаю зачем отказываться от нового стандарта, у которого хорошая поддержка среди популярных компиляторов, а улучшения по сравнению с с89 не заканчивается на VLA.

не понимаю зачем отказываться от нового стандарта

C11 с опциональным VLA. И какой-нибудь C20 без VLA вообще.

Кроме того, ты серьезно предлагаешь передавать все N размерностей как параметры?