Сергей Протько: Мне неловко парировать слова специалиста. Да, Вы правы. Но ведь не говорил про сервер, сказал исключительно с точки зрения клиента. Браузер открыт - сессия для пользователя есть, закрыт - сессии нет (но на сервере есть). Cookies же есть и после закрытия браузера. Не так?
Сергей Протько: Безусловно. Но попробую объяснить свою мысль другими словами, дабы не смущать автора вопроса и читателей.
Cookies - это инструмент, который позволяет сохранить на компьютере пользователя какие-то краткие идентификационные данные после закрытия браузера, дабы иметь возможность использовать их повторно в будущем.
Сессии же для пользователя живут до тех пор, пока браузер не будет закрыт.
Если ошибаюсь в этом, то буду благодарен за указание.
Можно попробовать записывать координату начала и координату конца интервала в разные ячейки. То есть, вместо записи в столбце X в одной ячейке "12-20", будет две ячейки "12" и "20". Если же таких записей много, то вместо ячеек можно добавить столбцы (X-начало и X-конец).
После этого можно сделать запрос к БД в отношении конкретной строки и, получив все координаты отрезка, сверить с ними координаты точки. Надеюсь, правильно понял Ваш вопрос и проблему.
То есть, нужно узнать, попадают ли координаты точки в заданный интервал? Если так, то почему бы просто не проверить, входит ли каждая из координат точки в заданный промежуток, соответствующий её оси.
Ребят, спасибо вам за внимание к моему вопросу и отклики. Ответы пользователей lega и Tark пометил в качестве решения, но при этом разъяснения и комментарии, которые оставили Сергей Протько, Sergey Lerg и DancingOnWater, были столь же полезны.
DancingOnWater: Python + PyQt при использовании QML даст свободу для отрисовки интерфейса. Именно поэтому отнёс данную связку к числу приоритетных.
А сложность Си нахожу скорее не в синтаксисе и необходимости знать методы работы с языком и самой системой, а в том времени, которое необходимо для достижения приемлемого уровня, позволяющего самостоятельно решать простые задачи без очевидных ошибок. Как ни крути, порог вхождения выше.
Если благодаря Питону смогу более-менее качественно решить свою задачу через несколько месяцев, пару раз переписав код по ходу изучения языка, то с C++ вряд ли смогу сделать то же самое хотя бы через год. Абы как, грязно и неприлично - может быть, хорошо - маловероятно.
Сергей Протько: Во многом отсутствие должного развития подобных идей, вкупе с их зависимостью от энтузиазма автора и определяют необходимость выбора из более стабильных и распространённых проектов.
Сергей Протько: Спасибо за Dlang. Тоже рассматривал его в качестве кандидата, но по причинам, которые указал ниже в комментарии к ответу DancingOnWater (учебные материалы, GUI), пришлось от этого варианта отказаться.
Всё же, занимаясь Front-end разработкой, не думаю, что в ближайшее время подобная "экзотика" в хорошем смысле мне пригодится. Если Питон в работе ещё может быть полезен, а знание C++ даёт огромные возможности и является чем-то вроде показателя высокой квалификации специалиста, то изучение чего-то редкого, экспериментального, нового или недостаточно популярного, полагаю, больше подойдёт для профессионального программиста, нежели для любителя.
Мой вопрос, как сказал чуть ранее, был задан исключительно потому, что не могу квалифицированно оценить скорость работы приложений, написанных на различных языках, в обычных условиях. Вернее даже не столько скорость, сколько будут ли заметны эти различия рядовому пользователю. Ведь, скажем, если C++ в тестах показывает результат всего в доли секунды, а Питон - несколько секунд, то у меня (непрофессионала) это ассоциируется с такими же тормозами и при реальном использовании.
По этой причине и спросил сообщество об уместности своих опасений и о том, действительно ли Питон настолько медленный. Если же все эти тесты намеренно сделаны ресурсоёмкими, а в реальных условиях в большинстве случаев различий не будет никаких (или они будут незаметны), то это ли не повод для радости? :)
О, благодарю за ссылку на сравнение в реальных условиях. Очевидно, что результаты решения абстрактной задачи с сайта IBM почти не отличаются от практических.
Задачи и подход, используемые Mozilla при разработке Rust, не могут не радовать. Но не являясь профессиональным программистом, вынужден в первую очередь исходить из принципов популярности языка, обусловливающей наличие различных учебных материалов, и присутствия специалистов, которых можно терзать своими вопросами.
Кроме того, как упоминал, помимо самого языка вряд ли смогу обойтись без GUI библиотеки, предоставляющей возможности по тонкой настройке интерфейса. Всё же, мои задачи на данный момент лежат исключительно в плоскости простых "бытовых" приложений. Долгие безуспешные поиски достаточно незамысловатой программы подтолкнули к тому, чтобы выучить язык и написать её самому. А там, возможно, она и кому-нибудь ещё пригодится.
Что же касается C++, то, учитывая его сложность, он вряд ли будет лучшим выбором для изучения в качестве первого языка. Однако игнорировать и пренебрегать этим монстром вовсе не хотел, поскольку его достоинства хорошо известны.
MAKAPOH: Спасибо за пример. Находил некоторые компилированные приложения, написанные на Питоне, и тестировал их в Windows, что-то срабатывало почти мгновенно, что-то временами подтормаживало. Найти же что-то вроде сравнительных тестов скорости языков с реальным ПО, а не абстрагированно, не удалось. Отсюда и сомнения.
Сергей Протько: Безусловно, написание качественного кода требует хорошего знания языка. И чем сложнее язык, тем больше времени потребуется для его понимания и выработки правильного стиля. Соотношение КПД языка с затратами времени на изучение и разработку и послужил причиной моего обращения к сообществу.
Не хочу невольно оскорбить приверженцев Java или C#, но первый язык не рассматриваю из-за его ориентированности на ПО для предприятий и мобильные платформы, а второй просто не привлекает. Всё же, мне нравится лаконичность Питона. А единственным сдерживающим фактором было беспокойство по поводу скорости работы написанной на нём программы, которое было развеяно Вами и остальными откликнувшимися пользователями. Кроме того, учитывая хорошие отзывы, в качестве дополнительного варианта попробую немного поработать с Go.
К сожалению, для меня значения времени выполнения приложений в сравнительных обзорах выглядят преимущественно в качестве абстрактных чисел. Не имея достаточного опыта, не могу судить о том, насколько скорость выполнения реального приложения, написанного на C++ будет превосходить аналог на Python. Если на рядовом ПК разница будет составлять всего доли секунды, то для меня выбор очевиден - Python. Если же эта разница будет значительной и заметной для пользователя, то, судя по всему, выбор будет в пользу C++.
Не планирую писать высоко нагруженные проекты, лишь что-то полезное в "быту". Например сейчас, не столько для развлечения, сколько для собственного удобства хочу написать дополняемый пользователем словарь иностранных слов с использованием SQLite и удобным интерфейсом.
Просто не хотелось бы, соблазнившись потенциальным быстродействием C++, потратить уйму времени на его изучение, а потом обнаружить, что для обычных задач использование этого языка будет сродни стрельбы из пушки по комарам, поскольку Python смог бы справиться в этом случае не хуже.
И у каждого языка - свои задачи, несомненно. Весь вопрос в том, чтобы не потратить время впустую на изучение того, что потом окажется не столь полезным, сколь ожидалось.
Комментируемый ответ поправлю.