Чебурашку я не обижал, я сам как чебурашка. Кроме меня тут вообще никто ничего не вспоминает, так что наверное это намёк в мою сторону. На моём компьютере установлен Borland Delphi 7, но я не вижу смысла лезть во все языки сразу. Тем более что речь то идёт о C++ и кроссплатформенном программировании. То что тему перетащили во флейм её не отменяет.


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

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

То куда Линукс поперся (Путь Венды) - это еще одно проявление влияния корпораций...Победа над "что надо"...

Когда компы были 33МГц - на них работали  (Я имею удовольствие иногда на раритетах поработать помогая людям что-то настроить, установить и т.д.)...
Когда у Меня был 400МГц Целерон, то Я думал что когда появятся 5-10ГГЦпроцы, то графика будет - зашибенно-реалистичная, можно будет в риалтайме в игре что-то делать и это будет выглядить как фильм.....
Но это не так и еще скоро таковым не будет...
Но самое главное Я думал, что во времена 3-5ГГц процов система будет сверх стабильной и виснуть не будет и приложения больше 3-х одновременно будут нормально работать...И не будет никаких тормозов...

Но НАС имеют!...Нас жестоко и регулярно имеют... И делают это просто... .NET, MFC, Java...
Нам дают среду и говорят - не парьтесь, а творите...В итоге когда Ты поуши в ...среде, Ты понимаешь что и слазить поздно и вроде бы можно забить на конечного пользователя, так как кто еще использует компы(У Меня то 3ГГЦ топовый)...  <1ГГЦ?
Нас поимели: Я захотел создавать программы...И так уж сложилось, что Я пользоватль распространненой системы от МС. Куда податься за советом? К вендору... А он лапшой уши забьет и про MFC и про многое другое... Меньше быдлокодеров получается, так как написать программу сложнее чем сайт на php...
В итоге у нас качество кода все падает и те, кто мог бы писать отличный код сидят на платформе, которая написано посредственно(так как расходы на разработку сокращаются, и кто код пишет все знают  )......

Я год из целей сэкономить на покупке второго компа работал на P2 333МГЦ естественно под Линуксом, а потом пересел за Athlon 6000++ + WinXP и... разница настолько маленькая по отношению к увеличению МГЦ в 8раз и ядер в 2раза... Разница до 2-х раз...

Пусть радуются тут некоторые спи...ным IDE, но Мне грустно... 

Нас имеют и разводят на деньги... Наверное если бы запретили бы разрабатывать компы быстрее P3 и сказали бы всем разработчикам - делайте что хотите, но быстрее компов не будет... И разработчики бы сели и начали бы оптимизацию... Но "ИМ не выгодно"!

В общем радуемся, так как скоро комп будет жрать пару киловат и сможет отрисовывать только 2-х мерные приложения %)

unicuum, пора принять таблетку фенозипама  

Это сообщение отредактировал(а) Lazin - 30.4.2009, 05:50

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

Добавлено через 1 минуту и 6 секунд

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

P.S. чебурашка напоминает Майкла Джексона

Продвинутые операции с последовательностями


Помимо одномерных массивов существуют многомерные: ступенчатые [a]...[z] и прямоугольные [a,z]. С одной стороны может показаться, что оба состоят из линейных последовательностей, но и те и другие можно представить в виде подвида графов - древовидного списка, а уж он то точно не является линейным. 

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

картинка не в стиле C++, так что не удивляйтесь


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

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

С точки зрения программиста роль играет лишь порядок обработки данных, именно поэтому мною выбрано такое название, не массивы, не коллекции и не прочая правда от больших корпорациях имя которой ложь, а последовательности (sequences).

Такое восприятие помогает не только однотипно воспринимать и программировать различные структуры данных, но увеличивает уровень взаимодействия с другими классами системы, например, такими как нити - многонитиевое программирование.

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

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

День сурка. Стеки и очереди.

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



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

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

В .NET, да и в целом в майкрософт управление событиями пытаются сделать самым извращённым способом. Они знают в них толк и потому заслужили моё самое глубокое уважение. И вновь STL и Boost остаются за кадром, по причине их процедурной ориентированности, а так же необоснованной перегрузкой макросами.

Но вот Qt, это другое дело. Весёлые розовые поросятки обнаружив столь чудесную платформу с радостным визгом бегут под нож мясника. Ножом в данном случае является мета объектный компилятор. В случае его использования получившаяся программа не обретёт абсолютный уровень абстракции.



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

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

С этим никто спорить не будет. Мир нас ломает, мы прогибаемся под него. Чем меньше у нас власти, тем изощренней мы прогибаемся.
Метаобъектная система Qt это костыль в сам язык C++. У того же fasm'а макросная система гораздо богаче по своим возможностям, а на C++ вместо них придумали метапрограммирование на шаблонах, страшная и некрасивая штука, тоже своего рода костыль, который помогает проводить вычисления в момент компиляции. Или вот в C++ нельзя записать битовую последовательность: 01110001b и передать скажем в unsigned char. Вместо этого я должен изгаляться с булевой алгеброй, использовать сторонние классы или обращаться к каждому биту поименно. Или вот почему нельзя компилятору сказать что-то типа этого: unsigned char massiv[] = #include <myfile.ext>, нет я должен сначала написать кодогенератор, который переведет мне каждый байтик в текст и в удобоваримый для компилятора формат. Но если каждый день исправлять что-то, добавлять, удалять и т.д., то программы написанные на Си/С++ до нововведений перестанут собираться. Старые проекты умрут окончательно, а готовые программы придется насильно переписывать каждый раз, чтобы они были актуальными.

Т.ч. все эти новые абстрактности ни что иное как идея нового компилятора. И насколько бы они небыли правильными - новое поколение идет по ошибкам старого. Сейчас так много новых направлений и веяний появилось, что я с трудом вообще понимаю для чего они нужны. Одно понимание автомата конечных состояний (finite state machine) требует не одного часа раздумья.

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


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


Нет, C++ умеет абсолютно всё, не его вина, что люди "забивают микроскопом гвозди". Проблема не в языке, проблема в библиотеках. Скорее всего их писали сишные кодеры пытаясь сделать совместимость так, чтобы и старые программы компилировались. Но мне это не нужно, я старые программы не писал, потому могу забить.

Затеряный мир программирования

Существует множество видов программирования. Как уже упоминалось ранее одно из них процедурное, которое ещё называют функциональным, а второе объектно-ориентированное. Помимо этого на каждое из них можно накладывать обобщённое программирование. STL и Boost относятся к процедурному обобщённому программированию.

• Обобщённое программирование (ОП)
• Объектно-ориентированное программирование (ООП)
• Обобщённо-объектно-ориентированное программирование (ОООП)

Тот же Qt худо бедно пытается использовать объектно-ориентированное программирование, но ведь C++ намного шире этих понятий, так как позволяет работать в парадигме обобщённого-объектно-ориентированного программирования.

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



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

Какие-то пошлые картинки пошли   

Под включением подразумевается агрегация?

см. чуть выше

А нельзя ли как-то объединить схемы "включения" и "наследования", таким образом, чтобы всем стал понятен смысл первого варианта ответа в опросе?
---

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



Это сообщение отредактировал(а) SABROG - 1.5.2009, 17:01

Эй, вы так рискуете до песочницы, а не только флейма дойти