LINUX.ORG.RU

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

 


0

3

Яннис Польман (Jannis Pohlmann), один из основных разработчиков среды XFCE, в своем блоге сообщает о том, что некоторые проекты, являющиеся частью XFCE, нуждаются в разработчиках, которые в дальнейшем смогут обеспечить их поддержку и развитие. Сам Яннис объясняет ситуацию тем, что после получения работы инженера-программиста лично у него остается совсем немного времени на XFCE, при этом он хочет посвятить это время разработке основных элементов среды, в частности thunar, tumbler, garcon и др.

Итак, в поддержке нуждаются следующие проекты:

Янис в первую очередь рекомендует обратить внимание на thunar-media-tags-plugin и xfce4-mixer, так как эти проекты наиболее востребованы как среди аудитории XFCE, так и среди многих других пользователей. В частности, у xfce4-mixer недостает интеграции с менеджерами уведомлений, наличия горячих клавиш для регулирования звука, более удобного GUI-интерфейса. Также требуется интеграция с GStreamer.

Для работы над проектами требуются знания C, GLib и GTK+, к тому же Яннис утверждает, что кодовая база всех проектов не представляет сложностей даже для новичка.

>>> Подробности

★★★★★

Проверено: maxcom ()

Оно не могло бы... того... ? XFce перестал быть нормальным проектом как только тупо скопировал GNOME 2/Windows Explorer, хотя до какого-то момента был вполне самобытным, интересным DE.

DRVTiny ★★★★★
()
Ответ на: комментарий от RPG

А патч, в результате которого в Thunar все новые файлы выделяются ярко-красным цветом

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

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

И сопровождающий не ответит даже на предложенный патч «добавьте галку в настройки, тогда приму патч»? Если нет, то это плохо.

Toll ★★
()
Ответ на: комментарий от Toll

Вот и я, к сожалению, не знаю...
Может кого-нибудь заинтересует - я бы с радостью над таким поработал.

Ubo
()
Ответ на: комментарий от Toll

И сопровождающий не ответит даже на предложенный патч

Один патч был заслан полтора года назад, но тогда не было сопровождающего. Полгода назад один человек взялся, потом пришёл ещё один, но они в основном правили глюки. После всех этих изменений патч перестал применяться. Недавно я обновил патч и послал письмо сопровождающему лично; приняли через 4 часа после письма. Насколько я понял. было примерно так: попробовал, не вышло, забил.

Со вторым было просто молчание. Автор на вопрос «ты вообще патч получал? Я бы очень хотел, чтобы ты на него взглянул» ответил «ага, добавил в todo». И вот уже полгода тишина.

Собственно на этом мой опыт заканчивается.

i-rinat ★★★★★
()
Ответ на: комментарий от RPG

А патч, в результате которого в Thunar все новые файлы выделяются ярко-красным цветом

М-м-м, надо будет в fmd запилить.

baverman ★★★
()
Ответ на: комментарий от red_eyed_peguin

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

farafonoff ★★
()
Ответ на: комментарий от f0b

Язык очень сложно читать - синтаксис очень сложен. На самом деле на этом языке легче писать, чем читать.

Вот даже пример очень простого кода (из дебиана) мы видим кучу разного синтаксиса, @, $, *, какую-то переменную PERL_DL_NONLAZY. На том же С достаточно запомнить пару элементарных синтаксических правил и можно прочитать совершенно любую программу.

BEGIN {
local $ENV{PERL_DL_NONLAZY}=1;
eval 'use Locale::gettext';
if ($@) {
*gettext = sub { shift };
*textdomain = sub { «» };
*LC_MESSAGES = sub { 5 };
}
eval {
require POSIX;
import POSIX qw(setlocale);
};
if ($@) {
*setlocale = sub { return 1 };
}
eval {
require I18N::Langinfo;
import I18N::Langinfo qw(langinfo YESEXPR NOEXPR);
};
if ($@) {
*langinfo = sub { return shift; };
*YESEXPR = sub { «^[yY]» };
*NOEXPR = sub { «^[nN]» };
}
}

farafonoff ★★
()
Ответ на: комментарий от i-rinat

Не нужна альтернатива пользователю. Где-то на хабре пробегала статья про то, что только 5% пользователей меняют дефолтные настройки мсофиса. Сделайте удобно по-умолчанию, а галочки засуньте по-дальше, хоть в конфиги.

farafonoff ★★
()
Ответ на: комментарий от farafonoff

Не нужна альтернатива пользователю. <...> Сделайте удобно по-умолчанию

Удобно - это как? Я не хочу, чтобы файлы красным выделялись, мне это неудобно. А кому-то — жизненно необходимо. И что поставить по умолчанию?

а галочки засуньте по-дальше, хоть в конфиги

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

Вот представь, что ты написал программу для себя. Пользуешься ей, она сделана именно так, как тебе удобно. Со временем появилось много пользователей, их тоже устраивает (иначе бы они не появились). И тут появляется человек, который уверяет тебя, что бегущая строка по контуру окна, нарисованная ядовито-зелёным цветом — это то, чего ему не хватало в твоей программе все эти годы. Он даже присылает патч. Только вот тебе это совсем не кажется разумным, ведь если патч применить, ты сам не сможешь программу дальше использовать. Станешь ты заниматься доработкой конфигурации, написанием обходного кода и прочим или просто забьёшь и будешь ждать, пока это сделает автор патча? А ведь с учётом того, что автор патча считает новое поведение единственно верным, он это не сделает. Никогда.

i-rinat ★★★★★
()
Ответ на: комментарий от farafonoff

На самом деле на этом языке легче писать, чем читать.

А если аналогичную программу написать на си - преимущества, скажем, в скорости выполнения, будут сильно отличаться? Может у языков (си и перл) есть какие-то индивидуальные направленности? Для примера (программист знает 2 языка с одинаковым уровнем владения), захотелось написать простейший аудиоплеер или менеджер сетевых подключений - какому языку с точки зрения простоты синтаксиса, количества строк кода, (что-то еще?) и т.д. он отдаст предпочтение?

f0b
()
Ответ на: комментарий от farafonoff

Язык без встроенной поддержки строк

Лолшто? Ниасиляторы указателей набежали? Как говорит Артемий Татьянович: «Вон из профессии!»

red_eyed_peguin
()
Ответ на: комментарий от farafonoff

3.0 со временем станет главным и все забудут про 2.6

А это ничего, что сейчас уже пистон 3.2 есть, а люди до сих пор на 3.0 не хотят переходить?

red_eyed_peguin
()

ГТК-отстой умирает, вот бида.

Hexs
()
Ответ на: комментарий от densss

Мне нравится Тунар своей простотой, но глядя на его функционал, по сравнению даже с PCManFM (я даже не упоминаю тут Nautilus и Dolphin) становится печально.

Да, автор сам подчеркивает что Тунар должен быть максимально простым. И тем не менее меня в нем все устраивает, кроме вкладок. Но проблему с вкладками я решил путем патча для панели:)

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

Если в панеле-то есть прекрасная панель bmpanel2 там как ты и написал.

Ну я то привык к стандартной панели, к тому же на добавление патча у меня ушло 10 минут, а на поиски нужной мне готовой я бы потратил полчаса да еще и потом бы в ней разбирался и настраивал как нужно.

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

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

Удобно - это как? Я не хочу, чтобы файлы красным выделялись, мне это неудобно. А кому-то — жизненно необходимо. И что поставить по умолчанию?

С красным - это следствие нежелания искать, как сделать лучше, ибо полученный результат окупил неудобства. Раскрашивание иконки было буквально в соседних строчках кода (код, отвечавший за выделение) и я это скопировал. А по-хорошему нужно просто рисовать на иконке лейбл вроде иконки NEW, точно также как рисуется лейбл на иконке, что это ссылка. Многим может вполне пригодиться, а в настройках это убирать тоже можно. По достоинству оценил патч, когда правил несколько версий одного и того же кода: в куче одинаковых файлов легко запутаться и иногда начинаешь править не патч, а оригинал. А когда патч подсвечивается - сразу понятно, что я этот файл недавно редактировал.

RPG
()
Ответ на: комментарий от i-rinat

По большому счету ради этих 5% можно ограничиться #ifdef вместо конфига. Цвета вообще должны браться из дефолтной темы. Например вместо красного какое-нибудь бледное выделение (в теме должно быть такое) Тогда и у людей не вызовет отвращения, и смотреться будет консистентно. Вообще именно к цветокодированию есть самые разные подходы, могу показать скриншот нашей АСУ с пестрыми цветами.

farafonoff ★★
()
Ответ на: комментарий от f0b

Я бы выбрал C# под Швиндошс. - Объясню почему. Нормальный синтаксис (мало знаков препинания, достаточно ключевых слов), нормальная ide, .net встроен в винду - время запуска незаметно. Эффективный jit - отличие от натива незначительно. Нативный gui, полноценный фреймворк. Под линукс такой киллер-платформы я не вижу. Ближе всего имхо подошло Qt, но остатки c++ все портят (нет модульности, ужасно долгая сборка, ужасный синтаксис). Python лично мне не нравится тем, что он динамически типизирован и соответственно никакая ide не может мне подсказать названия и параметры методов. Если пишешь не 8 часов в день на работе, а пару часов в неделю for fun, то заучивать сигнатуры функций и методов не очень приятно. Я вижу применение динамики только для небольших скриптов (в том числе в вебе), для винды - .net, для линукса - qt на десктопе и java на сервере. +если нужна просто кроссплатформенность, то java.

farafonoff ★★
()
Ответ на: комментарий от red_eyed_peguin

В С нельзя строку вернуть из функции, в 21 веке это маразм. (можно конечно вернуть указатель на _подстроку_, тогда вызывающий должен знать что это именно указатель на подстроку; еще можно вернуть область памяти выделенную malloc, но тогда нельзя это запихивать в разделяемые библиотеки.) Про неосиление указателей скажи разработчикам ядра линупс, там постоянно выковыривают локальные эксплойты, основанные на переполнении буфера.

farafonoff ★★
()
Ответ на: комментарий от RPG

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

farafonoff ★★
()
Ответ на: комментарий от farafonoff

farafonoff, RPG, я, видимо, слишком запутанно использовал тезис про красный цвет файлов. Суть не в цвете. Суть в том, что конечное решение принимает автор, а не пользователь. Вот такой эгоизм.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Так его и должен принимать автор. По ходу разработки программы отбрасывается миллион вариантов, которые в конечном итоге отличают thunar от explorer.exe, nautilus и dolphin. Если для каждого отброшенного варианта вводить галочку в настройки - ничего хорошего не выйдет.

farafonoff ★★
()
Ответ на: комментарий от farafonoff

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

75% уже есть, а 100% ждать нет смысла, там и С99 до сих пор на 100% не поддерживается

anonymous
()
Ответ на: комментарий от anonymous

Ну вот ты и ответил себе. Учти еще, что эти 75% там чисто формально (недавно мне показывали баг когда gcc падал при вычислении сложного шаблона). Мэйнстрим всегда отстает от bleeding edge на 3-4 года - это совершенно нормально.

farafonoff ★★
()
Ответ на: комментарий от farafonoff

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

это неверно. Разделяемые библиотеки проецируются в пространство процесса, а значит и malloc из библиотеки вернёт указатель куда-то в кучу приложения. У библиотек своего адресного пространства нет. Пример: g_string_new и g_string_free из glib.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Зато возможны свои реализации malloc. В винде такие проблемы более вероятны, но и в линуксе есть _любители_выделять_память_из_пула_

farafonoff ★★
()
Ответ на: комментарий от farafonoff

но и в линуксе есть _любители_выделять_память_из_пула_

Это тоже не важно. Ещё раз — есть центральное понятие — процесс. Разделяемые библиотеки — это код и статические данные. Стек и куча принадлежат процессу, а не библиотеке. Библиотеке вообще никакого процесса не соответствует. malloc, кстати, реализуется в библиотеке libc, которая с большинством программ связывается динамически.

i-rinat ★★★★★
()
Ответ на: комментарий от farafonoff

Работа программиста похожа на работу скульптора - надо отсечь все лишнее.

Это работа архитектора. Работа программиста — сделать число трамвая больше единицы.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Если память выделена из пула - чем ты ее будешь высвобождать? free тупо упадет. Если я могу обменять 0.1% производительности компьютера на отсутствие такого геморроя - я это сделаю. Управляемые языки - мой осознанный выбор.

farafonoff ★★
()
Ответ на: комментарий от i-rinat

В опенсорсе нету архитекторов. Все опенсорсные проекты похожи на кучу слепленного говна. Посмотри на монолитное ядро линукс, монолитный компилятор gcc, монолитный mplayer. Все проекты с архитектурой которые я знаю начинались как проприетарные или замена проприетарным - даже unix проприетарен.

farafonoff ★★
()
Ответ на: комментарий от farafonoff

Если память выделена из пула - чем ты ее будешь высвобождать?

Ты пытаешься троллить? Кто владеет пулом? Другой процесс? Как получить доступ к памяти другого процесса без IPC?

Управляемые языки - мой осознанный выбор.

Ок, только не надо проецировать картину мира «вид из окна управляемых языков» на C.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Зачем IPC? Ты не знаешь как работает malloc? над адресным пространством есть еще куча, из которой malloc и выделяет память, причем делает это не эффективно: время работы malloc и free в общем случае непредсказуемо.

http://en.wikipedia.org/wiki/C_dynamic_memory_allocation#Implementations

Почитай про разные реализации. Если malloc пришел из одной библиотеки, а free из другой - получишь сегфолт.

Ок, только не надо проецировать картину мира «вид из окна управляемых языков» на C.

Когда в ядре (и всех остальных программах на С) перестанут находить уязвимости типа переполнения буфера и разыменование нулевого указателя - я с радостью поверю что человечество дозрело до повсеместного применения указателей.

farafonoff ★★
()
Ответ на: комментарий от farafonoff

монолитное ядро линукс

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

монолитный компилятор gcc

никогда не видел его кода

монолитный mplayer

вроде довольно неплохо структурирован

начинались как проприетарные или замена проприетарным

Это ты сейчас всё пространство покрыл. Вообще всё, ибо первые программы были проприетарными

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

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

Монолитное. Почитай про разницу между монолитом и микроядром. Когда к линупсу приделают стабильный API хоть в одной подсистеме, я поверю в «архитектуру».

> монолитный компилятор gcc

никогда не видел его кода

Он ужасен. Достаточно того что gcc собирается только gcc строго определенных версий.

монолитный mplayer

вроде довольно неплохо структурирован

Зато монолитен. Даже кодеки надо вкомпиливать заранее.

начинались как проприетарные или замена проприетарным

Это ты сейчас всё пространство покрыл. Вообще всё, ибо первые программы были проприетарными

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

farafonoff ★★
()
Ответ на: комментарий от farafonoff

Если malloc пришел из одной библиотеки, а free из другой

Сомневаюсь, что две библиотеки, экспортирующие каждая по malloc и free, вообще слинкуются с одним бинарником. Статически — точно не слинкуются; динамически — не проверял

над адресным пространством есть еще куча

Ты это серьёзно? Если адресное пространство у каждого своё, как могут пересекаться кучи?

время работы malloc и free в общем случае непредсказуемо.

а сборщик мусора предсказуем, ага. Ой, что это за глитч? Пришло время собирать мусор!

перестанут находить уязвимости типа переполнения буфера

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

Уязвимости в .NET тоже регулярно исправляют, кстати говоря.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Сомневаюсь, что две библиотеки, экспортирующие каждая по malloc и free, вообще слинкуются с одним бинарником. Статически — точно не слинкуются; динамически — не проверял

функции могут называться по-разному, например mymalloc(). Возвращает-то она все равно свой указатель.

Ты это серьёзно? Если адресное пространство у каждого своё, как могут пересекаться кучи?

Ты не на то отвечаешь. Я говорю про случай когда в одном адресном пространстве сосуществуют разные кучи.

а сборщик мусора предсказуем, ага. Ой, что это за глитч? Пришло время собирать мусор!

Честно - ни разу с подобным не сталкивался. Зато сталкивался с проседанием производительности C++ при работе с большим количеством коротких строк - пришлось приделывать свой аллокатор памяти.

Уязвимости В .net - возможно. Сам он написан на неуправляемом языке C++. А вот программы на нем крайне надежны по определению. Надо очень постараться, чтобы сделать такую программу уязвимой (особенно учитывая наличие всяких linq, которые делают sql запросы типизированными)

farafonoff ★★
()
Ответ на: комментарий от farafonoff

Почитай про разницу между монолитом и микроядром

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

Он ужасен. Достаточно того что gcc собирается только gcc строго определенных версий.

Так имеет право говорить только человек, который доделывал или исправлял код. Иначе про любой код можно сказать, что он ужасен, только на том основании, что ты в нём не разобрался. Многие программы собираются только определёнными версиями компиляторов.

Зато монолитен. Даже кодеки надо вкомпиливать заранее.

Снова. Монолитность бинарника ничего не говорит об архитектуре. Код структурирован. Внутри каждого модуля можно абстрагироваться от окружающего кода. Там есть некое подобие API, оно меняется, но оно есть.

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

Я не буду отыгрывать роль пропонента опенсорса. Открой код любого сложного проекта, там та же фигня.

i-rinat ★★★★★
()
Ответ на: комментарий от farafonoff

функции могут называться по-разному, например mymalloc(). Возвращает-то она все равно свой указатель. Ты не на то отвечаешь. Я говорю про случай когда в одном адресном пространстве сосуществуют разные кучи.

Я объединил фразы, они явно про одно и тоже. Скажу так — я беспокоюсь за психическое состояние человека, который способен в программе делать вызовы jack_malloc для выделения памяти и jane_free для освобождения. Уж либо одно, либо другое. Не надо выбор аллокаторов преподносить как недостаток. Если программист желает выстрелить себе в ногу, у C/C++ нет никаких возможностей этому помешать.

А вот программы на нем крайне надежны по определению

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

А вот про сами программы я бы так не сказал. Отстой можно написать на любом языке. Выстрелить в ногу уже нельзя, зато можно залить соседей, они придут и прострелят ногу за тебя.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

К ядру линукса нельзя приделывать модули после компиляции (очень строгие требования по версии и флагам компилятора) То что они сделали динамический линковщик не делает его модульным.

Просто посмотри на винду. Однажды скомпиленную бинарную систему можно наращивать драйверами, программами и службами в течение 10 лет.

farafonoff ★★
()
Ответ на: комментарий от i-rinat

Вот тебе пример. есть функция char* translate_message(char* msg). Лежит она в моей библиотеке, а я забыл написать что ты должен сделать с полученным указателем. Как будет выглядеть ее вызов?

Одну виртуальную машину отладить несколько проще, чем целый стек программ написанных на С программистами разного уровня и квалификации.

farafonoff ★★
()
Ответ на: комментарий от farafonoff

К ядру линукса нельзя приделывать модули после компиляции (очень строгие требования по версии и флагам компилятора) То что они сделали динамический линковщик не делает его модульным.

dkms

Просто посмотри на винду. Однажды скомпиленную бинарную систему можно наращивать драйверами, программами и службами в течение 10 лет.

Почему у меня драйвера от XP не работают в 7? И где твои 10 лет?

программами и службами

программы и службы? А причём тут ядро? Программы, скомпилированные во времена 0.9 работали и в 2.6, внешний интерфейс ядра не менялся кардинальным образом. Поэтому программы просто работают, даже те, которые были скомпилированы в 95-м году. А вот с выходом висты многие программы получили облом, в program files оказалось файлы записывать нельзя. А у GNU за это время иерархия ФС почти и не поменялась.

Однажды скомпиленную

вот именно, что однажды. Уже ничего серьёзно не поменять в ядре. Да они ничего и не хотят менять. Как драйвер NTFS создавал жуткую фрагментацию во времена 2000 и XP, так и в семёрке он делает то же самое. Я сомневаюсь, что они его вообще трогали — страшно, наверное.

i-rinat ★★★★★
()
Ответ на: комментарий от farafonoff

Вот тебе пример. есть функция char* translate_message(char* msg). Лежит она в моей библиотеке, а я забыл написать что ты должен сделать с полученным указателем. Как будет выглядеть ее вызов?

Если это твоя библиотека, то ты написал говно. Ибо библиотека без документации бесполезна. Если же мне _очень_ надо пользоваться именно твоей библиотекой, я сделаю так: освобождать память не буду, прогоню программу через valgrind. Найдёт утечку — поставлю free, не найдёт — оставлю как есть. Уже был такой опыт.

Одну виртуальную машину отладить несколько проще, чем целый стек программ написанных на С программистами разного уровня и квалификации.

Чего ж тогда уязвимости всё ещё находят? Проще — не значит, что это сделают. И учти, что если за год вышли исправления 6 уязвимостей, это не значит, что было найдено 6 уязвимостей.

i-rinat ★★★★★
()
Ответ на: комментарий от farafonoff

есть функция char* translate_message(char* msg). Лежит она в моей библиотеке

а несколько сообщений назад ты утверждал, что такое вообще невозможно (вернуть строку из библиотечной функции)

i-rinat ★★★★★
()
Ответ на: комментарий от farafonoff

В С нельзя строку вернуть из функции, в 21 веке это маразм.

Маразм у тебя в голове. man apr_pstr(n)dup. Ни в одном языке нет такой удобной работы со строками, как в C при использовании libapr.

red_eyed_peguin
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.