The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Опрос Stack Overflow: Rust назван самым любимым, а Python самым востребованным языком, opennews (??), 04-Авг-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


21. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +8 +/–
Сообщение от Аноньимъ (ok), 04-Авг-21, 10:16 
Rust это романтизм 21 века.
Мечта о потерянном идеале. Фантазия идеального кода.
Ответить | Правка | Наверх | Cообщить модератору

43. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +6 +/–
Сообщение от Rev (?), 04-Авг-21, 10:49 
Гуголь заявляет, что 70% всех уязвимостей и ошибок связаны с неправильной работой с памятью. Плюсовики бьют пяткой себе в грудь, что они умеют работать с памятью, но статистика говорит обратное.
Так что такой язык как Раст всё-таки нужен.
Ответить | Правка | Наверх | Cообщить модератору

50. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от myhand (ok), 04-Авг-21, 11:16 
> Так что такой язык как Раст всё-таки нужен.

А что, Python, LISP, Go, <нужное вписать, их легион> (все, что умеет автоматическое управление памятью) - неправильно работают с памятью?

Ответить | Правка | Наверх | Cообщить модератору

59. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +2 +/–
Сообщение от freecoder (?), 04-Авг-21, 11:37 
Это все слишком много мусорит.
Ответить | Правка | Наверх | Cообщить модератору

73. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от myhand (ok), 04-Авг-21, 11:45 
> Это все слишком много мусорит.

А что, в Rust придумали какие-то новые алгоритмы для автоматического управления памятью?

Ответить | Правка | Наверх | Cообщить модератору

90. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +3 +/–
Сообщение от Аноним (90), 04-Авг-21, 12:14 
Да.
Как всегда, раст-хейтеры понятия не имеют, о чем говорят.
Ответить | Правка | Наверх | Cообщить модератору

115. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –1 +/–
Сообщение от myhand (ok), 04-Авг-21, 13:56 
> Да.

Ссылки на публикации в реферируемых научных журналах будут в студии?

Раст-хейтеры не верят в магию.

Ответить | Правка | Наверх | Cообщить модератору

144. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +2 +/–
Сообщение от Конь (?), 04-Авг-21, 15:37 
Если вкратце, то время жизни любой ссылки не должно превышать время жизни того на что ссылается эта ссылка, и в расте эти (и еще куча всего) проверки происходят во время компиляции, а по этому бесплатны с точки зрения производительности.
Официальная документация:
https://doc.rust-lang.org/book/ch04-02-references-and-borrow...
Для тех кто шарит:
https://arxiv.org/pdf/1903.00982.pdf
Ответить | Правка | Наверх | Cообщить модератору

154. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –2 +/–
Сообщение от Аноним (29), 04-Авг-21, 15:57 
Мы знаем
Только бонус это мелкий и слишком дорогой
Ответить | Правка | Наверх | Cообщить модератору

97. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –2 +/–
Сообщение от Аноним (32), 04-Авг-21, 12:53 
>> Это все слишком много мусорит.
> А что, в Rust придумали какие-то новые алгоритмы для автоматического управления памятью?

Конечно же нет. Всего лишь добавили borrow checker, это что-то наподбее надсмотрщика над программистом, который фигурально выражаясь бьет его палкой, если программист использует неодобренные borrow checker'ом конструкции. Технология аппробированная египетскими и советскими фараонами при строительстве пирамид и беломорканалов.

Притом растовский borrow checker достаточно тупой, что не всегда признает синтаксически правильные прогаммы [1]. В этих случаях растовский программист пишет по старинке (с unsafe) со всеми вытекающими следствиями.

В общем Гулаг 2.0 от FAANG.

[1]
https://stackoverflow.com/questions/63437935/in-rust-how-do-...

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

117. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от myhand (ok), 04-Авг-21, 13:59 
Ну да.  Наука-то - не нужна, верно?  Трясти надо...
Ответить | Правка | Наверх | Cообщить модератору

135. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –4 +/–
Сообщение от freecoder (?), 04-Авг-21, 15:04 
> А что, в Rust придумали какие-то новые алгоритмы для автоматического управления памятью?

В Rust нет сборщика мусора, программист должен убирать за собой сам, а компилятор просто проверит, что все чисто. А так как компилятор все равно проверяет чистоту, то в 99% случаев руками убирать ничего не надо - сам компилятор вставит код уборки в нужных местах. И вуаля, мы получаем что-то вроде "статического сборщика мусора".

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

221. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от myhand (ok), 05-Авг-21, 05:01 
> А так как компилятор все
> равно проверяет чистоту, то в 99% случаев руками убирать ничего не
> надо - сам компилятор вставит код уборки в нужных местах.

Сразу видна глубокая наука...  Ну а что будет в 1%?  Компилятор
грязноту не заметит?

> вуаля, мы получаем что-то вроде "статического сборщика мусора".

Тыкву.

Ответить | Правка | Наверх | Cообщить модератору

276. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от freecoder (?), 05-Авг-21, 13:24 
В 1% компилятор не сможет вставить код уборки автоматически и программисту придется написать уборку самому.


Ответить | Правка | Наверх | Cообщить модератору

170. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +2 +/–
Сообщение от Ordu (ok), 04-Авг-21, 16:37 
> А что, в Rust придумали какие-то новые алгоритмы для автоматического управления памятью?

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

Стековой памятью надо управлять так, памятью в куче эдак, причём если копнуть глубже, то и стековой памятью можно управлять по-разному и памятью в куче тоже. Раст позволяет кодировать эти соглашения в API. И проверяет чтобы API соответствовало коду. Причём он проверяет, чтобы реализация API соответствовала бы заявленному в API. И он проверяет, чтобы код, пользующийся API, пользовался бы им так, как требует выбранная стратегия управления памятью.

Вот собственно и всё. Программист затем может использовать любую стратегию управления памятью, которая ему кажется лучшей для задачи, он даже может смешивать эти стратегии произвольно. rustc же просто проверит, что тот не накосячил нигде.

Правда надо понимать, что с такой стратегией управления памятью, как сборка мусора, как-то не задалось. Эта стратегия, была даже в std в до-v1.0 расте, но не сложилось. Сейчас есть попытки запилить gc крейтом, но там пока неясно всё. Правильнее было бы говорить не о попытках запилить, а об исследовании путей к тому, чтобы это сделать. Если интересно можно обзор таких попыток[1] посмотреть.

[1] https://manishearth.github.io/blog/2021/04/05/a-tour-of-safe.../

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

223. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от myhand (ok), 05-Авг-21, 05:11 
> Стековой памятью надо управлять так, памятью в куче эдак, причём если копнуть
> глубже, то и стековой памятью можно управлять по-разному и памятью в
> куче тоже.

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

> Раст позволяет кодировать эти соглашения в API. И проверяет
> чтобы API соответствовало коду. Причём он проверяет, чтобы реализация API соответствовала
> бы заявленному в API. И он проверяет, чтобы код, пользующийся API,
> пользовался бы им так, как требует выбранная стратегия управления памятью.

Эта задача там действительно решается или "мамой клянус, в 99% случаев это сработает"?

Проверка корректности программ в общем случае - задача алгоритмически
не менее безнадежная чем сравнение двух вещественных чисел.

Ответить | Правка | Наверх | Cообщить модератору

229. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от Ordu (ok), 05-Авг-21, 08:38 
>> Стековой памятью надо управлять так, памятью в куче эдак, причём если копнуть
>> глубже, то и стековой памятью можно управлять по-разному и памятью в
>> куче тоже.
> Ну, так это так или иначе делают при реализации структур данных в
> высокоуровневых языках (типа того же питона).

Насколько я понимаю в пайтоне единственная стратегия управления памятью -- сборка мусора.

>> Раст позволяет кодировать эти соглашения в API. И проверяет
>> чтобы API соответствовало коду. Причём он проверяет, чтобы реализация API соответствовала
>> бы заявленному в API. И он проверяет, чтобы код, пользующийся API,
>> пользовался бы им так, как требует выбранная стратегия управления памятью.
> Эта задача там действительно решается или "мамой клянус, в 99% случаев это
> сработает"?

"мамой клянус". Есть ведь unsafe который позволяет тебе творить всё, что возможно творить в C. Есть unsafe inline asm, который позволяет тебе творить всё, что позволяет asm.

> Проверка корректности программ в общем случае - задача алгоритмически
> не менее безнадежная чем сравнение двух вещественных чисел.

Во-первых, здесь не об общем случае доказательства корректности. Речь о безопасности работы с памятью.

Во-вторых, ... лирическое отступление. Опеннет влюблён в миф о том, что достаточно квалифицированный программист на C может писать безбажные программы. Если мы допустим, что этот миф верен, то из него вытекает, что этот программист про свои программы может доказать их корректность. У него есть в голове какой-то способ это доказать, этот способ -- часть его квалификации. Если он не может доказать, то каким образом он знает, что вот теперь его программа корректна? Вся теория идёт лесом: если теоретически невозможно доказать в общем случае, значит этот программист практически выбирает такие _частные_ случаи (такие способы написать программу), в которых доказательство корректности возможно.

Доказать корректность про целую программу на C практически невозможно. Если это невозможно только потому, что внимания и терпения недостаточно, то это ситуация, с которой C'шные программисты вынуждены мириться, и поэтому она считается нормальной. Но если C'шный программист не видит способа как можно было бы доказать, имея достаточно внимания и терпения, то ему надо переписывать свою программу или быдлокодер. То есть, если у меня в программе есть массив, если я подозреваю, что индекс может выходить за границу его... если я подозреваю, но не знаю, это значит, что я не могу доказать корректность своей программы, это значит, что это гумно, а не программа. В большинстве случаев, когда упираешься в такое, всё же доказываешь -- либо находишь баг и исправляешь его, либо доказываешь корректность. Но мне приходилось переписывать шматы кода, потому что я не понимал, почему они работают: программа падает, почему падает непонятно, падает явно не в том месте кода, где ошибка. Но в программе есть какой-то кусок кода, который я не понимаю -- может из него иногда вылетает висящий указатель? Хз. Доказать не могу, опровергнуть тоже. Начхать, нахрен такой код, я вот сейчас напишу такой, который я буду понимать и про который докажу, что из него не вылетает висящих указателей.

Так вот, _во-вторых_, раст позволяет тебе инкапсулировать unsafety в модулях, чтобы оно если и протекало через границы модулей, то явно и контролируемо. Если ты про каждый модуль с блоками unsafe доказал его safety, разглядывая его в отдельности, если ты затем отдельно разобрал каждый вызов unsafe функции пересекающий границы модулей, и если в процессе выстраивания доказательств ты не совершил ошибок, то ты выстроил доказательство safety. Фишка в том, что тебе не придётся выстраивать доказательств, которые ссылаются на много разных файлов с кодом. Каждое доказательство в отдельности будет ссылаться только на код одного файла. Исключения могут возникать только когда ты вызываешь unsafe функцию из другого модуля.

Но простор для ошибки человека всё же есть, всё же, "мамой клянус".

Ответить | Правка | Наверх | Cообщить модератору

251. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от Аноньимъ (ok), 05-Авг-21, 11:45 
С интересом прочитал, спасибо.
Ответить | Правка | Наверх | Cообщить модератору

269. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от myhand (ok), 05-Авг-21, 12:40 
> Насколько я понимаю в пайтоне единственная стратегия управления памятью -- сборка мусора.

Мда, неудачный пример.

Кстати, а вообще в расте это используется (т.е. в std)?

> Есть ведь unsafe

Не, конечно без.

> допустим, что этот миф верен, то из него вытекает

Не.  Не следует.  Может доказать сможет Ваня, а не чудо-программист.  А может доказать и никто не может, а программа корректна.  Ты - верь!  (Тем более, что это - миф.)

Ответить | Правка | К родителю #229 | Наверх | Cообщить модератору

313. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от Ordu (ok), 06-Авг-21, 14:49 
>> Насколько я понимаю в пайтоне единственная стратегия управления памятью -- сборка мусора.
> Мда, неудачный пример.
> Кстати, а вообще в расте это используется (т.е. в std)?

Какие стратегии в принципе есть? Сборка мусора. Подсчёт ссылок. Или какие-то вручную выстроенные, например, мы на каком-то стековом фрейме выделяем память, а все верхние стековые фреймы работают с этой памятью как со статической, не выделяя или парясь освобождать. Ну, чтоб конкретный пример, допустим у нас есть груда текста в каком-то синтаксисе, мы парсим и может что-то ещё по-мелочи делаем. Как?

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

Но внезапно оказывается, что подстроки (скажем идентификаторы) надо заносить в AST, и AST должен оставаться валидным и после того, как буфер с исходным текстом будет освобождён. Эммм... Ну ок, мы будем прежде чем заносить в AST делать strndup, то есть будем выделять память. Стратегия становится сложнее...

Но тут мы задумываемся о том, что вовсе не нужно на каждое вхождение идентификатора делать новый strndup, надо на каждый идентификатор делать это единожды. Значит перед strndup надо попытаться найти существующий идентификатор с таким именем, и strndup'ить только если он не найден. Стратегия становится ещй сложнее...

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

В стратегии появляются усложнения, дополнения, исключения, и в некоторых случаях она может превращаться в что-то невыразимое словами. Чем сложнее стратегия, тем сложнее ей следовать, тем более вероятны баги. Когда я прочитал какую-то книжку про структуры данных, я был восхищён без меры, и первым делом я запилил такую структуру данных, что... Мне повезло, что тогда я уже сидел в венде, а не в DOS'е, потому что программа падала постоянно, в DOS'е я бы замучался перезагружаться. И никакие объёмы отладки не могли исправить все баги. Потом в моей практике подобное случалось ещё пару раз.

В расте это не проблема, потому что borrowed указатель внутрь неизменяемого буфера отличается от owned указателя, эта разница отслеживается статически, и если я позволяю себе делать с borrowed что-то, что с ним нельзя делать, компилятор будет ругаться. В расте я могу, скажем, для строк-идентификаторов завести специальную кучу -- это может быть просто HashSet, например, чтобы закидывать туда идентификаторы, -- и получить (или может создать вручную) специальный тип указателя, который будет жить немного по своим законам. Типа указатель на идентификатор вроде и borrowed, но используется так же просто как указатель на статическую память -- делай что хочешь, кроме изменений внутри объекта. По-сути, я описываю свой план менеджмента памятью в своих API, и компилятор потом проверяет, насколько мне удалось этому плану следовать. Я могу сколь угодно угодно сложную стратегию изобретать -- всё что мне удастся закодировать в API, -- и не бояться, что эта стратегия слишком сложна для меня, что у меня процессорной мощности серого вещества не хватит на неё. (Ну, то есть, может и не хватит, но я не смогу этого не заметить, потому что в этом случае дело кончится некомпилируемым кодом, который мне не удаётся довести до компилируемого состояния. Это будет очень досадно, но это лучше, чем код который компилируется, и падает в рандомные моменты.)

RAII, на фоне этого, выглядит мелким дополнением, которое избавляет меня от необходимости явно писать free. Иногда это не столь мелко, если это даёт возможность писать полиморфный код, который один раз компилируется в код с вызовом free, а другой раз в код без вызова free, в зависимости от того, с каким куском памяти он работает.

Возвращаясь к std: в ней используются все элементы, из которых можно запилить любую такую стратегию. Используется предача borrowed ссылок, используется передача значения с возвратом его из функции (что позволяет функции, например, принять буфер, при необходимости перевыделить его, изменить содержимое и вернуть обратно), передача "указателя на указатель" (если я закидываю в функцию &mut String, чтобы та дописала что-то, при необходимости перевыделяя память, то это аналог передачи (char** s, size_t* len) в C)... Элементы все используются, то есть примеры использования можно найти. Но естественно в ней не используются все возможные такие стратегии, которые можно построить из этих кирпичиков.

>> Есть ведь unsafe
> Не, конечно без.

Строго говоря без unsafe'а совсем не выйдет. Придётся использовать std, а в std есть, например, реализация массива -- slice и Vec, -- а их невозможно реализовать без unsafe: там внутри работа с raw-указателями в C'шном стиле. Но если принять допущение, что std не содержит ошибок, то дальше всё доказывается строго компилятором.

Ответить | Правка | Наверх | Cообщить модератору

67. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –2 +/–
Сообщение от Аноним (1), 04-Авг-21, 11:41 
Да как ты не поймешь используя раст ты сразу постигаешь дзен. IQ сразу повышается до 1000, а уязвимости рассасываются сами собой. Больше не надо думать вообще раст сам за тебя все напишет. Кто не верит в это тот еретик.
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

79. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от Аноним (44), 04-Авг-21, 11:49 
Поэтому мы не будем даже пытаться разрабатывать инструменты, которые позволяли бы меньше ошибаться или закрывали некоторый класс ошибок вообще
Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

83. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –1 +/–
Сообщение от Аноним (1), 04-Авг-21, 12:02 
Такие инструменты есть и это точно не раст.
Ответить | Правка | Наверх | Cообщить модератору

85. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от Аноним (44), 04-Авг-21, 12:04 
> Такие инструменты есть и это точно не раст.

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

Ответить | Правка | Наверх | Cообщить модератору

157. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –2 +/–
Сообщение от Аноним (29), 04-Авг-21, 16:01 
>> И почему же их не используют?

Нет нужды

Ответить | Правка | Наверх | Cообщить модератору

166. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от Аноним (44), 04-Авг-21, 16:26 
Зато есть нужда память бить
Ответить | Правка | Наверх | Cообщить модератору

132. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –2 +/–
Сообщение от Я топтал твои хелловорлды (?), 04-Авг-21, 14:57 
Пытайся, тебе кто-то запрещает? Иди, разрабатывай! Иди давай!🤣 Никогда ты ничего не разработаешь. В лучшем случае будешь юзать чужое, попутно обсирая.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

195. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от нах.. (?), 04-Авг-21, 21:07 
будем, но называть инструмент ржавым, и делать его для инопланетян... а потом удивлятся почему вменяемые человеки его обсирают
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

200. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от Аноним (-), 04-Авг-21, 22:38 
> а потом удивлятся почему опеннетные анонимы, у которых девиз по жизни "Ничего не обос*ал сегодня? День прошел зря!", его обсирают

Да нет, никто особо не удивляется.

Ответить | Правка | Наверх | Cообщить модератору

65. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –1 +/–
Сообщение от Аноним (65), 04-Авг-21, 11:39 
Правильно, но, к сожалению, медленно
Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

76. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  –1 +/–
Сообщение от myhand (ok), 04-Авг-21, 11:47 
> Правильно, но, к сожалению, медленно

А в Rust быстро - это магия такая или предмет веры?

Ответить | Правка | Наверх | Cообщить модератору

121. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от Аноним (15), 04-Авг-21, 14:07 
Время покажет, по плодам узнаем их. Вспомним, что говорили они.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

126. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +1 +/–
Сообщение от Аноним (15), 04-Авг-21, 14:13 
В одной конторе посчитали, что большая часть багов делается перед обедом и в конце рабочего дня. Ввели кофе-таймы посреди первой и второй половины. Багов стало меньше, профит всем.
Раст может быть и нужен, но вряд ли любители стильного-модного будут переписывать старое, мечтать не миллионы строк кода писать, много лет для этого нужно, 5-10, когда нужное будет по-новому сделано.
Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

175. "Опрос Stack Overflow: Rust назван самым любимым, а Python са..."  +/–
Сообщение от Аноньимъ (ok), 04-Авг-21, 17:13 
Нужен или нет опрос не показывает.
А вот то, что Rust любим, показывает.

А любовь это очень хорошо на самом деле.
Ненужна людям С++ порнуха, она вся шаблонная и не даёт людям испытать настоящую любовь.

Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

81. Скрыто модератором  –3 +/–
Сообщение от Anonymoustus (ok), 04-Авг-21, 11:58 
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

87. Скрыто модератором  +2 +/–
Сообщение от Анонимочкин (?), 04-Авг-21, 12:06 
Ответить | Правка | Наверх | Cообщить модератору

89. Скрыто модератором  –2 +/–
Сообщение от Anonymoustus (ok), 04-Авг-21, 12:08 
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру