- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#define SQARESZ 3
void rotateclockwise(char *ptra, size_t sz)
{
char (*a_ar)[sz] = (void *)ptra;
char b_ar[sz][sz];
for (size_t y = 0; y < sz; y++)
{
for (size_t x = 0; x < sz; x++)
{
b_ar[y][x] = a_ar[sz-1-x][y];
}
}
memcpy(a_ar, b_ar, sz*sz);
}
void print_ar(char *ptra, size_t sz)
{
char (*a_ar)[sz] = (void *)ptra;
for (size_t y = 0; y < sz; y++)
{
for (size_t x = 0; x < sz; x++)
{
printf("%i ", a_ar[y][x]);
}
printf("\n");
}
}
int main()
{
char a[SQARESZ][SQARESZ] =
{
{1,2,3},
{4,5,6},
{7,8,9}
};
print_ar((char *)a, SQARESZ);
printf("\n");
rotateclockwise((char *)a, SQARESZ);
print_ar((char *)a, SQARESZ);
printf("\n");
rotateclockwise((char *)a, SQARESZ);
print_ar((char *)a, SQARESZ);
printf("\n");
rotateclockwise((char *)a, SQARESZ);
print_ar((char *)a, SQARESZ);
printf("\n");
rotateclockwise((char *)a, SQARESZ);
print_ar((char *)a, SQARESZ);
printf("\n");
return 0;
}
Ты или крестик сними или трусы надень. Не хочется писать костыли - есть Boost. Не хочется Boost и писать костыли - не знаю, на fortran пиши. Кто вообще сказал что многомерные массивы оттуда должны быть в стандарте.
Люди не создавали время и не знают, что такое время. Это нормально.
Люди создали кучу языков программирования, но не знают, что такое язык программирования.
"Сделать что-то в языке", "сделать стандартными средствами", "сделать кратко и надёжно" и "сделать просто" - разные, порою не пересекающиеся вещи. И даже если вводить термины вроде "стандартная библиотека", "стандартный способ", окажется, что всё равно их никто не будет использовать потому, что они бесполезны.
[1] https://abseil.io/docs/cpp/guides/time
Спасибо, что объяснил. Я так понимаю, сетевого взаимодействия в тоже "Нет в С++"?
https://stackoverflow.com/questions/27126126/why-is-there-a-networking-library-proposal-for-c14-17
Нет, что вы, мы только факториалы в компайл-тайме считаем.
Нет, ведь для этого нужно обращаться к сети, а в C++ этого нет.
а мне надо одного
причем не компиляциюm, а прпрцессироване
https://www.cs.swarthmore.edu/~newhall/papers/cluster11.pdf
Или ты еще хочешь чтоб у тебя несколько процессорных ядер на разных компах одним процессом компилятора захавывались и компилировали один единственный сраный файл говноплюсов? А вот хер тебе! Этого не умеют никакие из известных мне компиляторов. Да и нахер это не нужно, в общем-то.
конечно я этого хочу.
SWAP я могу и на SAN сделать с Fibre Channel, да только почему бы мне тогда локально не поставить 4 терабайта SSD на nvme?
Или думаешь не хватит?
> SWAP
Сдохнет быстро. Лучше под такое дело сделать жесткий диск из оперативы. Была такая хрень, GIGABYTE i-RAM и HyperOs HyperDrive.
лучше уж тада правда по сети
Можешь там SWAP делать себе
Естественно нет. Вот например если ты захочешь на "C++" написать под какую-нибудь нестандартную ОС, под которую сеть будет реализована через какую-то свою, особую, несовместимую ни с чем жопу, то тебе придется через эту жопу делать сетевое взаимодействие.
А написать свой хороший контейнер - уже достаточно нетривиальная задача, чтобы не пользоваться полустандартной библиотекой.
В языке C++ ты можешь легко написать функции, которые будут работать с произвольными типами данных, а не только с char. ну и про malloc() и free() тоже можно будет забыть, за временем жизни будет следить вектор.
https://dev.by/news/intervyu-s-krisom-kasperski-aka-mysch-h
— Как я понял, твой успех был отчасти в том, что все пытались найти общее универсальное решение и впоследствии увязали в нарастающей сложности. Ты же решил узкоспециализированную задачу, зато смог это сделать эффективно и быстро. Немного отвлекаясь от основной темы, здесь мы снова возвращаемся к любимому тобой спору вокруг назначения языков C и C++.
— Каждый конкретный язык определяет мышление, хотим мы того или нет. Так вот, постоянно сталкиваюсь, что «плюсовики» тяготеют к решениям в общем виде, в то время как «сишники» решают задачу в частном виде, что в разы быстрее.
Одну текущую задачу сначала показали «плюсовику», спросив, сколько займёт её решение. Он сказал: «Здесь нужно писать могучий движок. Короче говоря, это проект на полгода». Его коллега-«сишник» поинтересовался: «А зачем?» Ведь поставленная задача укладывается в сотню строк кода! Ответ был ошеломляющим: «Ну и что, мы так и будем по сотне строк кода писать для решения частных задач, каждый раз, как они возникают? Нетушки, задачи надо решать раз и навсегда!».
По моему глубокому личному убеждению, проблемы нужно решать по мере их возникновения. Писать программы на вырост с избыточным универсализмом нужно лишь очень хорошо предварительно подумав, ибо это из серии «Почему сегодня не делают корабли, летающие к звёздам?» Ответ прост: потому что корабль, построенный завтра, прибудет быстрее, а корабль, построенный послезавтра, еще быстрее. И их обоих обгонит корабль, построенный лет через пятьдесят, но когда он вернётся обратно, то обнаружит, что у человечества совсем другие проблемы».
Чего такого гарантированно нет в порно?
Совершенно верно. Например в среде "PHP" принято писать код с SQL инхекциями, тогда как в других языках это считается табу
именно так и будем. Вставил очередную ветку в if в 78 местах кода, и нафиг мне эжти ваши движки?
Например, нужно получить имя пользователя № 25580. Я пишу так:
Если вдруг в $_GET['user_id'] придёт не число, то просто выскочит предупреждение, что такокококой-то ключ массива отсутствует. А если бы хранил в СУБД, то была бы инъекция.
ту нам sort, wc, join , вот жэто всё
И найти юзера по шаблону имени можно программой grep!
Через FUSE отображаем базу данных на текстовые файлы и ищем в них грепом, что нужно.
не придумал
Мне нравится твой вариант. Жаль, он не работает если на комптютере более одного пользователя или более одной программы.
но я считаю что в наше время каждый пользователь может позволить себе отдельный комптютер, тк что жэто не проблема
P.S.: Ты забыло раскококошить слово "выскочит".
можно взять mmap и за ммапить в ппамять хоть 77 гигабайт дданных
http://php.net/manual/ru/class.swoole-mmap.php
Признавайтесь, кто написал расширение Swoole!
А с текстовым файлом будет жопа. По-любому придётся сканировать весь файл в поисках переводов строк.
https://pp.userapi.com/c307714/v307714555/1fed/cUQU3A1UMdg.jpg
я за пёрл
Так делает печеньковый монстр.
https://www.youtube.com/watch?v=j6eFNRKEROw
Какое-то вербозное говноИменно поэтому я за "AWK".
Полкило колбасы, москальский салат, пара бутылок шмурдяка?
После него пук очень вонючий
У тебя панкреатит?
Не шуми, спать мешаешь.
Самое время ложиться спать.
Именно так.
давай-ка
уябывай отсюда
програмисты должны не уметь awk
если кто умеет авк -- тот, ясное дело,прыщеадмин для замены картриджей
Как раз в угоду любителей awk, ключ -a включает разбиение на поля в массив @F. Но и без него цикл можно уплотнить:
BODY while(condition) выполняет BODY пока condition true.
Обращение к <> в скококолярном контексте приводит к чтению одной строчки и покладанию ее в $_. А при наступлении EOF оно вернет undef и цикл закончится.
split сплитит $_(так как не указано иное) по паттерну " " (так как не указано иное) и овзвращает лист (если явно не заказать скалярный котекст)
printf получает массив в какачестве аргумента и выводит.
prl охенн
- строковый литерал ' ' в качестве шаблона split эмулирует awk'овое разбиение (отличается от /\s+/);
- цикл while <> таки не завершается, если из файла прочитана строка "0" (в булевом контексте она ложь); например, строка "0" может быть последней перед EOF без "\n"; также ромбик <> может возвращать по одному символу, когда задан размер записи $/ = \1.
Именно поэтому я не за Perl. 🙁
Погодите...
UPD: размер буфера в 6 байт установлен для демонстрации работы олгоритма.
* std::vector<std::vector<int>> (топорный вариант, проверено временем - работает ок-ish)
* std::map< int, std::vector<int> > ( если часто надо переаллоцировать первый уровень )
я в прошлом начал с первого, но закончил std::list<std::vector<int>>, потому что по первому индексу надо было только итерировать (прямое индексировние был не нужен), и надо было добавлять новые строки часто.
на glibc под прыщами, аллокатор как-то хитрожопо соптимизирован, что существенной разницы по расходуемой памяти было почти невозможно померять. может только если размерности в тысячах/миллионах. но мне это было не надо.
Mежду чем и чем разницы? Между одним вектором и N векторами? Так она отличается только на примерно на ~3*N интов.
Существенное отличие не в потреблении памяти, а в кол-ве обращений к аллокатору. Если ты создаёшь один вектор, у тебя будет ровно одна аллокация на всю матрицу. Если ты делаешь вектор/список/мапу векторов, у тебя будет N+1/2*N аллокаций (а в случае списка/мапы ещё и куча мелких объектов). Для числодробилок это может быть важно.
Память лучше выделять редко и большими блоками.
Если тебя устраивает list<vector>, то пирфоманс тебе явно не особо важен.
в курсе. про это не написал - но точно также на линухе никакой существенной разницы не видел.
если конечно в tight loop впихнуть там будет сильно заметно.
но в приложении которое еще что-то делает - это капля в море.
честно говоря самого удивило. колличество аллокаций я поэтому и не мерял - потому что я видел что glibc/stdc++ какую-то магию творит уже на расходе памяти.
на старых системах/старых STL версиях я делал оптимизации std::map/list -> std::vector и видел 2-5х меньше расход памяти и 2х прирост производительности. тест аналогичного кода на линухе - разница была в пределах ошибки измерения.
Доставка по России. Анонимно.
wiistriker@gmail.com
Как минимум тем, что у тебя эта хрень будет хуже кешироваться процессором из-за того, что аллокатор как попало может это дело разбросать. Да и операция взятия конкретного элемента из такого "двумерного массива" будет больше тактов проца жрать
> В C++17 до сих пор нет нормальных многомерных массивов, которые были в Fortran начиная с Fortran 90
У автора статьи - и похоже у тебя тоже - какое-то очень предвзятое понимание как массивы в Фортране работают. (Сам Фортрана не знаю - но было в прошлом несколько коллег которые десятилетия на нем пахали. Народ этот язык сильно переоценивает. Кучи фортранщиков на кресты перешли, к слову, и куча софта на кресты уже спортирована.)
Все недостатки - и достоинтства - той или иной реализации массивов, как ты не крути, в независимости языка, будут присутствовать.
Если ты хочешь размерность массива в рантайм менять - ... со всеми вытекающими.
Если ты хочешь оптимальный кэш футпринт - ... со всеми вытекающими.
Если ты хочешь оптимальную прямую индексацию - ... со всеми вытекающими.
С/С++ тебе позволяет через библиотеку делать как тебе нравится.
На Фортране (и Пасцале, и Лиспе) уже в язык захардкожено.
Wähle Dein Gift.
Отнял у тебя работу. Проверь.
Можно подумать, там сложно либу написать поверх массивов. В крайнем случае FFI.
В Фотртане и Паскале у тебя есть указатели, можешь поверх них свои массивы делать через написание библиотеки (даже без FFI).
Правильно, чтобы ногу с корнем оторвало.
А для чего код в топике? Там же во время компиляции все размеры известны, автор статьи другого хочет.
вай вай
К слову, на 90 градусов очень легко развернуть in-place: транспозиция + отражение дают поворот.
Т.е. к примеру если транспонировать и отразить каждую строку, получишь поворот по часовой стрелке. Если отразить каждый столбец — против часовой стрелки.
А теперь напиши функцию, которая будет вращать матрицу на произвольное кол-во элементов относительно центра.
> вай вай
Пффф...
Как вращать, квадратными кольцами такими?
Написать-то я напишу, только что мне за это будет? Лень мне.
Как что? 80 очков на хакирранке!
Именно поэтому я за S" Forth"
Пример. Возьмём исходный текст:
Чтобы сохранить программу, состоящую из «Отдохнёшь и ты.», нужно отпилить от стихотворения последнюю строчку.
Правда, я пока ещё не придумал, как будет интерпретироваться такая программа.