Работа сис программистом.. Стоит ли?

Вы меня не поняли. Люди изучившие х86 асм и С 20 лет назад так на них и пашут. Находят применение и дос низкоуровневики. А сколько с тех пор поменялось всяких супертехнологий? Что такое OWL знаете? Не так давно накрылось кстати. А умерший, хоть и не закопаный пока MFC? Та-же участь ожидает и решетку, ибо МС она до фени. Главное бабло на рекламе рубить. Более блестящую 'технологию' стянуть где получится, забросят решетку, ибо сами понимают - голь это. На одной рекламе держится.

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

 

Неплохо в Москве получают настройщики/внедряльщики систем CRM / ERP.
К примеру средний внедренец SAP R3 в Москве имеет 70-80 тыс. руб. в мес.

Продвинутый внедренец с опытом 3-5 лет. в серьезной конторе около 100 тыс. руб. в мес. + бонусы в конце года.

 

buktak
Да PHP и C (НЕ C++). А в свободное время gcc скрещиваю с асмом (вейвлет преобразованиями занимаюсь, наработками заинтересовались в Intel и nVidia, вот довожу до ума).

Да у меня вообще сейчас пусть медленно, но идет разработка компилятора своего языка - опыта программирования у меня не весть сколько (примерно 8 лет), но некоторая нелюбовь к "высокоуровневым" языкам сложилась. Но речь не об этом. Что такое OWL и MFC естественно знаю. А вот встречный вопрос: про алгоритмы разрешения конфликтов в Clips вы знаете? Вопрос правда риторический - не *** меряемся. А так совершенно согласен, что все эти "супертехнологии" в скором времени отомрут, как ненужные придатки. Если что и выживет, то это будет вариация Java - уж больно широко распространилось (хотя мне совершенно не понятно почему нравится, тот же deprecated на каждом шагу...).
Вообще многие технологии со временем показывают свою непрактичность и ограниченность, да и даже во время пика популярности используются только в своих областях. А системное программирование может все Мне, кстати, в свое время было в новинку применять COM на асме. Но ведь работает! Системщик может написать любую прикладную программу, вопрос лишь в затраченном времени. А вот про "высокоуровневого прикладника" обратного не скажешь. У меня есть 2е знакомых, которые считают себя крутыми "кулхацкерами" только потому, что могут кинув компонент TSuperPuperMegaZip на форму в Delphi "написать" классный архиватор. Я конечно утрирую, но один из них неплохо зарабатывает прикладным программированием.

Я сам не сказал бы что системщик, скорее программист, предпочитающий писать максимально быстрый и небольшой по объему конечного файла код. Естественно, из этого выходят условия использования голого компилятора C/Asm и несколько большее время на написание программ. Но результат себя оправдывает - программы в несколько десятков/сотен Кб. Но вот у нас в городе, я так и не нашел, кому это реально нужно: или ты программируешь на C#/1C/PHP, или работаешь с БД. Даже когда работал на оборонку, и то писал на Pascal Так что вопрос выбора пути развития зависит не только от нравится/денег хочется, но и от того, есть ли вообще возможность заниматься в том ключе, который был выбран.

 

Весьма интересно. А взглянуть можно?

Не старался сказануть что-то такое. Просто пример: больше рекламы - круче обломы. А насчет Clips - не знаю что это.

паскаль - тоже неплохой язык. Особенно современные потомки.

 

Предпринимается попытка отойти от структуры столь популярных C-подобных языков в плане чрезмерно перегруженного синтаксиса и возможности допускать логические ошибки (код STL как пример плохого кода и ==, как общеизвестная лог. ошибка). Вместе с тем, я серьезно проработал множество существующих языков системного программирования (как учебники по языкам,так и BNF, какие мог найти), посмотрел плюсы и минусы, внес свои коррективы.
Наиболее близким по семантике будет, пожалуй, PHP. Но у меня транслируется в x86 asm (пока что) из дага разобранного кода. Сейчас проект на уровне парсинга основных конструкций языка, плюс ведется активное обсуждение с друзьями по поводу пожеланий к синтаксису, структуре и функциональным возможностям языка. Когда будет более-менее рабочая версия, которую не стыдно показать - выложу где-нить все исходники. Пускай отправляется в свободное плавание (ессно, я буду работать дальше, ибо еще нужна раскрутка компилятора). А то хочется программировать на языке, который был бы действительно удобен и соответствовал современным требованиям (к примеру C-like строки архаизм, ИМХО. Лучше добавлять в строку ее длину, чем искать конец строки. Хотя SSE4.2 делает такой поиск в один такт ).

Про рекламу согласен - у самого аналогичное мнение. Главное не реклама, а реально проверенные временем средства.
Clips - язык (и он же среда разработки) для написания экспертных систем. Довольно широко применяется. Разрешение конфликтов применяется в случае, когда несколько правил должны выполнится на данном шаге. Но это так, для общего образования, если интересно.

ИМХО он лучший. Модула-2 особенно нравится. Язык явно продуман и нацелен на понимание и простоту программирования ( как написание своего кода, так и изучение чужого ). Да, в нем есть некоторые "переборы", которые так нравится приводить сторонникам "сишника" (then begin end; implementation; function/procedure), но не будем вспоминать все минусы самого C/C++ Про Паскаль я написал в контексте того, что у нас мягко говоря не особо нужны программисты на C/Asm. В основном требуется уровень не "ниже", чем знание VCL в BCB, ну и заодно MFC/STL.

P.S. Материалы Вирта по анализу как его, так и сторонних ЯВУ повлияли на разрабатываемый мною ЯП.

 

А нельзя-ли взглянуть на выделеное?

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

Мне очень нравится оберон/блэкбокс за красивую компонентно/объектную реализацию. Кроме того блэкбокс имхо наиболее интересная на сегодня РАД система.
Что не нравится. Слабая практическая направленость (зарабатывание денег) того-же блэкбокса (обсуждалось в соседней ветке). Ну и очень растянутый синаксис

К сюда 'var ai: array 34 of array 63 of integer;', и в особенности к сюда ':='. Для студентов самое то. А вот мне охота полаконичнее чего-то.
В настоящее время из паскаль-образных синтаксисов мне больше всего по душе луа-вский. Когда время есть слегка дописываю его до компилятора с динамической и принудительной типизацией, компонентной системой, несколько расширеным синтаксисом и возможностями (ссылки) и возможностью морфирования языка. Потому и интересуюсь вашими наработками. Реклама у вас ничего..

 

_basmp_
Ну, во первых, как-то мы не в той ветке разговор завели. Как бы ее не закрыли, а то мы совсем отклонились от темы. Чтобы немного вернуться к теме, напишу, что у нас в городе "оператор станка" (формулировка из рекламы) получает от 18тыс. Кто еще хочет программировать за 10тыс?

А теперь по существу

Я же написал, что сначала хочу до ума довести.
А так, синтаксис подразумевает оформление отдельных структур языка (типов переменных, функций, структурных элементов, и т.п.). Например вызовы функции test( a, [1, 2, 3, 4], , c ) или методы встроенных объектов "Hello, World!".length.
Структура подразумевает объединение отдельных блоков в единое целое (тут тебе модульность и межмодульные связи, области видимости переменных). Сюда же можно отнести попытки избавиться от вариаций goto/jmp и т.п. - метки циклов для выполнения break/continue на более высокий уровень и т.д...
Функциональные возможности: RegExp при работе со строками, встроенные типы вектора (динамические массивы) и хеши (со строгой типизацией правда, пока не знаю как эффективно работать с нетипизированными данными, да и не вижу особого в этом смысла для системного языка).
Далеко не все из этого сейчас реализовано - мало времени удается уделять, но я упертый

Не будем тут устраивать разборки, ибо мне не нравится подход SZ-строк. А насчет изменения длины. Вроде как WCHAR-строки хранят в себе не только длину данных, но и плюс длину реально выделенной области памяти (первоначально +4 байта что-ли). Чем не решение? Лишние 4/8 байт (для 32-битных платформ вполне хватит) или постоянные вызовы strlen для строк в сотни КБ? Сразу хочу сказать, что речь о коротких строках не идет (тут просто 2 байта на длину и далее сама строка). Да и то, только для строк, которые изменяются.

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

Да? А как же великая и ужасная инструкция ==. Она что, лаконичнее =? Нет. Понятнее? Нет. Предохраняет от логических ошибок? Аналогично нет. Мне больше нравится подход Вирта: :=, =, #. Понятнее и гораздо ближе к математике. Может потому мне и понятнее?
C/C++ тем и плохи, что во имя лаконичности отвергнута простота и понятность. Вот например, как в C++ описывается процедурный тип? У.... Я очень долго не мог запомнить typedef void(TYPE*)(....) и т.п.

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

 

Xerx

дык
заложите в Ваш фундамент несколько видов(типов) строк. каждый выберит для себя своё

 

По теме ветки: Много раз работал на неинтересных мне, хоть и денежных работах, не два еще работать буду. Но долго заниматься нелюбимым делом хоть и за большие деньги не могу. Крыша едет. Желание жить куда-то девается. Тоска жрет. Сам не понимаю как перестаю заниматься работой, а вместо этого паяю что-то или прогу пишу на бумажке.. ИМХО занятие денежной, но неинтересной до тоски работой причина появления очень интересных опенсорсных проектов.

Xerx

Такое уже есть в луа

Код (Text):

1. test(a,{1,2,3,4,"kluch"="value"},c)
2. s="Hello, World!"; print(s:len());
3. print(#s); print(#"123");   // # -- универсальный оператор длины
4. s:gsub([[[\\/]+]],[[/]]);   // замена по шаблону
5. s:find('^[[:space:]]*_');  // поиск по шаблону

при быстром написании динамическая дипизация - золотая вещь

Я с вами не спорю. Просто замечаю, что иногда в строках очень удобно организовывать байтовые массивы. Кроме того не говорю, что длину надо считать постоянно. Она хранится и переписывается только при изменении строки. + все остальное, что я писал. Работает очень быстро и для мегабайтных строк и по ссылке - прямой доступ к строке.

два раза нажать на одну кнопку все-же проще, чем на 3 разные ':=' причем оператор '==' встречается относительно редко, а вот ':=' в каждой строке. Единственая проблема - это логические ошибки - это серьезная проблема. Из-за нее я стараюсь не пользоваться '=='. Вместо него использую вычитание ('-').

Думаю это дело вкуса. Я в свое время перешел с паса на С не только из-за лаконичности, но и из-за наглядности и большей гибкости и возможностей. Но это вкус у меня такой. К примеру одно время я писал на одном ps.

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

wsd

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

ЗЫ с блэкбоксом ошибочка вышла. Только-что нашел как ехе и dll-и делать. Осталось объектники и либы научиться делать/юзать.

 

Это и планирую: стандартные строки, изменяемые по длине редко, но перевыделением памяти и часто изменяемые по длине с двойным счетчиком (дина+выделение памяти). Нагрузка на компилятор ненамного больше, а вот конечной программе это хорошее подспорье. А вводить больше 2х типов - это да, явный перебор. Вообще, нужно максимум работы переносить на этап экспорта, т.е. создания конечного продукта.

Тоже довелось так работать, например с FoxPro. И основываясь на полученном опыте - совершенно согласен.

Я этого и не отрицал. Но ведь они есть и в PHP, и в JavaScript, и в Java, а в Perl/shell они вообще встроенные на гораздо более высоком уровне (не как методы объектов, а как операторы самого языка).

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

А в чем проблема с такими строками? Как Pascal, так и Delphi при выполнении @str дают адрес первого символа. А @str-2 - адрес счетчика длины. Все очень легко и понятно.

Где она хранится? Это известно но компилятору? А если я буду передавать адрес символа в строке некоей рекурсивной функции? С этим компилятор вряд ли справится, если только у него не будет ОЧЕНЬ мощной и качественно смоделированной эвристики. Либо я не правильно понял.

Вот, а я хочу сделать язык минимально подверженный логическим ошибкам. Во имя этого я избавился от goto, && и &, ==, нелогичных названий типов вида integer и long и т.д.

Возможностей больше, лаконичнее (черезчур). Вот я и писал с самого начала, что, взяв за базу C-подобные языки, разрабатываю некий более гибкий и вобравший в себя множество "полезностей" и оригинальных решений из других языков. Естественно, с точки зрения ИМХа.

Ай, яй, яй! Конкурент

 

Xerx

cord и ecord из Boehm GC?

Сильно много хорошо тоже будет плохо. В свое время я прошерстил все эти языки. Lua имеет минимально-достаточный лаконичный (только чуть растянутее чем у перла) паскальподобный синтаксис с наследуемыми объектами и морфируемыми операторами (=, +, -, ., *, #, and, .., итд) при максимальном быстродействии при минимальной длине (один exe ~150Kb) с возможностью легкого встраивания. Кроме того, зачем производить регулярный поиск в массиве или числе?

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

Замечание верное. Видимо эту возможность следует учесть при планировании типа и его обработчиков, те в описатель ссылки на строку кроме адреса ссылки ввести адрес описателя строки и при записи по ссылке корректировать при необходимости и параметры строки и адрес ссылки. Кроме того, при первом изменении строки увеличивающем выделеную добавлять память выровненую по границе страницы (или двух).

goto пытаются убрать начиная с конца 60х. Сперва уберут, а потом возвращают. Кроме того метки полезны для навигации и описания сорцов, а так-же для связи со встроеным асмом. && и || стоит заменить или заалиасить с and, or, +xor. Битовые &, |, $ пусть остаются иначе новая коллизия. От ошибок по '==' можно избавиться запретив присвоение в 'if()' некрасиво, но что делать.. Int, long и проч. как базовых стоит заменить на int8,int16,int32,... и uint8, ... Точно также и с float-ом float32, float64, float80 итд. И обеспечить аналог типедефа.

Коллега!

Взгляните сюда http://wasm.ru/forum/viewtopic.php?id=26424 и выскажите свое положительное мнение.

 

_basmp_

Не знаком, линк сохранил. Почитаю, отпишусь что думаю.

Многовато для системного языка. Думается, там много всего кроме необходимого уровня линкуется (RTTL, и т.п.).

А кто об этом говорит? Речь о применении регулярок только при работе со строками (именно строками! указатель на массив байт уже не подходит). Эта проверка при разборе грамматики в синтаксическом анализаторе.

Можно пример? Если при любых операция со строками происходит или приведения операндов в строку или парсинг строки в другой тип ( str += '123'+456+78.9; или i = j + "8"; ), а перевод из указателя в строку возможен только с созданием нового экземпляра класса строка с копированием памяти?

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

Описание часто делают через ToDo или /** **/ как выделение значимого комментария. Навигация... Что под этим подразумевается?

У меня несколько другой подход: and / land, or / lor (or & Logical or) ну и т.д.... Правда лог. отрицание это !a, а побитовое - ~a. Несколько скользкое место.

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

Опять же у меня немного другой подход, более близкий к ассемблеру: byte/ubyte, sbyte, word/uword, sword, ... sdword. Таким образом можно вводить qword, tword и т.д. Плавающая точка аналогично, только не float, а real (но это уже незначительные мелочи).

Мне очень НЕ нравится реализация typedef в C/C++. Особенно, когда еще и struct всовывают. Все таки подход Ada-подобных языков лучше, ИМХО.

Положительное, хм... За меня уже все решили. Но, собственно, я и не против.

 

Низкоуровневое программирование (в том числе драйверы) рулит! Поскольку программистов бизнес-формочек и всяких БД навалом... А вот низкий уровень очень редок из-за того что там надо больше знать и дольше этому учиться.

Вот у меня вопрос в другом - если уже железно решил посвятить себя сис. программированию, то в каких направления специализироваться?(драйвера/микроконтроллеры/ ???) Какие технологии изучать, чтобы состоятся системным программистом? (в силу того что язык это не главное, а главное это технологии(COM/ATL/CORBA, но это наверное не для сист прог-ния, незнаю...))
Язык дело понятное – ASM/С/С++. А вот технологии, какие нужны ума не приложу.
Просто ж пора уже начать специализироваться в каком то направлении, а то к окончанию Вуза, не буду знать, куда податься. Вернее я знаю куда хочу – быть системным программистом в силу своих способностей , просто тут тоже есть разные направления (драйвера/системы реального времени(QNX) и т.п.). А в каждом направлении, есть свои технологии. Может где то можно прочитать про это(я пока ненашел, вот и решил обратится). Меня пока привлекает написание драйверов , возможно есть еще какие либо направления которые мне будут по душе.
Сам неплохо знаю С/С++ и WinAPI (GUI и сист. прог-ние в Windows(процесы/потоки их синхронизация и тп)), ASM пока не трогал, но нутром чую нужно
Осталось взятся за дело и начать что то делать, токо что...

 

Это со всеми языковыми библиотеками, мусорщиком, компилером, оптимизатором и виртуальной машиной (Луа возможно самый быстрый из интерпретируемых языков). Ну и либС конечно (язык мультиплатформеный).
Учитывая воможности Луа и отсутствие всяких внешних dll-ей, это ИМХО не много. Кроме того у него логичные и понятные сорцы.

Это пример того, что выносить в языковые конструкции стоит не все.

можно

Код (Text):

1. string s1,s2="stroka";
2. int8* bytes;
3. bytes=&s2;
4. ...
5.     bytes[i]=...;
6. ...
7. &s1=bytes;

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

это и есть динамическая типизация. При чем 1+"123" может быть понято и как 1+123, и как 1+&"123".

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

Под навигацией понимается левая колонка в SourceInsighte и аналогичных редакторах. Вынося описания на метки получаем исключительно удобную навигацию. Так, что комменты становятся практически не нужны.

немного критики если позволите. and и land итд достаточно мало отличаются друг от друга и возможна та-же ошибка, что и у '=' и '=='.

На мой взгляд длинно и не наглядно. В асме все эти байты/ворды находятся по исторически-традиционным причинам (длина байта и ворда в старых машинах бывала и 4 бита и 7 бит и 18), а не из-за удобства. К примеру в новых разработках и в самих С-шных ашах уже давно применяется формат: тип(целое, дробное, знаковое, беззнаковое ...) + разрядность. В идеале компилер сам должен парсить конструкции типа int64 или real80 и создавать переменную указаного типа и разрядности или выдавать ошибку если это невозможно.

 

ИМХО

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

Туда где деньги платят и где вас примут. Это не от знаний зависит, а от вашей 'харизмы' (то-бишь хавайте получше, не напрягайтесь и учитесь улыбаться по карнеги). А-а забыл торговаться учитесь обязательно.. И енгиш с дойчем и фрэнчем. Чинезе и жапан - суперплюс.
Все остальное вам работодатели скажут.

QNX очень интересная система. Особенно ее драйвера. Тем более, что сорцы открыли. Думаю вам стоит на http://qnx.org.ru сходить.

При отладке (самая важная часть програмления) без асма вам будет тяжело, если вообще возможно.

sf? gnu? Тут ветка 'Projects'? На qnx.org.ru, раз вам qnx по душе, есть интересные публичные проекты. Ищите, что нравится. Предлагайте помощь. Или вы хотите без опыта сразу на в/о работу?

 

Я имел ввиду пример не такого плана, а где происходит изменение длины строки. Да и данный пример представляет из себя интерес разве что только в последней операции: &s1=bytes;. Все остальное совершенно прозрачно. А данная инструкция потенциальная дыра: я так понимаю происходит связывание (или копирование?) адресов. Но если терминальный ноль был потерт вызовами bytes=...;, то что присвоить строке в данном случае?

+и как "1"+"123". Это зависит от того, К КАКОМУ типу все будет приведено в итоге.

Вот вот, как раз мой вопрос по инструкции &s1=bytes; Жду ответа. А мой вариант - присвоил адрес строки указателю, то получил просто указатель на массив, и для получении строки обратно одного этого указателя мало, еще длина нужна - точно сработает. Ограничения? Пока не вижу: алгоритмы обработки строк как линейных векторов вроде как не меняют их длины.

Это лучшее, что я пока придумал. Есть вариант лучше и нагляднее?

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

Насколько я понимаю, сис. программирование любят не вообще, а из-за того, что в выбранной сфере деятельности решить задачи можно только этим самым сис. программированием. В свете этого я не понимаю всей глубины вопроса "люблю, но не знаю, что делать". Я к этому пришел именно по необходимости, а не потому, что я такой крутой, что "у меня прога юзает только kernel32.dll и весит 70КБ"

Ну зачем же так критично. Мне довелось немного шаманить с МК на машинных кодах в bin-образе прошивки (другого способа не было) и не так давно что-то с PIC вариантом Pascal было. Даже вроде о вариациях Бейсика для МК писали в Радио.

Чувство, что просто чешется программировать, все усиливается. А это "не есть хорошо", ибо есть у меня похожий знакомый. Так мне его даже жалко...
Так что учиться, учиться и еще раз мучиться! А потом уже на своем небольшом опыте разных областей выбрать то, что больше нравится. Ибо, как я понял из поста, сейчас еще идет учеба, так что время попробовать себя в разных направлениях еще есть.

 

Не совсем. При первом присвоении надо учесть информацию находящуюся ниже ссылки, bytes=... все хорошо пока (&(bytes)-bytes) <= s1:len(), обратную ситуацию надо учесть обязательно. И в плане памяти и в плане длины вектора. Последняя операция прверяет последний байт по смещению bytes:len() и если он не 0 добавляет еще один байт с 0. В таком случае не получится, что:

Как я писал выше ссылочный тип должен быть сложнее обычного int32. То есть:

Код (Text):

1. typedef struct {
2.     int32  VarType;           //тип этой переменной
3.     int32  ObjectType;       //тип перем. на кот. ссылаемся
4.     void* ObjectDescriptor; //указатель на структуру-описатель ссылаемого объекта
5.     void* Adress;              //или Offset. Есть свои + и - в обоих случаях
6. } pointer;

при динамической типизации как правило приводят к типу первого операнда: 0+"1"==1, "" .. (2+5)=="7"

Не понял.. В примере я просто хотел показать случай, когда нужен прямой доступ к строке и выгода от указания ее длины перед строкой == 0. Кроме того ВинАпи, ЛинАпи и большинство других Апи и библиотек хотят С строки, те Пас перед посыланием строки в такую либу должен будеть сконвертить ее в С стиль (например просто дописать 0 в конце).

Пока не выходят за выделеную память. Как решить вопрос я написал выше по посту.

Ну например логические в пас стиле (and, or, xor,(! или not)), а битовые в С стиле (&, |, $, ~) или наоборот.

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

Код (Text):

1. int32 i;
2. int32 c;
3. i = 1234567890;
4. ...
5. c = (int8)i;
6. i >>= 8;
7. ...

и комбинация <ТипРазрядность> имхо самое то.

но с другой стороны это нехильное развлечение и дает массу полезного опыта.

МК - это МК61?

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

 

А зачем? Если программа вышла за пределы выделенной памяти - это проблемы автора программы и компилятор/полученная программа не обязана "расширить" строку до нужного размера. Ведь для того и инициализировалась bytes, чтобы просто обращаться к символам строки, рассматривая их не как вектор байт.

И это должно храниться и обрабатываться уже в конечной программе? Зачем же так сложно?! Просто была строка, мы получили указатель на символы в ней, как-то их обработали и все. Обработка выхода за пределы интервала это, как я уже писал, работа программиста. мини зы: возможно мы сравниваем два языка с некоторой разницей в уровнях представления данных и мой вариант более низкоуровневый.

Ну да, я не то написал, согласен. Мне приведение видится наиболее логичным к типу левого операнда в инфиксном операторе (подчас это совпадает с предложенным вариантом. но не всегда!)

WinAPI и LinAPI писали под ОС, на каком языке написанные? На C. Сторонние библиотеки также пишутся в совместимости с ядром системы (чтобы меньше телодвижений было при вызовах). От этого не отойдешь, но и подстраиваться я не хочу.

Ну и я также выше уже отметил, что не вижу тут проблем для компилятора.

А не будет ли это еще хуже, особенно при переходе с других Pascal/C-подобных языков? Как бы не возникла каша в голове. Да и использование такой смеси символьно/знаковых операторов мне видится не лучшим примером.

Если на чистоту, то у меня в исходниках компилятора типы называются U8, S32, F16

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

Нет, МК - это МикроКонтроллер в самом широком смысле.

[ИМХО] Лучше найти не пыльную денежную и не сильно "высокоуровневую" работенку. А для себя и других программить уже как хочется. Как вариант для diver85. Например сайтики писать на PHP/Perl (НЕ НА C#), или прикладное ПО на Delphi (ай, яй, яй, не бейте меня палками ). Главное, чтобы тоже было хоть немного интересно и оставалось время на любимое занятие.[/ИМХО]

 

Горький опыт показывает, что автоматический контроль за массивными/ссылочными/строчными операциями в 'быстрых' ЯВУ просто необходим. Это избавляет от очень большой головной боли. Хороший пример вы приводили выше. Кроме того, код получается не больше и не медленнее. Тк если нет автоматического контроля, программист должен будет делать его сам. А автомат заоптимизировать можно сильнее. Кроме того, сорцы избавятся от большого количества технических деталей, что сделает их значительно читабельнее.

Переменные в современных интерпретируемых или просто ориентированых на надежность языках организованы еще сложнее. Не раз уже я использовал такой подход. И скажу я вам он очень оправдан. Кроме того, что он предохраняет от случайной порчи не относящейся к делу памяти, от записи и считывания по неверному адресу. Он защищает и от следующего момента:

Код (Text):

1. a="123";   // typeof(a)==string
2. b=&a;
3. ...
4. a=23;      // typeof(a)==number
5. ...
6. b[3]='5';  // трудноуловимая ошибка

Меня интересует компилируемый язык пригодный для очень быстрых разработок. Считаю что такой язык должен иметь минимально необходимый синтаксис, быть достаточно лаконичным и простым, достаточно легкочитаемым и гибким (слегка дополненый синтаксис Луа вполне подходит). Он должен обеспечивать и динамическую и точную типизацию. Он должен обеспечивать достаточную рантаймовую защиту по работе с любыми видами буферов и ссылок. Возможность изменять приоритеты (защита/скорость) для участка кода. Иметь встроеный ассемблер. Иметь возможность морфирования синтаксиса для участка кода. Иметь перегружаемый парсер (возможность копипастить юзать С или пас код к примеру) для участка кода. Впоследствии модульную систему по типу оберона. Наметки кусками уже есть.

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

Вот-вот удобно, правда? Только я бы назвал их чуть поразвернутее.

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

Почему вас надо бить? Для быстрых халтур Дельфи и Билдер очень даже подходят. Многие их юзают. Однако, я считаю, что на сегодняшний день, наилучшая РАД система - блэкбокс. Не знаю, правда, что там с лицензией для коммерческих применений. Кроме того я хочу РАД под себя. Язык о котором я писал выше - компилер для нее. Отсюда например требования к защите по памяти (РАД системе - РАД язык).

 

_basmp_

а есчо хотелось бы, чтоб по щучьему велению работал)))) лаконичность кода и функцианальность вещи несовместные.