Проектам из состава среды XFCE требуются разработчики

Когда в gcc на 100% реализуют С++11 - приходите ко мне в дом престарелых, помянем былое.

Причем здесь реализация нового стандарта? Над проблемой обратной совместимости в серьезных проектах задумываются. А в школоло-пистоне, конечно же, ломают эту самую совместимость при каждом удобном случае, ведь на нем не пишут ничего серьезного. Так, язычок «for lulz» (даже на for fun не тянет).

Спасибо. И не один ты смеялся :D

dkms это костыль. Сменится минорная версия компилятора - dkms умрет.

Огромная часть драйверов работают и на 7 тоже. Кроме того, 10 лет уже прошли.

Винда это операционная система, а 2.6 это ядро. Запусти программу из 3 дебиана в 6, и удивись, сколько либ разбежались (тот же питон :))

Меня устраивает драйвер ntfs. Как ХР стояла 6 лет, так и 7 уже полтора года стоит. Производительность устраивает.

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

В ядре линукс ломают обратную совместимость. Веселее того, ядро 2.4 ты не соберешь гцц 4 версии - вот такая поломка обратной совместимости.

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

Я просто не считаю что работа со строками вообще является существенной частью документации для прикладной библиотеки. И да, я считаю что valgrind это костыль, который прикрывает несовременность языка С.

Про уязвимости это ваша фраза - не моя. Я сейчас поискал, не могу найти ничего свежее какой-то баги в криптографии asp.net 2010 года. Сейчас я чаще наблюдаю ботнеты из линуксовых серверов на необновленном редхате, чем с виндовых машин.

Конечно невозможно. Это возврат не строки а указателя на char. Из самой этой функции непонятно, что с ним можно сделать.

Это вопрос с подвохом

Корректный прототип этой функции будет

int translate_message(char* msg, char* result, size_t result_size);, возвращающая код ошибки если результат длиннее result_size Согласитесь, string translate_message(string msg) короче и понятнее.

Я просто не считаю что работа со строками вообще является существенной частью документации для прикладной библиотеки. И да, я считаю что valgrind это костыль, который прикрывает несовременность языка С.

Отличный пример мышления «я этого не понимаю, значит это не нужно».

«Рассмотрим эти задачи подробнее. #1: Перевернуть строку на месте. Каждый кандидат, с которым я общался, сперва делал это неверно. Все без исключения пытались разместить буфер и переворачивать строку в этом буфере. Вопрос, кто размещает буфер? И кто его освобождает? Задавая этот вопрос множеству кандидатов, я обнаружил любопытную вещь. Большинство людей, думающих, что они знают С, на самом деле не понимают памяти или указателей. Это до них просто не доходит.»

Я сейчас поискал, не могу найти ничего свежее какой-то баги в криптографии asp.net 2010 года.

google://kb2484015

Запусти программу из 3 дебиана в 6, и удивись, сколько либ разбежались (тот же питон :))

Я собрал и запустил программу на android, причём программа была собрана под gnu. У них даже интерпретаторы отличаются, ан нет же, запустил и она работала.

Меня устраивает драйвер ntfs. Как ХР стояла 6 лет, так и 7 уже полтора года стоит. Производительность устраивает.

Аутотренинг помогает не видеть скорости и времена чтения.

Постоянно следить откуда пришел этот char* и куда он передается?

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

Обращаться с похапистами считаю ниже своего достоинства. Можешь не пытаться дальше толстить в мою сторону.

hello world запустил? радуйся. Что-то более менее сложное обычно сильно зависит от окружения и нуждается в портировании.

Фрагментация растет не сильно быстрее чем в ext3, если следовать общеизвестному совету - держать 30-40% раздела свободными.

Ололо-школоло, кроме пхп языков не знаем? .net-java-python-c++ - в порядке предпочтения.

Я прекрасно понимаю указатели. Я не могу понять причину, которая вынудит меня писать высокоуровневый код на С. В крайнем случае я использую хотябы С++. Любители порассуждать про указатели видимо не знают, что неизменяемые строки в явах и дотнетах дают потокобезопасность, при том что каждый захват блокировки будет стоить дороже чем разворот строки. Если уж мне так нужно будет сделать _самый_быстрый_поворот_строки, я воспользуюсь char[].

hello world запустил? радуйся.

спасибо

Фрагментация растет не сильно быстрее чем в ext3, если следовать общеизвестному совету - держать 30-40% раздела свободными.

Вот тебе test-case: создаёшь новый раздел, гигов на 20-30. Копируешь туда две копии system32, потом удаляешь все dll-ки. Занято будет при этом не больше трети раздела. Записываешь файл около 400 метров со скоростью примерно 1 Мб/c. Смотришь на число фрагментов и как они по диску распределены. Потом делаешь то же самое на ext3. Сравниваешь результат.

net-java-python-c++

Ты, наверное, хотел сказать

говно-моча-пионерия-c++

Так, чисто чтоб ты думал в следующий раз, когда непонятные слова копипастить будешь, .NET — это не язык. Это платформа, на основе которой существует множество языков, в том числе и твой любимый пестон, и любимый троллями-которых-здесь-уже-нет lisp.

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

Да ты шо! Нобелевку товарищу farafonoff!!! Оказывается, проектирование потокобезопасных приложений зиждется всего лишь на одном приеме: неизменяемость строк. Сделал все строки неизменяемыми и сразу подебил!

Кстати, не подскажешь, а почто в жабке StringBuffer придумали?

Я не могу понять причину, которая вынудит меня писать высокоуровневый код на С.

Быдлокодерам не понять, что иногда люди делают что-то из любви к искусству™. Кто-то виртуальные машины на жабоскрипте пишет, а кто-то «высокоуровневый код на C».

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

К сожалению сейчас не располагаю нужными ресурсами для проведения данного теста.

На .net есть только два по-настоящему мейнстримовых языка - VisualBasic и C#. Отличаются только синтаксисом, я предпочитаю второй.

Сейчас я не вижу альтернатив управляемым языкам для десктопной разработки. Может быть ты подскажешь?

Строки покрывают 90% всех данных, которые обрабатывает типичная программа, так что грамотная их реализация упрощает программы на те же самые 90%.

StringBuffer не использовал никогда, куда чаще приходится использовать StringBuilder, а то и просто String.format()

Я думаю 90% потребностей успешно покрывает класс String, 90% оставшихся - StringBuilder, а на долю StringBuffer приходится не более 1% всех юзкейсов.

Код на С я бы не назвал высокоуровневым. Посмотри на любой код - там смесь макросов, void* - кастов и обработки ошибок.

«Освобождение ресурсов» - типичный прием троллинга. 99% всех ресурсов - память, а оставшиеся ресурсы (обычно только сокеты и файлы) можно высвобождать в блоках finally.

Сейчас я не вижу альтернатив управляемым языкам для десктопной разработки. Может быть ты подскажешь?

Судя по тому, что все окружение, что я использую, написано на C++ или на C, ответ довольно очевиден.

Посмотри на любой код - там смесь макросов, void* - кастов и обработки ошибок.

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

«Освобождение ресурсов» - типичный прием троллинга. 99% всех ресурсов - память, а оставшиеся ресурсы (обычно только сокеты и файлы) можно высвобождать в блоках finally.

Нет, типичный прием троллинга — это сказать, что главное — освободить память, а с остальным можно и ручками легко разобраться. Почему бы было не пойти дальше и не сказать, что любой сокет и файл в конце-концов является своеобразной ссылкой на некоторый внутренний ресурс операционной системы, расположенный в памяти, поэтому управление файлами и сокетами является синонимом управления памятью, а на решении такого рода проблем как раз и специализируется GC. Честное слово, я бы не удивился, услышав от тебя подобное заявление.

куда чаще приходится использовать StringBuilder

Whatever. Суть одна: сначала для простоты мы придумываем неизменяемые строки, а потом начинается наворачивание хрупкой системы костылей, позволяющей обойти дичайшую потерю производительности, возникающую при необходимости эти константные строки изменять.

Я думаю 90% потребностей успешно покрывает класс String, 90% оставшихся - StringBuilder, а на долю StringBuffer приходится не более 1% всех юзкейсов.

90% + 90% + 1% =181% — неплохая арифметика. Тут президентские выборы на носу, подобные люди будут весьма востребованы при подсчете голосов. Отличный, кстати, повод бросить программирование, предрасположенности к которому ты, судя по всему, лишен.

Настала пора разобраться, что именно ты хочешь доказать. Сформулируй тезис(ы).

Я тебя удивлю, но посмотри например pthread api (void*), или bsd sockets (явное приведение структур, макросы). Это стандарт кодирования на С.

Я тебя наверное еще раз удивлю, но gc умеет собирать и файлы и сокеты, просто делает он это в непредсказуемые моменты времени. Если предсказуемость не нужна можно и не освобождать руками, все уйдет само, а если нужна, то это никак автоматически не разрулить.

Хрупкая система костылей - это memcpy/memmove, strNcpy и прочие. А StringBuilder - вполне нормальный способ собирать строку заранее неизвестной длины. btw, предложи свое решение на C. Варианта будет два - либо посчитать длину строки заранее, или использовать realloc. И то и другое создает накладные расходы (сюрприз) и усложняет код в разы.

читать ты тоже не умеешь.

90% ОСТАВШИХСЯ.

Тезис: Архитектура==стабильный api, это просто когда ничего не ломается. Не верю что разработчики сбегутся поддерживать полумертвый проект на С просто так. Я думаю что такие поделки как DE и WM делают либо настоящие фанаты своего дела, либо за деньги. Фанат на xfce не придет, потому что у фаната уже есть свой WM.

Архитектура==стабильный api

http://ru.wikipedia.org/wiki/Архитектура_программного_обеспечения

Первое определение — калька с англоязычного, в английской вики есть ссылка на источник. Там нет упоминания зависимости от времени, а понятие стабильности со временем связано неразрывно.

Если не читал http://linux.oneandoneis2.org/LNW.htm , советую прочитать. Там хорошо изложено, почему стабильного API в FOSS ожидать бессмысленно.

Я тебя удивлю, но посмотри например pthread api (void*), или bsd sockets (явное приведение структур, макросы). Это стандарт кодирования на С.

Твоя хрупкая психика пошатнулась от встречи с реальным миром, где (о ужас!) все высокоуровневые данные оказались просто-напросто массивами байт? Действительно, лучше было забубенить lpMegaUniversalSockAddr с тысячей ненужных полей в духе winapi, чем сделать простой и внятный интерфейс?

В pthread, кстати, void* только в качестве аргумента и возвращаемого значения рабочей функции потока.

Я тебя наверное еще раз удивлю, но gc умеет собирать и файлы и сокеты, просто делает он это в непредсказуемые моменты времени.

Ты меня ни капли не удивишь. О жабковских финализаторах я впервые прочитал, пожалуй, когда твоих дотнетов и в проектах не было. Я рад, однако, что ты понимаешь, что для управления многими видами ресурсов нет ничего лучше старого доброго ручного метода. В этом отношении плюсы — идеальный инструмент: RAII позволяет облечить ручное управление ресурсами, в то время, как указатели позволяют в точности управлять временем жизни объекта, не накладывая никаких ограничений на семантически области видимости переменной, этот объект представляющей.

А StringBuilder - вполне нормальный способ собирать строку заранее неизвестной длины.

Скажи, а ты на полном серьезе считаешь, что твой любимый StringBuilder обходится без realloc (в жабке твой realloc — это new[] + copy)?

И то и другое создает накладные расходы (сюрприз) и усложняет код в разы.

Ты не поверишь, но я писал свой string_buffer и ощущал себя сухо и комфортно, вызывая string_buffer_strcat и string_buffer_add_printf. Более того, не вижу никакой сложности в реализации этих функций.

Может и обходиться. Читал про rope? В этом и заключается суть программирования - абстрагировать пользователя от деталей реализации. Мне достаточно знать что StringBuilder работает за amort. O(n).

Я и говорю - усложнение кода в разы. Вместо того чтобы взять и пользоваться ты навелосипедил свой 100000 стрингбуффер. Знаешь сколько я таких повидал? и ведь ни один не лучше других, просто свои.

Да - лучше сделать lpMegaUniversalSockAddr, чем char[14]//оставим на будущее, 14 байт точно хватит всем и навсегда.

RAII не очень дружит с обработкой ошибок (что будет если образуется ошибка при освобожнении ресурса?) В С++ все было бы не так плохо, если бы вместо 100500 авто-слабых-умных-scoped-shared указателей был один, встроенный в язык на уровне синтаксиса. Плюсы - ужасный инструмент для любой задачи. бесконечные pimpl, конструкторы и деструкторы, и автопоинтеры, служащие одной только цели обходить проблемы языка - это ужасужас. Я пробовал писать на С++ - забубенишь десяток классов, для каждого напишешь pimpl, копирующие конструкторы, конструкторы с кучей разных параметров, деструкторы для всего этого - и кажется что день прожит не зря. А посмотришь как продвинулось решение задачи - никак.

Может и обходиться. В этом и заключается суть программирования - абстрагировать пользователя от деталей реализации.

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

Вместо того чтобы взять и пользоваться ты навелосипедил свой 100000 стрингбуффер

Тю, делов-то! Линус вообще DVCS навелосипедил, и ничего, куча народа пользуется.

К слову о велосипедах: для C существует огромное количество библиотек, а для плюсов есть готовая библиотека абсолютно на любой случай жизни. Что примечательно, сишные и плюсовые библиотеки, как правило, работают. А вот для диалектов вайтспейса вроде питона можно легко найти десяток неработающих (или кривых до ужаса) библиотек, так что велосипедить в ЯВУ приходится не шибко меньше, чем в ассемблероподобной сишке.

RAII не очень дружит с обработкой ошибок

Замечательно дружит.

что будет если образуется ошибка при освобожнении ресурса

Очевидно, что ошибку надо обработать.

В C++ все было бы не так плохо, если бы вместо 100500 авто-слабых-умных-scoped-shared указателей был один, встроенный в язык на уровне синтаксиса.

Категорически не согласен. Профессиональный инструмент именно гибкостью и отличается от любительской поделки.

Плюсы - ужасный инструмент для любой задачи.

Очевидно, ты не умеешь их готовить.

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

Плюсы — инструмент для профессионалов. Любителям он неподвластен.

Для плюсов-то? Большая часть библиотек которые я видел написаны на С. Это значит что например к питону они приделываются автоматически, а вот для С++ приходится писать классы-обертки которые завернут char* и void* в RAII.

Что-то я не видел никого кому бы они были подвластны. Все программы на С++ которые я видел падают и текут памятью - тот же фаерфокс или опенофис посмотри.

Большая часть библиотек которые я видел написаны на С. Это значит что например к питону они приделываются автоматически

Тоньше надо! Пистон, как и прочие ЯВУ требуют написания обертки, особенно когда дело доходит до сложных типов. А в плюсах любой сишный код доступен сразу.

Это твое заявление, кстати, отлично показывает низкий уровень знакомства с пистоном и плюсами.

Все программы на С++ которые я видел падают и текут памятью - тот же фаерфокс или опенофис посмотри.

У тебя, видимо, плохая карма. Лично у меня никаких проблем с FF.

Фаерфокс уже не течет памятью? А разработчики-то не знают, что-то там еще отлаживают, оптимизируют.

Фаерфокс уже не течет памятью?

Где? Открыл iceweasel, походил по linux.org.ru.

==3051==    definitely lost: 0 bytes in 0 blocks
==3038== 4 bytes in 1 blocks are definitely lost in loss record 13 of 27
==3038== 4 bytes in 1 blocks are definitely lost in loss record 14 of 27
==3038== 4 bytes in 1 blocks are definitely lost in loss record 15 of 27
==3038== 4 bytes in 1 blocks are definitely lost in loss record 16 of 27
==3038==    definitely lost: 16 bytes in 4 blocks

Я поверхностно погуглил, но не нашёл веб движка на .NET. Они вообще есть?

internet explorer контрола там за глаза. Браузеры - штука инертная, лет через 10 может и напишут.

internet explorer контрола там за глаза. Браузеры - штука инертная, лет через 10 может и напишут.

Это ты нападал на FF, приводя его как пример проекта на неуправляемом языке и бросаясь обвинениями в протекатии памяти. Я провёл тест, далеко не полного покрытия, конечно, но тест. И не нашёл протекания. А сейчас ты пишешь, что веб движок на .NET не нужен, ибо «internet explorer контрола там за глаза». Некрасиво.

У меня к тебе вопрос общего характера. Зачем ты пришёл на этот форум? Ты не открыл ни одной темы, значит не за помощью и не поделиться. Доказать, что GNU/Linux не нужен и должен быть стёрт с лица земли? Ты постоянно пытаешься смешать Linux и всё, что ним связано, с говном. Зачем тебе это? Здесь кто-то принуждает тебя его использовать?

Я всего лишь пытался тебе доказать, что и у C сейчас есть применение, а ты из кожи вон лезешь, доказывая, что он не нужен. Я почитал твои сообщения в других темах, и большинство из них сводится к «не нужно».

В Debian порядка 30 тысяч пакетов, у меня установлено около трёх тысяч. Это значит, что 90% не нужны мне лично. Но будет глупо кидаться на пользователей, которые пользуются чем-то, чем не пользуюсь я, с криками «не нужно, твои программы отстой». Они пользуются, значит их устраивает.

Я пользуюсь параллельно виндой и линуксом (и по работе, и в быту), и меня сейчас волнует ровно один вопрос по линуксу. Мне нужна нормальная платформа для разработки программы. Есть корпоративное приложение на дельфи, собираемся переписывать под линукс. Что может нам предложить мир опенсорса: Java - GUI тормозит и выглядит убого и ненативно, Qt - убогая поддержка работы с бд (даже по сравнению с дельфи), динамические языки не рассматриваются. От переписывания на .net удерживает только отсталое состояние mono.

Qt - убогая поддержка работы с бд (даже по сравнению с дельфи)

Это чего там убогого-то? Наоборот, там вменяемая концепция драйверов.

В Delphi, как только ты отходишь от хеллоуворлдов, и требуется эффективная работа, для каждой СУБД приходится тянуть свою библиотеку компонентов, к которой в итоге оказывается пришита прикладная программа. Отличный пример - Direct Oracle Access, который работает просто замечательно по сравнению со стандартными дельфёвыми средствами. Но как только перед разработчиками набыдлокоженного встаёт задача работать с разными СУБД, можно отправляться мылить верёвку.

В Qt же нет особой сложности, чтоб один код работал на PostgreSQL и на Oracle. Только за синтаксисом SQL-я придётся послеживать, некоторые вещи таки придётся запихать в условную компиляцию. Отличный фреймворк, мне нравится.

В принципе, если прототип на Delphi, теоретически напрашивается совет покопать Лазарус. Но так как на нём я дальше хеллоуворлдов не ходил, рекомендовать не рискну.

Посмотрите как в дельфи идет работа с бд. Там что-то вроде «статической типизации», таблицы и запросы создаются в режиме редактирования, и на этом этапе проверяются запросы, извлекаются типы полей из базы. В случае Qt пишешь запросы руками (orm там нет и не будет никогда), и если в запросах есть ошибка - найти ее может только интеграционное тестирование. Это как разница между статической и динамической типизацией.

Переносимость между СУБД - миф. Если задача чуть сложнее чем движок форума, вылезают подводные камни с триггерами, хранимыми процедурами, оптимизацией, индексами. Не работал с ораклом, но уверен, что совместимость постгри с ораклом в деталях нулевая, и значит заменой драйвера дело не обойдется.