Pull to refresh

Comments 30

Я понимаю так: программирование — это создание программ, реализующих определённую логику работы. Создание графических форм это «не вполне» программирование. Это как-бы сопутствующая программированию сфера.
Статья не представляет собой ничего полезного, больше похожа на вводную главу какого-то учебника по Tcl/Tk. Вот если бы автор написал какую-нибудь полезную утилиту и выложил здесь исходный код с разбором, тогда польза была бы.

Это или это, а может это может устроить?
Создание форм — не программирование. Могу согласиться. А вот разработать логику этих форм, заставить выполнять главную задачу и как их создать с минимальными усилиями — это все программирование с Большой буквы. Да и без путеводителя тяжело программировать

Это или это, а может это может устроить?

Нет не может! Это коммерческие продукты с закрытым исходным кодом.
С таким же успехом, Я мог бы написать бесполезную статью про Qt, с приведение нескольких «учебных» примеров о том, как создавать формочки с кнопочками.
Сам таким заниматься не буду, если хотите вот вам ссылка на страницу документации. Переведите на русский язык и будет ещё одна статья: «Разработка приложений на языках C/C++ с использованием Qt»

А про Qt мы знаем начиная с 1.14. И где вы увидели коммерческие продукты? Качайте, изучайте код и т.д. Т.е. вы хотите сказать, что все учебники, все статьи про так как можно и что можно использовать, бесполезны? Интересно, а как вы училися! Кстати, и про Qt статья с примерами не помешала бы и кому-то очень бы помогла. Напишите и вам скажут спасибо.

Вот как раз таки учебники — полезны, а ваша статья бесполезна. Если Я решу изучить Tcl/Tk, то найду официальную документацию и буду читать. Или книгу, которая даст полную информацию о предмете. А собирать у себя в голове «мозаику» из таких вот информационных фрагментов, как ваша статья, нет смысла.

Я вам помогу, вот самая свежая книга:


image


Написана прекрасно.

Создание графических форм это «не вполне» программирование. Это как-бы сопутствующая программированию сфера.

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

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

Скажите пожалуйста, каков практический смысл использовать С89 в 2017 году?
Сужу по объявлению всех переменных в начале функций и по отсутствию однострочных комментариев:

int lenStr(){
    int code;
    int len;
    char slen[256];
    char *res;
/*Читаем из widget-а введенную строку в переменную tcl с именем a*/
    code = Tcl_Eval(tcl_interp, "set a [.ent1 get];");

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

Это какой код классики написали, чтобы я понимал? Так ты приведи этот код, в который "даже тривиальные изнемения" не внесли. Хотя классики и писали для того, чтобы на их коде учились, другие, например, ты.

Как-то громоздко все получилось, а преимуществ каких-то особых не видно. Не проще взять тот же Python+Tkinter? Сдается мне, в последнем случае код будет на порядок компактнее и проще при одном и том же выхлопе.

Вы о чем? Python + Tkinter = Tcl/Tk только со всеми недостатками (вот уж где громоздость так громоздкость). И как может быть на порядок компактнее, если Tkinter с Python это фактически просто обертка вокруг Tcl/Tk.
Вот здесь и здесь есть про Python + Tkinter.

Спасибо, я в курсе про Python + Tkinter. Вот только не в курсе про недостатки. Зато разработка и отлов ошибок на порядок проще на питоне, нежели на той лапше (уж простите) сишного кода, который вы привели в статье. Если вы это делаете just for fun, то окей, вопросов нет, а если для практических целей, то в чем смысл, если тоже самое можно реализовать так же кроссплатформенно, но на порядок проще?

Си это Си, Python это Python. Если вы возьмете "эту лапшу" и положите на Pyton получите один в один тот же код!!! С точностью до синтаксиса. И ошибка для Tk-GUI отлавливаются абсолюно одинаково, их ловит Tcl/Tk.
Не знаю с чем спорить? Есть задачи, которые можно решить и на скриптовых языках, на Python-e (но поверьте это лучше делать на Tcl) например, а есть задачи которые решаются только и только на C/C++.

Почему? На питоне я этот же интерфейс сделаю по-питоновски, мне же не нужно брать тиклевский скрипт и грузить его в интерпретатор. Под использованием Python + Tkinter я имел ввиду все тоже самое сделать на питоне через виджеты Ткинтера, красиво и чисто, плюс логику приложения на нем же. Тяжелые места выносить в С/C++, благо интегрировать сишный код с питоном проще простого.

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

Вот здесь вы найдете проект на Python + Tkinter со всеми исходниками GUI, включая проект. Посмотрите, сравните и ответьте на вопрос "я имел ввиду все тоже самое сделать на питоне через виджеты Ткинтера, красиво и чисто, плюс логику приложения на нем же".
Ну ни чем не отличается. Кому что нравится или на чем уже было сделаною

красиво и чисто

Если вы имеете ввиду отступы в блоках python-а, то да, он заставляет писать структурированно.

Можно взять и питон, но думаю, что статья тогда будет называться «Разработка приложений на языке Python с использованием Tkinter». В данной же статье описывается работа с Tcl/Tk именно из C/C++. Вполне полезная статья.
Ну я вроде бы и не говорил что она вредная. Но мне не очень ясен практический смысл. Код в статье просто вырвиглазный, а судя по самому процессу интеграции, поддерживать это будет очень сложно. Поэтому мной и был задан вопрос — зачем так сложно, если можно быстрее и проще с тем же результатом?

Так код-то генерируемый!

Tkinter тянет за собой tcl тогда какой смысл в питоне?

Ну во первых, В начале было Слово, т.е. все Tcl/Tk.
Я программирую и на том и том и на третьем. Писать на Qt и на Tk это две большие разницы. Попробуйте и увидите насколько легко и просто интрегрировать C/C++ и с Tcl и с Tk.
А вопрос риторический, а зачем Фортран, а зачем Python, а зачем Ada, а зачем Perl и т.д.
Вы же наверное разные рубашки носите. Я обещал и в ближайшие дни выложу материал о том, как использовать динамические C-библиотеки использовать и Tcl.

Немного некропостинг, но вдруг приголится.
Когда-то баловался с такой штукой: cpptk.sourceforge.net
ИМХО неплохая обертка над TclInterp_Create и его друзьями.

Вы правы, красивая штука, о чем я в статье и написал:


Для разработки GUI-приложений с использованием Tk-виджетов на языке C++ разработана красивая библиотека CPPTK. Последнее ее обновление вышло в мае текущего года. Но мы будем иметь ввиду предпоследнюю версию, а именно CPPTK-1.0.2.

А есть еще красивая штучка — CRITcl. Как-нибудь про нее напишу. Спасибо.

Only those users with full accounts are able to leave comments. Log in, please.