- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
#include <iostream>
#include <algorithm>
#include <stdlib.h>
const size_t MB = 1024*1024;
size_t MOD = 0;
unsigned char uniqueNumber () {
static unsigned char number = 0;
return ++number % MOD;
}
int main(int argc, char** argv) {
if (argc < 3) {
return 1;
}
size_t BLOCK_SIZE = atoi(argv[1]) * MB;
MOD = atoi(argv[2]);
unsigned char* garbage = (unsigned char *) malloc(BLOCK_SIZE);
std::generate_n(garbage, BLOCK_SIZE, uniqueNumber);
std::sort(garbage, garbage + BLOCK_SIZE);
free(garbage);
return 0;
}
Follow us!
Завязывай
и еще можно было бы поругацца на <stdlib.h> вместо <cstdlib>, но они тут оба не нужны
но согласен с предыдущим оратором, что на хабре приведенный код всегда радует профессионализмом, не только в указанном топеге
Это комментарий автора по поводу качества кода?
у него раковый дельфишный код пускает метастазы, что ничего не влазит
а у тебя, наверное, рабочий монитор 5 дюймов
когда по горизонтали 1920 и больше точек, конечно удобно рассматривать кучно расположенное говно, приклеенное к левому борту - советую вообще отступов не делать, они для слабаков
и ни в коем случае пустые строки нельзя делать, потому что по вертикали надо тоже место экономить
Вот у меня, например, отступы извечно были по 2. И никаких проблем. А избыточное горизонтальное пространство на "мультимедийных" мониторах надо использовать для других полезных целей, а не компенсировать его незаполненность баловством с гулливеровскими отступами.
товарищ страуструп предлагает использовать для отступа 5 пробелов
Особенно, если будет автовыравнивание по :, => и :=, чтобы красивеее смотрелись строки типа
Выравнивать, очевидно, не весь код, а только блок подряд идущих строк, содержащих : или :=
К тому же, накладывает на редактор специфические требования. Что будет с кодом, если его будут править в редакторе без функции автовыравнивания?
Выравнивание будет влиять только на внешний вид, а не на содержимое, как и подсветка, например.
(что будет с подсветкой, если код в ворде перекрасить? Да ничего не будет)
- Что будет, если взорвать атомную бомбу?
- Ничего не будет.... В радиусе нескольких километров.
А код должен быть красив и единообразен вне зависимости от используемых редакторов.
Лишняя сложность не приветствуется.
Так что похер, как что выглядит не в редакторе кода.
Стив Макконнелл тоже.
И объявления типов тоже ровнять удобно.
чему равно x? Лишняя зависимость между строками - большой минус в групповой разработке, ибо всегда найдется уникум, который эту "красоту" сломает. Блин, да у нас в коде по большей части мясо из пробелов и табов, не смотря на гайдлайны. А тут - выравнивание знаков равенства...
А вы всё опять приводите аргументы о том, как неудобно наводить красоту руками.
Троллите?
не уверен, что идея умеет делать такую "красоту" из коробки
Вот ты когда поставить где-то /*, тем самым закомментировалось 100 строк, в ВСЦ же не пишется про каждую, что она изменила цвет на серенький?
потому что код раскрашивает твой редактор. Вот если отступы изменились - файл поменялся, и эти изменения надо трекать. У нас, например, реформат кода ради эстэтики не приветствуется на уровне корпоративного стандарта.
В 100500 раз говорю: выравнивание тоже делается чисто редактором чисто на уровне внешнего вида, никто пробелы в строки на самом деле не добавляет. Так же как и раскраску символов.
Давай, тролль, ещё раз скажи, как неудобно пробелы руками переставлять.
Ну не знаю, идея спорная. Шрифты и цвета - хорошо, фолдинг тоже можно понять, но горизонтальные изменения текста...
Полезность сомнительная. Если тебе очень нужно - напиши плагин. По мне так оно того не стОит. Я предпочитаю больше контроля, всегда включаю подсветку непечатных символов, чтобы видеть, где пробелы, а где - табы.
ДАААА НАКОНЕЦТО:
>> Выравнивание будет влиять только на внешний вид, а не на содержимое, как и подсветка, например.
> Я предпочитаю больше контроля, всегда включаю подсветку непечатных символов, чтобы видеть, где пробелы, а где - табы.
Одно другому не мешает.
Была похожая идея, flexible tabs или как-то так. Все пробельные элементы в коде набирались бы табуляцией, а редактор бы сам по уже расставлял куда нужно. Т.е. в примере выше было бы:
И таким образом проблема с контролем версий решилась бы. Но мне просто не нравится выравнивание по присваиванию, т.как в этом нет никакой семантической нагрузки. Выравнивание по левой стороне, когда это выделяет блок кода несет семантическую нагрузку, например - т.е. помогает понимать код. А связи между двумя присваиваниями как правило нет. Они просто случайно оказались подряд.
Когда структуру описываешь, очень полезно.
Кстати, вот в ColorForth же цвета имели синтаксическое значение. Можно пойти дальше.
если тебе так удобно, это не значит что всем так удобно
4 символа на таб удобны большему числу людей, например
или ты в 80 горизонтальных символов стараешься влезть?
и да, монитор с 1200 по вертикали используется по прямому назначению - написание кода, а стоит он недорого, думаю, любой может себе позволить в 2012 году видеть 60 строк кода нормальным шрифтом, вместо того, чтобы говнокодить на калькуляторах - продуктивности больше
Большинству крестовиков, а не большинству людей.
c, c#, java, javascript, php, python, ... - 4 пробела (линус жаждет 8)
scala, ruby, delphi - 2 пробела
lisp - зависит от структуры кода
в принципе, у дельфи неплохие соседи
Зачем при разработке - а конкретно при кодировании - на С++ видеть список функций и переменных? Функции и переменные бывают членами класса и внешними, + переменные еще локальные/аргументы. Ваш класс пустил столько метастазов, что постоянно путаетесь в десятке методов и паре членов? Вы пишете тело метода такой высоты, что сложно поднять глаза на 10 строк выше и посмотреть имя аргумента - нужен пейджап? Нормальная ide всегда рада подсказать после . -> :: что нибудь полезное, а после ввода 1-2 символов уточнить список практически до 1 варианта.
Когда надо найти функцию/структуру/енум, которая предположительно описана в этом файле - в моей ide всегда можно воспользоваться вверху выпадающим списком с алфавитной сортировкой.
> дерево с папками/файлами
согласен, живёт справа
> REPL
для С++? уточнить чему будет равно 1+2? должно маячить?
> bash
зачем? особенно два. или у вас компиляция не запускается по комбинации клавиш, надо ручками?
> окно с историей
а это зачем? или ваша ide не знает про табы и что можно одновременно несколько документов держать открытыми?
> окно с результатами последней компиляции
пригодно только для перехода к ошибкам компиляции по двойному клику, видеть его 100% времени нет никакого смысла - разве что вы 100% времени только и делаете, как исправляете ошибки компиляции
> книжки
вы пишете код или книжку? вам надо ваш код распечатывать на матричном принтере?
вот то то и оно, что ХЗ
1. Собирается одной командой, но из консоли быстрее. К тому же, часто меняю опции сборки в зависимости от ситуации, в консоли это удобнее (дописал, к примеру, -о и порядок).
2. Некоторые операции с VCS выполняю с cli-клиентом, ибо так быстрее, надёжнее, и есть grep.
3. Логи сервака, запущенного из-под другого пользователя.
окошки баш у тебя встроены в иде? - вместо альттаба в нормальное полноэкранное окно назначаешь специальную комбинацию клавиш из 4-5 кнопок и переходишь в кастрированное 20х30 символов? и да, окошки баш - очевидно, проблема в недоразвитости любой иде в стенах линукс.
Да, баш - в отдельном полноэкранном окне, и при активном девелопменте я им пользуюсь не особо часто.
REPL - чего-нибудь посчитать, да, даже просто какие-нибудь константые значения. 1 + 2 я еще пожалуй в уме смогу, а найти gcd двух четырезначных чисел - вряд ли. ОК, может и смогу, но мне лень.
Я же написал, что для компиляции - отдельный буфер. bash нужен для разных вещей, например, пишу какое-нибудь задание с использованием latex для документации - мне лень специально для этого в .emacs добавлять функцию - проще держать отркытый терминал и когда нужно запускать генератор PDF. Часто бывает нужно отслеживать что делает система во время запуска приложения, (например, чтобы какой-нибудь tail / watch / trace все время бежал и т.п.) И, да, большую часть рабочего времени я компилирую, смотрю, что получилось, и исправляю / добавляю - поэтому мне и нужно видеть результат компиляции. Мне странно что это кому-то кажется странным.
Emacs знает про табы, но история помогает сориентироваться быстрее - я не всегда помню в каком файле что было, да и не хочу помнить - слишком много лишней информации.
Я пишу код для людей, а не для принтеров, матричные принтеры и книги не совместимы... я вообще не понял сравнения. Книги сделаны так, как сделаны потому, что так читать удобно, а не потому, что есть какие-то технические ограничения.
Кроме всего прочего, я печатаю транслитом, и мне влом идти на translit.ru - так у меня еще и буффер для транслитерации есть :P
1. Даже такие тривиальные операции, как обработка аргументов командной строки, зависят от реализации.
2. Соответственно, низкая переносимость, особенно между разными ОС. Если писать не только для себя, пользователю придётся воссоздавать моё окружение или качать тяжёлый исполняемый образ лисп-системы.
3. Недостаточное количество библиотек.
Посему могу заключить, что он CL можно с успехом использовать где-нибудь на веб-сервере, где скорость работы важнее переносимости.
Для повседневных задач более практичным и удобным мне всё-же кажется Clojure.
Кроме того, я это делал больше в целях попрактиковаться - так что там было много смешных вещей, например, был написан скрипт, который во время сборки проекта скачивал какой-то документ из ГуглДокс и на его основе чего-то там генерил :) Это потому что научить секретаршу делать комиты в репозитори оказалось очень затруднительно.
И, вобщем, я собрал систему которая автоматически сидела в чате, обменивалась сообщениями, чего-то там разным сервисам отсылала). К сожалению, я больше над этим не работаю. Для моих задач - хватало за глаза и за уши + переносимость меня не волновала т.как все, вобщем-то, запускалось на моей машине, и, даже если оно бы и запустилось у кого-то еще, никто из сотрудников не сгорал желанием попробовать :)
У нас, кстати, данные для стабов хранятся в svn в экселевских документах (чтобы инженеры по тестированию могли их править) и разбираются джабо-кодом на старте стаб-приложения.
Геморрой начинается при мёрже или попытке посмотреть дифф...
ололо.
Только "раковый дельфишный" при двух пробелах читается нормально, а крестовикам двух уже да, мало.
Но два пробела всё же маловато. При комментировании (// или /*) строка сдвигается. Минимум три.
MOD = atoi(argv[2]);
вернет 0 (ну мало ли, что там в аргах у нас...) - схватит деление на ноль))