С, С++, Pascal, Basic, Assembler и другие языки программирования, hex-редакторы

lsor · 3 октября, 2008

А в чём же была проблема?

Вылетели? Так это институтское задание было?

ALF_SS · 3 октября, 2008

repeat

{ получаем координаты курсора мыши }

x:=Ms_x;

y:=Ms_y;

{ рисуем картинку в позиции курсора мыши }

Put_Window(x,y,pic^);

until Ms_Lbut=press;

вроде ж сравнение в паскале <>

не селен я в паскале

ИМХО убогий язык и синтаксис

lsor · 3 октября, 2008

ИМХО убогий язык и синтаксис

Нет, не убогий. Убогий синтаксис в Си++.

ALF_SS · 4 октября, 2008

0_O ик

вот это новость.

ну ка покажите мне понятный исходник из 2к строк на делфях .

lsor · 4 октября, 2008

Делфи - это не синоним паскаля. Синтаксис паскаля - это не синтаксис делфи. Точно так же, как и синтаксис си - не синтаксис билдера (вас не смущало, что у вас класс окна неявно связан в билдере с функциями обратного вызова Windows? Средствами языка Си такое сделать невозможно - потому-то и появились макросы в MFC и метаобъектный компилятор в Qt). Что касается синтаксиса паскаля - он гораздо более ясный и чёткий, в отличие от незабвенного Си++, в котором наизвращались до того, что зачастую программы совершенно не читаемые без знания тонкостей. И это как бы ещё и без связки с убогой по синтаксису MFC. Вот смотрите, например, переменная с модификатором static, объявленная в самом классе является разделяемой со всеми объектами этого класса. Удивительно, правда? На кой чёрт это сделали? Это абсолютно не интуитивно и даже бессмысленно (потому что такие переменные очень удобно использовать в качестве флагов, а здесь эта возможность утеряна). И там как бы таких фишек много. I++, ++I, I+=A, if (a!=b && b!=c) (и попробуйте написать одну &). Там много гадостей. Невозможно, например, деструктору указать тип принимаемого значение void. Как и возвращаемого, впрочем. Вот зачем? Почему бы в целях унификации это не разрешить? Почему переменная в одних компиляторах живёт вне цикла, в котором была объявлена, а в других нет? Бред ведь.

samuran · 4 октября, 2008

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

Solanacean · 4 октября, 2008

I++, ++I, I+=A, if (a!=b && b!=c) (и попробуйте написать одну &)

А не надо писать одну &. И перечисленные конструкции являются наследием языка системного программирования, не забывайте. Автоинкремент и автодекремент очень удобно использовать, например, при работе с указателями и если не ставить себе цель обфусцировать код =), получается лаконично и очень читабельно. Кстати, о указателях - совсем недавно портировал код с C на Delphi (функцию распаковки пожатого по трем алгоритмам BMP, там все держится на указателях), лишний раз убедился в том, что работа с указателями в Delphi возможна разве что через одно место. Вот скажите мне на милость, почему в Delphi переменная-указатель не может использоваться в качестве имени массива, как в C? Это же логично, любому, кто хоть немного программировал на ассемблере, понятно, что связь между указателями и массивами самая что ни на есть прямая. Так почему я должен городить огород вроде

Type 
TZeroArrayB = Array[0..0] of Byte;
Var
pArrayB: ^TZeroArrayB;
  ...
begin
  ...
  GetMem( pMem, 1234 );
  pArrayB := pMem;
  ...
end.

чтобы обратиться к памяти, на которую указывает pMem, как к массиву байт? Разве такой способ - не грязная реализация по сути, в которой используется неспособность компилятора определить выход за границы массива? А вот в этом

sIn.Read( pMem^, sIn.Size );

логика какая? Операция '^' это операция разыменования указателя, т.е. получение переменной, адрес которой находится в переменной-указателе. Функции чтения нужно передать адрес буфера, так почему тогда '^'?

P.S. Был немало удивлен, обнаружив, что арифметические действия с указателями в Delphi возможны только через функции Inc/Dec, но это уже мелочи жизни... >_<

Изменено 4 октября, 2008 пользователем Gishi (смотреть историю редактирования)

lsor · 5 октября, 2008

А не надо писать одну &.

Да, но она тоже имеет смысл. И в ряду случаев пройдёт, как битовая операция. И не заметите даже.

получается лаконично и очень читабельно.

Если не злоупотреблять, правда.

Вот скажите мне на милость, почему в Delphi переменная-указатель не может использоваться в качестве имени массива, как в C? Это же логично, любому, кто хоть немного программировал на ассемблере, понятно, что связь между указателями и массивами самая что ни на есть прямая.

Это, наверное, потому, чтобы исключить ряд ошибок с использованием указателей. А вообще, нужны ли вообще указатели в паскале? Зачем Delphi лезть на такой низкий уровень в принципе?

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

А вот в Си++ приколы. Тоже очень неявные. Пример из книжки.

Пусть есть класс Account;

Пишем:

Account *pact = new Account[10];

Ну создали мы массив из 10 элементов.

А теперь его удалим.

delete pact;

Верно? Не-а. Деструктор вызовется только для первого объекта. Верно писать delete [] pact; Мда... И почему я, а не компилятор, должен за этим следить и явно указывать, что удаляется массив?

niiro dzyaki · 5 октября, 2008

работа с указателями в Delphi возможна разве что через одно место

Нормальная там работа с ними. Проблема в:

портировал код с C на Delphi

С языка достаточно низкого уровня на язык ООП? Естественно, будут проблемы - кесарю кесарево.

Вот скажите мне на милость, почему в Delphi переменная-указатель не может использоваться в качестве имени массива, как в C?

Отвечает К.О.:

"Потому что указатели в Дельфи типизированные".

Это же логично, любому, кто хоть немного программировал на ассемблере

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

Так почему я должен городить огород вроде

Отвечает К.О.:

"Потому что строгая типизация". И вообще, array of есть.

Функции чтения нужно передать адрес буфера

Really??? Так и написано procedure Read(Buffer: Pointer; Size: Cardinal); ?

Или все же procedure Read(var Buffer; Size: Cardinal); ?

P.S. Был немало удивлен, обнаружив, что арифметические действия с указателями в Delphi возможны только через функции Inc/Dec, но это уже мелочи жизни... >_<

А мужики то не знают ... Integer(p) отменили?

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

Mitea · 5 октября, 2008

Вот смотрите, например, переменная с модификатором static, объявленная в самом классе является разделяемой со всеми объектами этого класса. Удивительно, правда? На кой чёрт это сделали?

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

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

"А откуда я знаю, зачем вы блинами вытираетесь?". std::vector<Account> - само удалится и деструкторы где надо вызовет.

Solanacean · 5 октября, 2008

А вообще, нужны ли вообще указатели в паскале? Зачем Delphi лезть на такой низкий уровень в принципе?

Вы попробуйте написать паковщик/распаковщик сначала не используя указатели, а потом используя их. Или попробуйте написать что-то с использованием WinAPI.

С языка достаточно низкого уровня на язык ООП? Естественно, будут проблемы - кесарю кесарево.

Уважаемый, разве я говорил о том, что использовал средства ООП? И C++, например, если уж на то пошло, тоже язык ООП. И задача передо мной стояла не совсем прикладная, если вы не обратили на это внимание.

Отвечает К.О.:
"Потому что указатели в Дельфи типизированные".

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

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

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

Really??? Так и написано procedure Read(Buffer: Pointer; Size: Cardinal); ?
Или все же procedure Read(var Buffer; Size: Cardinal); ?

Т.е. вам не кажется, что

sIn.Read( pMem^, sIn.Size );

это редкостный изврат? (pMem - указатель на буфер, напоминаю)

А может быть вы думаете, что и это:

sIn.Read( SomeDynamicArray[0], sIn.Size );

верх изящества?

А мужики то не знают ... Integer(p) отменили?

Можно подробнее? Я без всякой задней мысли спрашиваю, потому как на Delphi, в отличие от мужиков, не работаю.

Изменено 5 октября, 2008 пользователем Gishi (смотреть историю редактирования)

lsor · 5 октября, 2008

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

Это уже из области фантастики. Причём, малонаучной. Какое мне дело до пространства имён класса? ;)

"А откуда я знаю, зачем вы блинами вытираетесь?". std::vector<Account> - само удалится и деструкторы где надо вызовет.

Эта пять! :D А, может, на стеке точки входа в деструкторы ещё сохраним? Тоже вызовутся ведь. ;) А серьёзно, вопрос не о том, как это можно сделать, вопрос о том, ПОЧЕМУ ТАК.

Вы попробуйте написать паковщик/распаковщик сначала не используя указатели, а потом используя их. Или попробуйте написать что-то с использованием WinAPI.

А это уже вопрос кривости реализации этого самого API. Учитывая, что он написан на Си, нет ничего удивительного, что возникают проблемы с паскалем. Действительно, в Win API количество указателей просто фантастическое. Но с другой стороны, раз уж мы полезли с паскалем в Windows, в Delphi стоило бы сделать полную внутреннюю обвязку Win API с уровня паскаля, а не заставлять программистов применять паскаль в качестве Си.

И C++, например, если уж на то пошло, тоже язык ООП.

Увы, нет. Си++ - это просто Си с классами. Настоящий объектно-ориентированный язык - это Objective C, который с Си++ имеет не слишком-то большую совместимость. Увы, я с ним не знаком, но судя по описаниям, это именно то, что очень удобно для работы с объектами. Не случайно Mac OS его использует.

между тем Delphi налагает на операции с указателями совершенно идиотские искусственные ограничения. В результате - ни рыба ни мясо.

Боюсь, что они этому самому Delphi чужеродны напрочь. И ввели их в угоду необходимости в спешке.

Solanacean · 5 октября, 2008

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

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

Увы, нет. Си++ - это просто Си с классами. Настоящий объектно-ориентированный язык - это Objective C, который с Си++ имеет не слишком-то большую совместимость. Увы, я с ним не знаком, но судя по описаниям, это именно то, что очень удобно для работы с объектами.

Это тема для жаркого холивора, в котором я, уж простите, не имею желания принимать участие. Уверен, что Objective C был выбран в качестве основного языка для макоси несколько по иным соображениям, нежели чем "потому что это труЪ".

Delphi стоило бы сделать полную внутреннюю обвязку Win API с уровня паскаля, а не заставлять программистов применять паскаль в качестве Си.

А вот интересно, в макосях подобная обвязка есть? Идея хорошая, да.

[EDIT] Нет, погодите... Во-первых, разве реализовывать такую обвязку должна M$, а не Борланд? Во-вторых, такая обвязка частично есть. Вам не приходилось дизассемблировать и отлаживать (на уровне ассемблера) экзешники, скомпилированные в Delphi? Внутри них совершенно жуткий спагетти-код, где вокруг каждого вызова WinAPI-функции слоями накручены обертки.

Боюсь, что они этому самому Delphi чужеродны напрочь. И ввели их в угоду необходимости в спешке.

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

Изменено 5 октября, 2008 пользователем Gishi (смотреть историю редактирования)

lsor · 5 октября, 2008

Это тема для жаркого холивора, в котором я, уж простите, не имею желания принимать участие. Уверен, что Objective C был выбран в качестве основного языка для макоси несколько по иным соображениям, нежели чем "потому что это труЪ".

Вот из Википедии:

Си++ (англ. C++) — компилируемый строго типизированный язык программирования общего назначения. Поддерживает разные парадигмы программирования: процедурную, обобщённую, функциональную; наибольшее внимание уделено поддержке объектно-ориентированного программирования.

Название «Си++» происходит от Си, в котором унарный оператор ++ обозначает инкремент переменной.

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

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

Objective-C, известный также как Objective C, ObjC или Obj-C — компилируемый объектно-ориентированный язык программирования, построенный на основе языка C.

В отличие от C++, язык Objective-C полностью совместим с Си и является довольно тонкой надстройкой. Объектная модель построена в стиле Smalltalk, то есть, объектам посылаются сообщения.

В Мас его выбрали потому, что сообщения и объекты на уровне языка - вот что очень нужно оконной ОС.

А вот интересно, в макосях подобная обвязка есть? Идея хорошая, да.

А я про паскаль под Mac OS и не слышал... бывает ли он вообще?

Как это, простите, в спешке? Указатели были в борландовских реализациях паскаля задолго до появления Delphi.

А у Вирта они были? Я не помню, но вроде как и нет. Да и спешка в том, что всё, что с указателями нужно делать - так это распределять динамическую память. И больше ничего! А всё остальное - это извращение.

Изменено 5 октября, 2008 пользователем lsor (смотреть историю редактирования)

Mitea · 5 октября, 2008

Это уже из области фантастики. Причём, малонаучной. Какое мне дело до пространства имён класса?

Не захламлять глобальное пространство имен.

Эта пять! А, может, на стеке точки входа в деструкторы ещё сохраним? Тоже вызовутся ведь. А серьёзно, вопрос не о том, как это можно сделать, вопрос о том, ПОЧЕМУ ТАК.

Потому-что Account* не содержит информации о том, ссылается он на один объект или целый массив. А выдумывать тип "ссылка на динамический массив" особго смысла нет, так-как есть std::vector.

lsor · 5 октября, 2008

Не захламлять глобальное пространство имен.

В классе? Но если я ввёл переменную, значит она мне нужна.

Потому-что Account* не содержит информации о том, ссылается он на один объект или целый массив. А выдумывать тип "ссылка на динамический массив" особго смысла нет, так-как есть std::vector.

А вот этого я, как пользователь языка, вообще знать не желаю. :) Я назначил как массив объектов. Вот пусть компилятор и думает за меня. ;)

А std::vector коряво выглядит. Да и я может, stl и использовать не желаю? Я вообще, так и свою могу написать библиотеку.

Изменено 5 октября, 2008 пользователем lsor (смотреть историю редактирования)

Solanacean · 5 октября, 2008

Вот из Википедии:

В английской статье на той же википедии написано, что язык мультипарадигменный, т.е. поддерживает разные модели программирования, включая объектно-ориентированное. Я только одного не могу понять: причем здесь ООП, если речь шла о указателях? =)

А я про паскаль под Mac OS и не слышал... бывает ли он вообще?

Тот же самый вопрос собирался задать вам.

А у Вирта они были? Я не помню, но вроде как и нет.

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

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

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

P.S. Не заметив вашего последнего сообщения, слегка дополнил свое предыдущее.

Изменено 5 октября, 2008 пользователем Gishi (смотреть историю редактирования)

lsor · 5 октября, 2008

Я только одного не могу понять: причем здесь ООП, если речь шла о указателях? =)

На самом деле, речь шла о том, у кого синтаксис кривее. :)

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

Возможно, это дело вкуса. :)

Mitea · 6 октября, 2008

В классе? Но если я ввёл переменную, значит она мне нужна.

class MyClass

{

static int FreeUID;

};

int FreeUID;

Если сделать MyClass::FreeUID не static, а глобальной переменной - будет ругань от компилятора. А MyClass возможно прицепляется через #include и гадать что там за переменные наобъявляли - абсолютно лень.

Mitea · 6 октября, 2008

В классе? Но если я ввёл переменную, значит она мне нужна.

class MyClass

{

static int FreeUID;

};

int FreeUID;

Если сделать MyClass::FreeUID не static, а глобальной переменной - будет ругань от компилятора. А MyClass возможно прицепляется через #include и гадать что там за переменные наобъявляли - абсолютно лень.

niiro dzyaki · 6 октября, 2008

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

Писал, много. С асмовскими вставками, чистый дельфи для этого не очень эффективен.

Или попробуйте написать что-то с использованием WinAPI.

Читайте исходники VCL до просветления. Хинт - самому также надо обвязать компонентной абстракцией и все.

И задача передо мной стояла не совсем прикладная, если вы не обратили на это внимание.

А нахрена, извиняюсь, микроскопом гвозди забивать? Либа на С + интерфейс к ней на Дельфях = сщастье

между тем Delphi налагает на операции с указателями совершенно правильные ограничения

Починено.

Указатели - потенциальная ошибка. Попишите програмки строк на 50000, поймете.

Delphi стоило бы сделать полную внутреннюю обвязку Win API с уровня паскаля

Так сделано же. VCL.

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

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

Т.е. вам не кажется, что
Код
sIn.Read( pMem^, sIn.Size );
это редкостный изврат

Нет.

Можно подробнее?

p:=Pointer(Integer(p)*2-10);

Боюсь, что они этому самому Delphi чужеродны напрочь. И ввели их в угоду необходимости в спешке.

ВВели их как и goto, для тех 5% случаев когда с ними проще, чем без них.

Solanacean · 6 октября, 2008

Писал, много. С асмовскими вставками, чистый дельфи для этого не очень эффективен.

Замечательно. Указатели это потенциальная ошибка, а ассемблерные вставки (в которых у вас к тому же наверняка используются те же указатели) - нет.

Указатели - потенциальная ошибка.

Массивы - потенциальная ошибка.

Попишите програмки строк на 50000, поймете.

Мне не очень нравятся ваш менторский тон и ваша непонятная уверенность в том, что вы один Д'Артаньян, а все кругом - идиоты, не писавшие ничего серьезнее "привет, мир". Я сам, к слову сказать, не сторонник бездумного использования указателей, но в некоторых случаях указатели = самый простое и вместе с тем эффективное решение.

Нет.

Все с вами понятно, вопросов больше не имею.

p:=Pointer(Integer(p)*2-10);

Благодарю.

niiro dzyaki · 6 октября, 2008

Указатели это потенциальная ошибка, а ассемблерные вставки (в которых у вас к тому же наверняка используются те же указатели) - нет.

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

Массивы - потенциальная ошибка.

Массивы - более высокий уровень абстракции. Соответственно, область применения уже, разнообразие ошибок меньше, отслеживать их проще. На самом деле, с массивами достаточно:

var
 i, j : Cardinal;
 Matrix: array [0..MAX_COLS, 0..MAX_ROWS] of Integer;
...
try
 // работаем с массивом
except
 // оба-на, тут мы знаем, к какому некорректному элементу пытались обратиться
end;

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

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

lsor · 6 октября, 2008

class MyClass
{
static int FreeUID;
};
int FreeUID;
Если сделать MyClass::FreeUID не static, а глобальной переменной - будет ругань от компилятора. А MyClass возможно прицепляется через #include и гадать что там за переменные наобъявляли - абсолютно лень.

Вопрос не о том. Вопрос о том, почему копия FreeUID не создаётся для каждого объекта класса, а одна на всех.

Так сделано же. VCL.

Но разве VCL покрывает все функции Win API? (Сорри, но я не использую среды типа "кое-как, но работает", я под Windows пишу на VC6 и MFC+Win API, потому очень плохо знаком с VCL, но вспоминается, что там не все API функции представлены)

Мне не очень нравятся ваш менторский тон и ваша непонятная уверенность в том, что вы один Д'Артаньян, а все кругом - идиоты, не писавшие ничего серьезнее "привет, мир". Я сам, к слову сказать, не сторонник бездумного использования указателей, но в некоторых случаях указатели = самый простое и вместе с тем эффективное решение.

Ну ругаться-то зачем? ;)

А вообще, есть одна проблема: серьёзных программистов на самом деле чёрта-с-два сыщешь - в основном "специалисты" по SDK попадаются. Всё-то они знают о всех конструкциях и структурах makefile и настройках компиляторов, но вот доходит до дела и все их знания не помогают им, скажем, модифицировать программу для установки вечной жизни или разработать алгоритм анализа текста с использованием автоматов, или сделать игровую программу или ещё что. На самом деле, это большая проблема... Библиотечными функциями пользоваться умеют, а своё создать - нет, не научены. :angry: Вот что на самом деле грустно-то...

Solanacean · 6 октября, 2008

Массивы - более высокий уровень абстракции. Соответственно, область применения уже, разнообразие ошибок меньше, отслеживать их проще. На самом деле, с массивами достаточно:

Вы сейчас привели пример жуткого костыля и что самое забавное, сделали это упомянув уровни абстракции. Обработка исключений процессора это не абстракция от железа, а наоборот, самый что ни на есть низкий уровень. Все это элементарно реализуется на ассемблере путем установки SEH и VEH обработчиков.

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

Ваша мысль понятна. Я предлагаю другую аналогию: вместо пистолета (или что там у вас) пусть будет нож, поскольку нож - инструмент более широкого назначения. Так вот, программисту Delphi разрешают пользоваться пластмассовыми ножами, которыми нельзя порезать себе палец или кого-нибуть убить, но ни на что полезное, кроме намазывания масла на хлеб, они не годятся. Нужно ли говорить вам, что шеф-повар всегда выберет более эффективный и опасный инструмент? Вы считаете, что ему нужно дать по уху и вручить пластмассовый?

Ну ругаться-то зачем?

Вам показалось.

А вообще, есть одна проблема: серьёзных программистов на самом деле чёрта-с-два сыщешь - в основном "специалисты" по SDK попадаются. Всё-то они знают о всех конструкциях и структурах makefile и настройках компиляторов, но вот доходит до дела и все их знания не помогают им, скажем, модифицировать программу для установки вечной жизни или разработать алгоритм анализа текста с использованием автоматов, или сделать игровую программу или ещё что. На самом деле, это большая проблема... Библиотечными функциями пользоваться умеют, а своё создать - нет, не научены. Вот что на самом деле грустно-то...

Не уверен, что правильно понял высказанную вами мысль, поэтому не могу в полной мере разделить вашу грусть, но, раз уж вы решили поделиться наболевшим... У меня легкую грусть вызывает то, что развелось много "тепличных" программистов, для которых компьютер и ОС этакие черные ящики. Они не знакомы с архитектурой машины, никогда не нюхали ассемблера (конечно, работать на нем не обязательно, но знать все же полезно) и не имеют представления о WinAPI, не говоря уже о каком-нибудь Native API. К услугам таких программистов готовые компоненты и библиотеки - элементы конструктора, опять же черных ящики для построения программы. А с другой стороны, если хорошенько подумать, может и не нужно все это прикладнику? Как не нужно системщику, например, умение писать игровые программы.

разработать алгоритм анализа текста с использованием автоматов

Вы работали с lex/yacc? Вопрос никак не связан с основной частью моего сообщения.

Войти

С, С++, Pascal, Basic, Assembler и другие языки программирования, hex-редакторы

Рекомендуемые сообщения

lsor

Топ авторов темы

Популярные дни

Топ авторов темы

Популярные дни

ALF_SS

lsor

ALF_SS

lsor

samuran

Solanacean

lsor

niiro dzyaki

Mitea

Solanacean

lsor

Solanacean

lsor

Mitea

lsor

Solanacean

lsor

Mitea

Mitea

niiro dzyaki

Solanacean

niiro dzyaki

lsor

Solanacean

Присоединяйтесь к обсуждению

Обзор

Активность

Важная информация