С++ - главное начало..

Никак. Иначе получиться абсолютный быдлокод (причем не только под Linux). Рекомендую читать Кормена или Кнута вначале.

>Интересует создание GUI.

Если плюсы, то изучать Qt.

Что имеется в виду под созданием гуи? Зачем совершенно незнакомому с программированием человеку нужно быстро научиться этому? Опишите задачу.

Для плюсов ни Кормен ни Кнут не помогут, тем более для GUI они не нужны, все равно будет быдлокод.

Быдлокод - понятие растяжимое. Ибо если у меня есть в коде вразумительные каменты, но вам он по какой-либо причине не нравится - так это сразу быдлокод? Что-то вы батенька загинаете...

Если быдлокод откамментить, то от этого он не перестанет быть быдлокодом.

Не-а, не загинают. Пожалуйста, оставьте плюсы в покое и больше не трогайте. Tcl/tk вас спасёт.

В сжатые сроки не получится, вначале человеку придется осилить Шилдта, потом Саттера, потом Александреску. Если будет сильно ботать, то может быть на полгода управится.

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

Каменты не причем. Быдлокод - это концептуально неправильный код, который неэффективен и непродуман.

Например, многократные проверки на наличие в списке нуля, хотя _логика_ программы однозначно указывает его наличие или отсутствие в списке. А проверки не дешевые - например просмотр списка занимает линейное время, т.е. некая константа умноженная на количество. Если количество элементов не велико, то программа еще работает быстро. Когда количество элементов становится около 1 млн, программа уже существенно тормозит. В этот момент Настоящий Быдлокодер потребует более быстрого железа. Тут все потеряно. Ненастоящий - задумается, что же тут можно улучшить. Тут еще существует возможность к излечению.

Задача: проф дизайнеру весьма неплохо знающему Linux, требуется написать программу для мониторинга включенных компьютеров в сети на С++ с использованием GUI. Теперь поясню ситуацию: уволился последний кодер, его обязанности возложены на меня. Правда ЗП обещали повысить. Сейчас читаю книгу " Язык С++" В.В. Подбельский.

>осилить Шилдта, потом Саттера, потом Александреску

Хм, интересный список. Я так думал(ю), что классика Страустрруп->Шилдт->... А можно поподробней теперь про Саттера и Александревску(название лит-ры).

>осилить Шилдта, потом Саттера, потом Александреску

Хм, интересный список. Я так думал(ю), что классика Страустрруп->Шилдт->... А можно поподробней теперь про Саттера и Александревску(название лит-ры).

Сочувствую. Но помочь ничем не могу. Очень рекомендую последовать примеру предыдущего кодера.

> Задача: проф дизайнеру весьма неплохо знающему Linux, требуется написать программу для мониторинга включенных компьютеров в сети на С++ с использованием GUI. Теперь поясню ситуацию: уволился последний кодер, его обязанности возложены на меня.

0_o

> Сейчас читаю книгу " Язык С++" В.В. Подбельский.

Не в курсе что это за книга, но сам отечественных авторов стараюсь не читать (в обсуждаемом контексте) и вам не советую.

> требуется написать программу для мониторинга включенных компьютеров в сети на С++ с использованием GUI

Вот такой совет: если производительность не критична (на мой взгляд здесь именно такой случай), то лучше попробовать python: 1. любой gui (qt, tk, gtk и пр.); 2. освоить его на порядок проще нежели плюсы; 3. огромное кол-во батареек.

Страуструпа лучше не читать.
Саттер:
http://www.ozon.ru/context/detail/id/1273216/
Александреску:
http://www.ozon.ru/context/detail/id/1224785/

>на С++ с использованием GUI.

1. C++ - это условие заказчика или сами придумали? 2. Мне нравится разработка на основе glade/gtk/C. В glade можно быстро отрисовать окошки (главное - понять концепцию ящиков (Boxes)), gtk проста в изучении, ну а С - значительно проще чем C++, т.к. в нем значительно меньше противоречий.

>для мониторинга включенных компьютеров

навсякий случай:

man ping

>Сейчас читаю книгу " Язык С++" В.В. Подбельский.

Эта книга была актуальна 15 лет назад. Лучше не трать на неё время.

>Страуструпа лучше не читать.

+1, Страуструп написал справочник, а не учебное пособие.

Спасибо. А че так катигорично про Страуструпа?

1. В C++ нет противоречий.

2. C + gtk тоже достаточно нетривиальная вещь и если человек будет писать с нуля, то рождение быдлокода более вероятно чем в случае с С++ + Qt.

Я ниасилил в свое время, слишком непонятно пишет.

А что вы думаете о таком авторе как Lippman? Конкретно вот эта книга? http://www.oz.by/books/more1027324.html

>1. В C++ нет противоречий.

Friends? Дуализм ООП и структурного подхода?

>2. C + gtk тоже достаточно нетривиальная вещь и если человек будет писать с нуля, то рождение быдлокода более вероятно чем в случае с С++ + Qt.

Честно, не знаю. Мне просто понравилась такая связка, а искать того, кто не умеет программировать и просить выучить такое как-то не хочется =)

> С++ ... совершенно незнакомому с кодингом человеку

Смертельная комбинация. Именно этим ужасен С++.

> требуется написать программу для мониторинга включенных компьютеров в сети на С++ с использованием GUI

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

> Сейчас читаю книгу " Язык С++" В.В. Подбельский.

Немедленно выбрось это говно. От нее вреда больше, чем пользы.

Начинать учиться лучше по Страуструпу, 2-е издание (именно 2-е, оно есть в сети). Если нормально с английским, можно начать с этого: http://www.icce.rug.nl/documents/cplusplus/

Александреску - хорошая и полезная книга, но для написания GUI не обязательная.

>>1. В C++ нет противоречий.

>Friends? Дуализм ООП и структурного подхода?

В этом треде тебе еще не советовали "вдоль"?

>>>1. В C++ нет противоречий.

>>Friends? Дуализм ООП и структурного подхода?

>В этом треде тебе еще не советовали "вдоль"?

Ну вот ты посоветовал. Выпендрился, молодец!

>>>Friends? Дуализм ООП и структурного подхода?

>>В этом треде тебе еще не советовали "вдоль"?

>Ну вот ты посоветовал. Выпендрился, молодец!

Я не успел тебе этого посоветовать, но всё равно - извини. Не употребляй больше "дуализм ООП и структурного подхода" в списке недостатков Си++, потому что это не недостаток. И friend - тоже.

>Не употребляй больше "дуализм ООП и структурного подхода" в списке недостатков Си++, потому что это не недостаток.

А что - достоинство? Когда существует возможность обращения к private структурам и методам класса?

>И friend - тоже.

А friend - это стандартизированный грязный хак. "Всегда хочется нарушить правила. Вот и с помощью friend можно проделать дырочку в инкапсуляции и обратиться к внутренним данным и методам класса". ИМХО, это некачественная модель.

>> Не употребляй больше "дуализм ООП и структурного подхода" в списке недостатков Си++, потому что это не недостаток.

> А что - достоинство?

Да.

> Когда существует возможность обращения к private структурам и методам класса?

Не понял, о чем ты.

> А friend - это стандартизированный грязный хак.

Именно. И ты можешь его не применять.

> "Всегда хочется нарушить правила. Вот и с помощью friend можно проделать дырочку в инкапсуляции и обратиться к внутренним данным и методам класса".

Жизнь такова.

> ИМХО, это некачественная модель.

Ну, назови языки, в которых нет такой возможности.

>> А friend - это стандартизированный грязный хак.

>Именно. И ты можешь его не применять.

Нет, приходится. Иначе ты операторы в обе стороны ты не определишь.

>> Когда существует возможность обращения к private структурам и методам класса?

>Не понял, о чем ты.

С-style возможность обращения и записи по указателю (например char*) в класс нарушит ООП стиль.

>> ИМХО, это некачественная модель.

>Ну, назови языки, в которых нет такой возможности.

ЕМНИП, Java

>>> А friend - это стандартизированный грязный хак.

>>Именно. И ты можешь его не применять.

>Нет, приходится. Иначе ты операторы в обе стороны ты не определишь.

Операторы использовать необязательно :)

> С-style возможность обращения и записи по указателю (например char*) в класс нарушит ООП стиль.

Это наследство Си. И что там Саныч говорил про дверь?

Если уж очень нужно, используй паттерн pimp.

>>> ИМХО, это некачественная модель.

>> Ну, назови языки, в которых нет такой возможности.

> ЕМНИП, Java

ЕМНИП, там по умолчанию у поля класс видимости package - это как раз то, для чего (по-хорошему) используется friend.

А в Smalltalk и Python вообще все поля открытые - и что, тоже негодная модель? :D

>>>> А friend - это стандартизированный грязный хак.

>>>Именно. И ты можешь его не применять.

>>Нет, приходится. Иначе ты операторы в обе стороны ты не определишь.

>Операторы использовать необязательно :)

Круто =)

>>>> ИМХО, это некачественная модель.

>>> Ну, назови языки, в которых нет такой возможности.

>> ЕМНИП, Java

>ЕМНИП, там по умолчанию у поля класс видимости package - это как раз то, для чего (по-хорошему) используется friend.

Неуверен.

>А в Smalltalk и Python вообще все поля открытые - и что, тоже негодная модель? :D

Почему же! Наоборот, мне такая модель нравится даже больше! В этой модели (по крайней мере с точки зрения на внутрение поля) мне не вставляют палки^Wпалочки в колеса, которые элементарно обходятся и никому не нужны.

В конце-концов, смысл программисту вызывать внутренние функции класса? Чтобы программа в результате не работала? Ты не находишь это глупым?

>>ЕМНИП, там по умолчанию у поля класс видимости package - это как раз то, для чего (по-хорошему) используется friend.

>Неуверен.

В package или в использовании friend?

>>А в Smalltalk и Python вообще все поля открытые - и что, тоже негодная модель? :D

> Почему же! Наоборот, мне такая модель нравится даже больше!

Тогда не понимаю претензий к friend. Делай все поля public, и friend не понадобится.

> смысл программисту вызывать внутренние функции класса? Чтобы программа в результате не работала? Ты не находишь это глупым?

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

>В package или в использовании friend?

В package. Я его не использовал. =)

>>>А в Smalltalk и Python вообще все поля открытые - и что, тоже негодная модель? :D

> Почему же! Наоборот, мне такая модель нравится даже больше!

>Тогда не понимаю претензий к friend. Делай все поля public, и friend не понадобится.

Я понимаю. Но я в самом начале говорил о противоречивости модели. Таким образом, ты признаешь, что некоторые конструкции языка избыточны?

>> смысл программсту вызывать внутренние функции класса? Чтобы программа в результате не работала? Ты не находишь это глупым?

>Нахожу. Я так же нахожу, что людям свойственно делать глупости, и если язык этому мешает - это плюс.

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

> ты признаешь, что некоторые конструкции языка избыточны?

На этом примере - нет. Я признаю, что нет единой модели, одинаково хорошо подходящей для всех случаем.

> Возникает ощущение отсутствия контроля, и получается что тупая железка умнее тебя...

Не железка, а программист. И не умнее тебя (хотя всяко может быть). а больше тебя знает о программе, которую написал.

> Правда ЗП обещали повысить.

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

>> ты признаешь, что некоторые конструкции языка избыточны?

> На этом примере - нет. Я признаю, что нет единой модели, одинаково хорошо подходящей для всех случаем.

Для поставленной задачи C++ - не самый подходящий для начинающего программиста язык, какие бы модели разработки он не предоставлял...

Почитай книжку по С++, хотя бы основы. Потом почитай книжку по Qt. Потом начинай писать.

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

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

>Нахожу. Я так же нахожу, что людям свойственно делать глупости, и если язык этому мешает - это плюс.

В С++ public/private и тд и тп это защита от дурака, которая обходится средствами самого языка :)

Пример из жизно про С++ - есть у нас один препод - дык он свои знаия C++ использует только для крутой распальцовки, хая все остальные языки.

>паттерн pimp.
шо за зверь такой? в книге четырех такого не нашел. киньте ссылкой.

> Для поставленной задачи C++ - не самый подходящий для начинающего программиста язык, какие бы модели разработки он не предоставлял...

Полностью согласен. ИМХО, писать на Си++ GUI не стоит ообще, но у OP явно нет выбора - часть кода уже написана до него.

>> паттерн pimp.

> шо за зверь такой? в книге четырех такого не нашел. киньте ссылкой.

В GoF его нет, это специфический Си+++-трюк. Так же известен как pimpl idiom и opaque pointer.

http://en.wikipedia.org/wiki/Opaque_pointer

> шо за зверь такой? в книге четырех такого не нашел. киньте ссылкой.

Естественно не нашел, это C++ специфичная вещь, смотреть надо у Саттера.

> Пример из жизно про С++ - есть у нас один препод - дык он свои знаия C++ использует только для крутой распальцовки, хая все остальные языки.

C++ можно по вкусу заменить на любой другой ЯП.

> Полностью согласен. ИМХО, писать на Си++ GUI не стоит ообще, но у OP явно нет выбора - часть кода уже написана до него.

Учитывая постановку задачи, лично мне бы хватило одного дня, чтобы реализовать её на python + любой тулкит, включая изучение python'а и тулкита :)

>Сейчас читаю книгу " Язык С++" В.В. Подбельский.

Выкинь. Купи сраусатруппа. По моему, это единственно _необходимая_ книга для изучения плюсов. Толко читать надо вдумчиво и полностью. ;)

> Учитывая постановку задачи, лично мне бы хватило одного дня, чтобы реализовать её на python + любой тулкит, включая изучение python'а и тулкита :)

Тебе для этого нужен ЦЕЛЫЙ ДЕНЬ? O_O Прекрати принимать тормозин в таких дозах :D

> Тебе для этого нужен ЦЕЛЫЙ ДЕНЬ? O_O Прекрати принимать тормозин в таких дозах :D

Ну, кофе с утра попить, потом обед, после обеда спать охота, перед уходом с работы как раз часика полтора есть ;) А если серьёзно, то вы новый ЯП и тулкит осваиваете меньше, чем за день? :)

> А если серьёзно, то вы новый ЯП и тулкит осваиваете меньше, чем за день? :)

Если серьезно, то зависит от тулкита. PyGTK я осваивал несколько дней. Впрочем, это оффтопик 8)