Столкнулся с такой проблемой - оказывается нормального языка (компилируемого), который не требует потом кучу библиотек нет.
Исключение с(с++)+например QT не рассматриваю по религиозным соображениям.
В поле зрения попали компиляторы языков D и vala - vala все равно зараза тащит gtk. А d просто настолько сырой - нет нормальной ide, да че там документации элементарной и то нет...
Вообще есть нормальный язык - с чистой компиляцией без кучи (нужных) библиотек ?

(154) Это вы еще линковку по-нормальному не настроили. Тот же C++ для встраиваемых устройств (MS eMbedded C++) пустое окно может создать заняв всего 7 кБ. То же самое можно сделать и с обычным Visual C++, только надо правильный def файл создать.

(155)то был билдер и 2003-й год. я мог сейчас и соврать.

Окно авторизации, главное окно, всякие загрузки и сохранения системных настроек со стропроцентными проверками всех ситуаций, конвертация и определение языковых файлов, создание рабочих каталогов, протоколирование (по размеру, либо разделение по дням, понедельно или помесячно). В ресурсах с десяток иконок и языковый файл по умолчанию. На все про все 56 кб. Всего строк 2300 (с учетом всех комментариев и пробелов)

(152) окно и пара кнопок с обработчиками нажатий

(158) Фигово. Для больших вещей надо будет требовать большие компы. Немного не в пользу

Во! В пользу PB. Одна парочка компонент:
"Scintilla это бесплатный компонент для редактирования исходного кода. Он поставляется с исходным кодом и лицензией разрешающей использовать её в любых бесплатных или коммерческих проектах. Лицензия может быть найдена здесь. Исходный код и документацию можно найти на Scintilla Homepage."

Вот другая:
"Камеры используются, для отображения 3D-пространства. Ими можно управлять как реальными камерами (перемещать, осуществлять вращение, изменять угол обзора и т.д.). Необходима минимум одна камера render для отображения на дисплее. Много камер с различными позициями и положениями могут использоваться одновременно, которые делают возможными первоклассные эффекты как Splitscreen (полиэкран, для нескольких игроков), зеркала заднего вида и т. д."

Или вот:
"Привилегированный файл, содержит определяемые пользователем параметры программы. Он хранится на диске и загружается каждый раз при запуске программы (например 'файл.INI' в Windows ). PureBasic дает возможность создать привилегированный файл, используемый на любом компьютере (на различных платформах). Формат файла по умолчанию сохраняется в ASCII. Используя синтаксис одной строки 'ключ = значение'. Для удобства чтения, могут быть созданы группы."

(158) че то не понял, откуда такой вывод?
(160) у AutoIt тоже редактор на основе scintilla

(161) "че то не понял, откуда такой вывод?" мне казалось, что в 300 кб должно поместиться огромнейшее приложение. Нет?

(151) А чем FreePascal не угодил?
а Кросс-платформенный ( Linux, FreeBSD, Haiku, Mac OS X/Darwin, DOS, Win32, Win64, WinCE, OS/2, Netware (libc and classic) and MorphOS) + для множества аппаратных платформ ()Intel x86, Amd64/x86_64, PowerPC, PowerPC64, Sparc, ARM,
б Есть встроенный асм,
в Многие учили паскаль в школе / институте
г Есть три движка для GUI.
д В отличие от PureBasic (PureBasic — диалект языка BASIC и коммерческий компилятор для него. см. wiki:PureBasic и http://www.purebasic.com/index.php), FreePascal совсем открытый и бесплатный.
е И простой хелловорлд для командной строки компилится в 30 КБ, а небольшая программулина резервного копирования (тоже CLI) компилится в 32 КБ. Т.е., исполняемые файлы довольно компактны.

(163) ээээ... а графику на нем трудно ваять? Создать полноценное оконное приложение

+(164) А то для меня паскаль = досовская хрень для учебных целей и разработки абсолютно ни кому не нужных алгоритмов на БК000001 с 15 кб памяти

(164), (165) В средах Lazarus, FPgui надо просто накидать компоненты, а среда разработки напишет для реализации этих окон код, с вызовом нужных библиотек.

+(166) Я начинал с Лазаруса, а потом перешёл на более компактный FPgui, сейчас делаю внутренние утилитки.

+(163) сайты про фрипаскаль: freepascal.org, freepascal.ru

лазарус глючное УГ

А у AutoIt нет суперсложных примеров в поставке, поэтому не могу сказать, может оно и будет весить 350кБ.
Там примерно 300 кБ занимает движок, значит усложнение проги не будет вести к большому росту файла

(168)
"Создание файла программы

Основная программа состоит из четырёх обязательных частей:

   Создание и регистрация класса главного окна.

   Сначала заполняется специальная оконная структура типа WNDCLASS или WNDCLASSEX. Они содержат одни и те же поля, однако WNDCLASSEX имеет дополнительные поля:
       cbSize - сюда заносится размер WNDCLASSEX
       hIconSm - сюда заносится "маленькая иконка" приложения. Если маленькую иконку использовать не предполагается, то присваивается ноль.

   Скомпилированая с WNDCLASSEX программа имеет несколько больший размер.

   Главные поля класса:
       lpfnWndProc - сюда заносится адрес процедуры обработки сообщений главного окна программы.
       cbWndExtra - здесь, если диалоговое окно создаётся из ресурсов, должно присутствовать волшебное слово DLGWINDOWEXTRA.
       lpszClassName - здесь должно стоять название класса основного окна. Обращаю ваше внимание, что название должно быть точно таким же, как и название CLASS у того диалогового окна в ресурсе, которое будет главным.

   Регистрация класса проводится процедурой RegisterClass() для типа WNDCLASS и RegisterClassEx() для типа WNDCLASSEX.
"

ой нет, опять эти путанные повторяющиеся куски... нафуй-нафуй такое счастье

v8: Проблема - нет обновления

(171) Поверь, вот это ГОРАЗДО ламернее
v8: Периодические РС. Что быстрее: запрос или метод?

(172) а я на ассемблеры и не замахивался...
v8: Роль "ПравоВыводаИнформации" как работает в УПП - тут ваще человека в конфигураторе забанили, бгг

(173) И? Я и не скрываю, что многое не знаю. Задаю вопросы, когда полный все. Только вот это право помимо печати может еще на десяток мест повлиять, а делаю то из расчета, что бы не переделывать. Соответственно надо много доков читать, а когда загрузка большая, читаешь только выборочную литературу. Заметь, народ на других форумах отозвался и рассказал что к чему исходя из своего опыта. В итоге вместо того, что бы тратить туеву хучу времени, каждый поделился своим.
В (172) эксперимент ставится за 15-20 минут, в одной из веток тут делали. При чем народ замер в файловом варианте, на МС СКЛе и на ПГ СКЛе сразу сделал. 15-20 минут!!!!!! я просто не вижу вариантов, на чем можно запороться.

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

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

(174)
http://www.e1.ru/fun/photo/view_pic.php/p/83646fe0f9e043e7f6db6f55f153c770/view.pic.jpg

Мне вот что не понятно. Ну ладно, на с++ у автора аллергия. А старый добрый Delphi чем не угодил?

(176) не моё, напарники рассказывают, что у дельфи много устаревшего, а это уже минус. Еще раз, не моё, расскажи на сколько на нем просто делать нормальные приложения? Сегодня нач.юр.отдела очень крупной компании попросил дельфи7 и 9, а это уже настораживает

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

Так в любом компиляторе есть опция "static" которая позволяет все используемые библиотеки положить внутрь файла, кроме стандартных библиотек Windows.
Собственно говоря - чем это не устраивает ?

Делфи ХЕ2 вроде нормальный стал по сравнению с седьмым, но я например как-то уже не могу писать на делфи после дотнета. Неудобно и не в кайф )

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

(176)
вот что сие озночает ?

= *((unsigned **** *) d_addr->h_addr);

+(182)
что такое указатель на указатель указателя - и самое главное нахрена ?

(178) Меня голый ВинАПИ напрягать стал, старый наверное уже. Не, всякие точки нет не катят, т.к. слишком уж тяжелые и зависимые от кучи софта, кроме оси

(176)
зачем в дельфи антифриз и почему он криво работает ?

(181) А это как с фототехникой. Есть фотодрочеры, которые с пеной у рта долго и нудно выбирают тушку, объективы, режимы съемки... а в итоге шедевров все нет и нет :)

(182) А кто тебя заставляет такие конструкции использовать? Хотя тут ничего особо сложного и нет: значение h_addr (из названия следует, что это тоже указатель) приводится к типу unsigned ****, а затем разыменовывается. Т.е., это всего лишь чтение значения типа unsigned **** из адреса, на который указывает значение h_addr.

(185) Чтобы программы не перегревались :)

(182) приведение указателя к типу и его разыменование. Ничего сложного

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

(187)
нахрена его приводить к типу и разыменовывать ?

+(188)
вот а=2 - не проще такие конструкции использовать ?
или так круче ?
int *pa, a;
*pa = 2;
a = *pa;
pa = &a; // нах

(189)
Не переживай. Имхо примерно 90% людей совершенно не могут понять концепцию указателей. Это нормально.

(190)
я переживаю за эти бедные 10% :)

(188) Приводить к типу - потому что тип не тот, что нужен (например, void *). Ну а разыменовывать - чтобы значение, лежащее по адресу указателя, получить.

(190) а 90% из оставшихся 10 не вкупаются про смысл стека)))))))))

преимущества использования указателей (официально):

1) скорость выполнения программы.
2) удобство программирования.

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

(194) "скорость выполнения программы." это как? Либо просто пишем в переменную, либо сначала получить адрес переменной, а потом только писать. Разве это быстрее? Не, я может чего-то не знаю

(194) Издержки на индексирование абсолюно одинаковые что при A[5], что при *(A + 5) - в обоих случаях это преобразуется в 1 инструкцию lea, или вообще используется mov с косвенной адресацией.

(195) Т.е., думаешь прежде чем записать в переменную значение, ее адрес определять не надо? Такое только для регистровых переменных работает, а их в x86 весьма немного (максимум 8 РОН), и пара-тройка из них обычно занята для служебных целей.

(196) Нет справочника по тактам под руками. Лень искать. Честно. Но разве операция
mov    dword ptr [ebp+08], 1
будет дольше
lea   ebx, dword ptr [ebp+08]
mov    dword ptr [ebx], 1

или опять не правильно понимаю конструкцию? С указателями удобно работать, когда надо передать параметром куда-то и не более

(197) Современный компилятор для такого случая использует mov    dword ptr [ebp+08], 1 что для A = 1, что при *pA = 1. Более того, они могут использовать такую конструкцию даже в случае

DWORD *pA;
pA = &A;
*pA = 1;

если данное значение pA дальше не используется (например, для арифметики указателей).

Хотя для современных процессоров даже

lea   ebx, dword ptr [ebp+08]
mov    dword ptr [ebx], 1

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

(198) "не скажется на производительности, если в программе делается что-нибудь еще, поскольку lea исполнится задолго до того, как очередь дойдет до mov (параллельно с другими инструкциями)." Не скажется совсем или не скажется чуть-чуть?

+200

(199) Совсем. Тот же K10 от AMD имеет 3 блока AGU (на которых выполняется lea и вычисление адреса при косвенной адресации) и 3 блока ALU (которые, собтсвенно, произведут присваивание). 2 инструкции вместо одной скажутся только в сильно оптимизированном коде, где темп исполнения достигает 3 инструкций/такт - в этом случае декодер будет ограничивать скорость исполнения. Но такой код никакой компилятор не выдаст, тут только ручной хардкорный труд ассемблерщика. И при операциях с памятью 3 инструкции/такт практически недостижимы.

(194) вопрос терминологии. Указатели в том или ином виде присутствуют почти в любом ЯП.

(201) если эти две инструкции исполняются в вакууме, то возможно и не будет разницы. Но, если в коде, например, цикла десятки других lea и mov, зависимых друг от друга, то одиночный mov будет быстрее

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

А насчет десятков других зависимых инструкций - так задержки на доступ к RAM из-за произвольного доступа и низкой эффективности кеширования будут значительно выше возможной задержки от lea (и по факту она окажется скрытой). Даже хит L1D, не предсказанный заранее, вызовет задержку в 3 такта, хит в L2 вызовет задержку в 12 тактов, хит в L3 - около 60 тактов, ну а если не повезло и надо в память лезть - все 150-200 тактов.

Указатели удобны только для передачи массивов значений и для явного преобразования типов.
Например, я сложил в память всякую хрень, типа 01 45 56 32
А потом хочу достать два байта ((unsigned short*)p)[1] - и я получаю 0x3256
Другое дело, что можно сначала определить структуру, то есть составной тип, а потом его передавать по ссылке - это будет всем понятно - но - бывают ситуации, когда формат записи зависит от самой записи - тогда без указателей с ней работать очень сложно.
В любом случае - указатели - это ассемблер - и никакого автоматического управления памятью быть не может.
Именно по этой причине программы на Си часто падают с непонятными ошибками.
P.S. например, выяснилось, что ни компиллятору ни процессору не по зубам следующая инструкция:
unsigned long a;
unsigned char*pch;
unsigned short*psh;
a=0x12345678;
pch=(unsigned char*)(&a);
pch++;
psh=(unsigned short*)pch;
(*psh)=0xABCD;
И произошла фигня - двухбайтовое число оказалось на границе нечётного байта.

(205) в Си указатели удобны для всего, потому что, в отличии от ссылок, они могут быть не константныи. И используются повсеместно, для передачи "ссылок" на объекты.

Что касается арифметики указателей, то в современных программах ее используют в двух случаях: профессиональными Си-программистами, которые знают о чем-то, чего не знаем все мы; остальные влезают банально по не знанию, что есть десятки других удобных способом, не использовать арифметику указателей вовсе.

Не может быть автоматического управления памятью?? Я сейчас тружусь на работе, где основной ЯП полностью совместим с Си и обладает автоматическим сборщиком мусора.. Каково?

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

(205) В смысле не по зубам? Все работает так, как и должно работать. Что хотел - то и получил.

И, кстати, что такого в том, что двухбайтовое число оказалось по нечетному адресу? Ничего такого в этом нет, максимум штраф за 2 доступа к кешу вместо 1, когда это число попадет на границу строк кеша. Ну и store-to-load forwarding, скорее всего, не сработает (т.е. будет задержка на несколько тактов, если попытаться обратиться к только что записанному в память значению).

(207)
Это на x86 ничего страшного, что двухбайтовое число не выровнено по четному адресу.
А допустим на ARM'е - низзя, проц сразу сгенерит исключение.

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

И вообще, зачем вести речь о недопроцессорах, которые не могут нормально память адресовать? ;) В тех же БД такое встречается сплошь и рядом.

(209)
ARM - недопроцессор?
Производители смартфонов, планщетов, фотоаппаратов и т.д. и т.п. смотрят на тебя как то с недоумением, и одновременно смеются над тобой.
У тебя по карманам наверняка 2-3 девайса лежит на ARM'е.

(210) ARM суют в мобильные девайсы по одной причине - они меньше потребляют при удовлетворительной для мобильных девайсов производительности. Ну и производят их все кому не лень, а потому они дешевы. При этом все более или менее требовательные к производительности части реализуются спец. микросхемами (блоками), а не ARM.

P.S. А в кармане лежит максимум 1 девайс - Sony Ericsson T610, смартфоны не признаю (во-первых, ими пользоваться неудобно, во-вторых, нельзя ронять на бетонный пол, в-третьих, они просто огромные, в-четвертых, батарейку высасывают очень быстро), планшет мне не нужен. Девайсы на ARM есть (тот же автонавигатор или читалка), но они все тормоза поголовно, даже до Atom'а не дотягивают по производительности.

(211) ARM сравнительно молодая архитектура, и гораздо более перспективная, нежели x86. x86 - устарела донельзя, и то что процессоры на его архитектуре достигли очень высокой производительности, результат миллиардных вливаний в инженеров, которые чудом из какашки выдавливают последние соки.
А у того, кто обращается к данным по не выровненным адресам, просто руки из опы растут :)

(212) Да ладно? С 1983-го года и все молодая? Ну тогда и x86 совсем не старая ;)

turbo C 2.0

(еще один гвоздь в с++)
скажите название хоть одной книжки (не c .NET)
где есть нормальное описание работы с сокетами с протоколами (например pop3)

на purebasic за день сделал почтового клиента с приемом файлов... 16кб
чистый сокет + протокол pop3 + декодировщик-исправляльщек(base64) + буферы ( указатели(фиг с вами :) ))
+ узнал, что purebasic работает прям напрямую с api винды, короче сильная весч

на с++ там бы походу вообще дебри были....

на c# за час бы сделал, но .NeT зараза все портит

+(215)
статейки типа
http://club.shelek.ru/viewart.php?id=37

полное уе...ще

+(216)
смотрю 7 книгу по С++
ни намека на библиотеки тем более на сокеты
все какая то чушь про наследование и указатели друг на друга, короче все что не нужно
алгоритмы там всякие перестановок....
ничего полезного не нашел

(215) MSDN, Platform SDK, если под Windows.

(217) Не там смотришь.

я хз, чО там в книгах, но встроенный в QTcreator мануал - прекрасен, лучше чем СП

(218)
типа
http://msdn.microsoft.com/ru-ru/library/system.net.sockets.socket.aspx#Y228
нуууу блин мозг ломается
     bytes = s->Receive( bytesReceived, bytesReceived->Length, static_cast<SocketFlags>(0) );
     strRetPage = String::Concat( strRetPage, Encoding::ASCII->GetString( bytesReceived, 0, bytes ) );

не ну его нафиг
s->Send( bytesSent, bytesSent->Length, static_cast<SocketFlags>(0) );

(220) Ну и на чем он ломается конкретно?

(221) видимо, на комментарии
// The following will block until te page is transmitted.

+(220)
почти тоже самое у меня на бэйсике - все понятно :)

RequestLength.l = ReceiveNetworkData(ConnectionID, *BufferT, MessageSize(i))  
             CopyMemory(*BufferT, *Buffer+BufferLength, RequestLength)

(222)
кстати да, нафига ?

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

не важно всш, хта и т.п.

(223) а что непонятно? вызов метода объекта через ->?
(224) тебе как бы говорят - пока вся страница не передастся - будет выполняться этот цикл

+ врапер может быть включон как в скрипт так и в хта

(227)
вот что такое String ?

класс

(229) класс со статическим методом Concat...

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

(231)
во первых может это не класс ?
во вторых откуда ты это знаешь ?

(223) А от этого не разрывается:
http://msdn.microsoft.com/en-us/library/ms882964

(229) Класс хитрый.

(233) я немного прочитал описание синтаксиса языка

(232)
да да да да да + 100500 да
++++++++++++++++++

:)

(233)+ немного прочитал, что такое статические, асбтрактные, виртуальные и прочие плюшки в ООП

(232) куйня

(235)
структура ?
а может там уже чет переопределили
а может метод класса перегружен, а может еще чего...

+(239)
да нафиг я бы разбирался....

(239) чо ты плетешь?

(241)
что именно тебе не понятно ?

(242) непонятен твой поток сознания про вызов конкретного статического метода конкретного класса... при чем тут пееропределение, перегрузка и прочее?

(0)
http://clang.llvm.org/

(243)
ну может какой нить другой чувак(или я) в начале программы че нить сделал :)
потом через месяц пришел и забыл :)

(245) ну расскажи мне, что можно сделать со статическим методом класса

(245) А ты не делай так ;) Кстати, что ты к этой строчке привязался? Она просто преобразует число в строку. itoa() или sprintf() никто не отменял.

(247) нифига, оно просто склеивает строки. а Encoding::ASCII - преобразует кодировки

просто там строки не просто нул терминатед, а хитрые

(246)
ничего
если знаешь что он статический

(248) Ну просто создатели .NET - извращенцы :) Код из (223) вполне можно заменить на

bytesReceived = recv (ConnectionID, BufferT, BufferTSize, 0);
memcpy(BufferT, Buffer+BufferLength, bytesReceived);

(223)
причем сами функции типа ReceiveNetworkData
я так понял пишутся на том же бэйсике с обращением к апи виндовым
либо ассемблерные вставки
короче это все работает дико быстро

(251) Точнее (Buffer+BufferLength, BufferT, bytesReceived);

+(250)
читаю в книжке :


В качестве «краеугольного камня» изучения перегрузки операций мы  
построим класс String (рис. 11.9-11.11), который управляет созданием и  
обработкой строк. Стандартная библиотека C++ предоставляет похожий, более  
надежный.класс string. Как вы помните, мы ввели стандартный класс string
в главе 3. Дополнительный пример с классом string рассматривается в  
разделе 11.13. Сейчас мы воспользуемся перегрузкой операций для создания своего
собственного класса String.
Сначала мы рассмотрим заголовок класса String и обсудим закрытые  
данные, используемые для представления объектов String. Затем мы  
проанализируем открытый интерфейс класса, обсуждая каждую из услуг, которые  
предоставляет наш класс. Мы обсудим определения элемент-функций класса
String. Для каждой перегруженной операции мы рассмотрим код в  
программе-драйвере, который активирует данную функцию-операцию, и объясним,
как работает эта перегруженная функция-операция.
Определение класса
Рассмотрим заголовочный файл класса String на рис. 11.9. Мы начнем
с внутреннего представления String. В строках 55-56 объявляются закрытые
элементы данных класса. Наша реализация класса String имеет поле длины
length, представляющее число символов в строке, не считая завершающего
нуль-символа, и указатель ptr на динамически выделенную память для  
внутреннего представления строки символов.