Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Прочее";
Текущий архив: 2007.03.11;
Скачать: [xml.tar.bz2];

Вниз

Размер exe-шника С/С++ - и Pascal - компиляторов   Найти похожие ветки 

 
sabu   (2007-02-09 13:28) [80]

evvcom ©   (09.02.07 13:21) [77]

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

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


 
palva ©   (2007-02-09 13:33) [81]

> Так изначально было заявлено что в Паскале нет каких-то возможностей
Я перечислил некоторые возможности, которых нет в паскале. Именно возможности, а не синтаксис. На си можно написать такую функцию в составе dll, к которой нельзя обратиться из паскаля. На паскале нельзя написать такую функцию, к которой нельзя обратиться из си.


 
Psychedelic ©   (2007-02-09 13:35) [82]

> Ого, ну и программисты у нас. Оказыватеся те кто программирует
> на Delphi должен осваивать новые технологии.   Новые!


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


А к чему этот комментарий? Он совсем не к месту. Этой фразой я хотел сказать что никаких новых технологий нет, это все то же Delphi.

> Ну а если чел умеет бросать только компоненты на форму (это
> к вам не относиться - это вобщем) , а у нас в основном таких
> "программистов" завались (об этом уже говорили - обговаривали,
>  - ведро на рубль ), то конечно для него это будет довольно
> трудновато.
>
> А что плохого когда имеем RAD средство

>
> Так бросание компонентов - это и есть основное преимущество
> RAD-средства, там первая буква обозначает Rapid, чем меньше
> программист будет заботиться о неотносящихся к основной
> цели программы моментах, тем быстрее и качественнее будет
> создана его программа.


Во-во. Только вы забыли продолжить мою фразу - "RAD средство, которое создает результат без мертвого кода, и быстро работающее." RAD  - быстрая разработка.

> Ps. Убрать Object? Вы представляете что тогда будет с Delphi
> и с совместимостью с проектами? Врядли компания пойдет на
> создание убытка для своих клиентов.


> Э...клиентов, использующих object, сдается мне, не так уж
> много по сравнению с неиспользующими...


Да ну, неужели? Сдается мне вы лукавите, чтобы казаться правым.

> KOL это тоже делфи, это не другой язык.
> Каждое средство для чего то нужно, для разных задач.


> А можно узнать, для чего нужна KOL ?


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

Тут уж наверное зависит от мнений. Есть  две проги, абсолютно одинаковые по функционалу и интерфейсу. правда одна весит 2 мега, другая - 200 килобайт. Но выбирать то пользователю. Как вы думаете какую он будет качать? Конечно вы скажете что та , которая круче (ведь вы до смешного предсказуемы).
Но ведь по условию проги одинаковы, а у большинства народов СНГ - дома модем...  Это можно до бесконечности продолжать... Давайте лучше
>  людям пользу приносить
прям сейчас, и не будем зря бухтеть на этом форуме.


 
palva ©   (2007-02-09 13:37) [83]

> но тем не менее это compiler magic functions, думаю, в С аналогично.
Нет, в си это обычные библиотечные функции.
> Если посмотреть асм, то никакого "переменного" количества параметров ты не увидишь
Как раз и увижу в стеке разное количество параметров. При интерпретации первого параметра - формата функция использует нужное число параметров.

Более того, такие функции может писать для себя начинающий сишник.


 
Игорь Шевченко ©   (2007-02-09 13:38) [84]

sabu   (09.02.07 13:16) [74]


> Конечно пропустит.


Тогда об чем разговор ? С чего, собственно говоря, утверждение, что паскалевскому оператору ^ соответствует (*foo).bar, а не foo->bar ?


> А можно ли легко разобраться в Автошеме?


Извини, но в сортах дерьма не разбираюсь.


 
Romkin ©   (2007-02-09 13:41) [85]


>  разве в Delphi Language вообще можно перегрузить хоть один
> оператор? Или жисть не стоит на месте и я бесконечно отстал?
>

Есть перегрузка. Все зависит от версии языка :)


 
KSergey ©   (2007-02-09 13:42) [86]

> palva ©   (09.02.07 13:05) [71]
> 2. В паскале отсутствует возможность писать функции с переменным
> числом параметров.

Я предлагаю приводить все же те языковые средства, которые действительно здоровско помогают и мощны.
Переменное число параметров - да нафиг не здалося в общем-то. Легко заменяется передачей любого списочного контейтера, да и для понимания/отладки проще и понятнее. Не кошерно короче это переменное число параметров, хотя и прикольно, понятно :) Главное - легко заменяется.

О, еще чего есть в паскале и нет в С++, вернее то, что приходится изобретать в С++ (правда в плюс то, что средства для создания такого в С++ есть) и чего в паскале - нафиг не сдалось (да и не сделать, наверное буквальным переносом), зато есть средства для подобного прямо в языке: это сишные фарики классов.


 
Игорь Шевченко ©   (2007-02-09 13:42) [87]

Psychedelic ©   (09.02.07 13:35) [82]


> А к чему этот комментарий? Он совсем не к месту. Этой фразой
> я хотел сказать что никаких новых технологий нет, это все
> то же Delphi.


Комментарий как раз к месту, потому что использование VCL - это одна технология со всеми ее нюансами, а использование KOL, извини, совсем другая. Со своими нюансами.


> Во-во. Только вы забыли продолжить мою фразу - "RAD средство,
>  которое создает результат без мертвого кода, и быстро работающее.
> " RAD  - быстрая разработка.


Минуточку. А откуда берется мертвый код при использовании VCL и почему он мертвый ? Можно на примерах показать ?


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


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


 
wicked ©   (2007-02-09 13:42) [88]


>
> Тогда об чем разговор ? С чего, собственно говоря, утверждение,
>  что паскалевскому оператору ^ соответствует (*foo).bar,
>  а не foo->bar ?

сорь, что встреваю, но...
в паскале - ^
в си - *
foo^.bar ==== (*foo).bar
??? ==== foo->bar
стрелки, как таковой, в паскале нет :)
а в си++ она еще и перегружается - можно создать класс, ведущий себя, как указатель... для смарт поинтеров - удобно


 
sabu   (2007-02-09 13:47) [89]

Игорь Шевченко ©   (09.02.07 13:38) [84]

>Тогда об чем разговор ? С чего, собственно говоря, утверждение, что паскалевскому оператору ^ соответствует (*foo).bar, а не foo->bar ?

Но ведь из того, что пропустит компилятор, а что не пропустит не следует эквивалентность тех или иных конструкций, правда?

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

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


 
Romkin ©   (2007-02-09 13:48) [90]

wicked ©   (09.02.07 13:42) [88] В Delphi смарты уже вшиты, если я понимаю их правильно. ansistring & dynamic arrays - один из примеров.
И в Delphi все классы - указатели. ТАк что можно считать аналогом стрелки обычную точку :)


 
Игорь Шевченко ©   (2007-02-09 13:49) [91]


> Используя оператор -> мы оперируем непосредственно с указателем
> (синтаксически).


А используя оператор ^ в паскале мы разве не оперируем аналогичным образом ? Сдается мне, что это ловля блох


 
KSergey ©   (2007-02-09 13:50) [92]

> KSergey ©   (09.02.07 13:42) [86]
> > palva ©   (09.02.07 13:05) [71]
> > 2. В паскале отсутствует возможность писать функции с
> переменным
> > числом параметров.
>
> Я предлагаю приводить все же те языковые средства, которые
> действительно здоровско помогают и мощны.

Я дочитал в последующих постах по поводу того, что выходит можно написать в dll ф-цию на Си, но ее нельзя будет вызвать из Delphi.
Да, тут согласен. Но в данном случае, по моему глубочайшему убеждению, уже будет присутсвовать грубейная ошибка проектирования: выдавать такую dll за супер универсальную и удобную - будет по меньшей мере глупо :) А если не универсальна - тогда это и не минус.
Это как Си-компиляторам/линкерам от MS поставить в вину то, что они не умеют использовать bpl :)


 
DevilDevil ©   (2007-02-09 13:51) [93]

Удалено модератором
Примечание: Offtopic


 
DevilDevil ©   (2007-02-09 13:59) [94]

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

Меня попросили проивести пару весчей, привожу:

--- макросы
--- шаблоны
--- классы не в куче
--- операторы (в Delphi правда реализовали)
--- STL
--- весчи типа +=, ++, *=, \=, &=  и т.д.

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


 
palva ©   (2007-02-09 13:59) [95]

KSergey ©   (09.02.07 13:50) [92]
> А если не универсальна - тогда это и не минус.
А я разве говорил об универсальности или о минусах? Я говорил о возможностях си, которых нет в паскале. Такие возможности кое-кому нафиг не нужны, с этим можно согласиться. Но они есть.


 
KSergey ©   (2007-02-09 14:07) [96]

> Игорь Шевченко ©   (09.02.07 13:49) [91]
> А используя оператор ^ в паскале мы разве не оперируем аналогичным
> образом ? Сдается мне, что это ловля блох

В Си и С++, как вы знаете, принципиально различается обращение к полям/метоам класса/структуры, заданным собственно объектом и указателем на него. Используется точка или "стрелочка", но никак не "как в голову взбредет": к указателям только стрелочка. Признаться, мне не знакома философия данного решения для чистого Си; могу лишь предположить, что свыше было подсказано, что это будет удобно потом, в С++, когда появится перегрузка и именно и только стрелочку можно будет перегрузить :) Хотя имею и друое. более простое (или вернее менее мистическое) объяснение.

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


 
homm ©   (2007-02-09 14:10) [97]

2 Игорь Шевченко
> Трафик тоже дешевеет.

Вы хотите сказать что он у Вас дешевеет?

На самом деле конечно именно эту програмульку мне не сложно было бы скачать если бы она весила 591кб, как Вы сказали, Но есть приложения которые приходится обновлять, следить за новыми версиями... Я скачиваю как минимум все вновь появляющиеся версии ДМКлиента, и через одну-две версии Оперы. Может опера это не удачный пример, ибо здесь действительно проект такой сложности что пытатся сделать ее меньше бессмылено (хотя надо отметить, что дистрибутив до сих пор не превышает 4-х мегабайт, а функций все больше и больше...). Если бы дистрибутив ДМ весил 200-300кб, я думаю никому бы плохо не стало...

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

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

Все-же каждому свое...


 
Игорь Шевченко ©   (2007-02-09 14:10) [98]


> Так вот, относительно эквиваленстности ^ и -> - я никак
> не могу вас, Игорь, понять. Это же принципиально разные
> операторы!


Я наверное не сказал, что подразумеваю ^. (с точкой, разумеется) как эквивалент сишного оператора -> (или, что то же самое, (*foo).bar)


 
KSergey ©   (2007-02-09 14:12) [99]

> Игорь Шевченко ©   (09.02.07 14:10) [98]
> Я наверное не сказал, что подразумеваю

Не мне вам рассказывать о продолжительности отпуска телепатов :)


 
wicked ©   (2007-02-09 14:14) [100]

па-а-азвольте

> Признаться, мне не знакома философия данного решения для
> чистого Си; могу лишь предположить, что свыше было подсказано,
>  что это будет удобно потом, в С++, когда появится перегрузка
> и именно и только стрелочку можно будет перегрузить :)

вот кусок реального кода
Pt* operator->() const
{
 return fData;
}
Pt& operator *() const
{
 return *fData;
}

наряду с перегруженной стрелкой обычно также перегружается оператор разыменования - "*" - для тех, кому не будет терпеться обращаться к полям через (*foo).bar
хотя, ежели класс "внутрипроектный", то здесь ленятся и полагают, что в членам нужно обращаться только через "->"


 
KSergey ©   (2007-02-09 14:14) [101]

> DevilDevil ©   (09.02.07 13:59) [94]
> Дык давайте хотябы проявим уважение

А чиста кто-то не уважает?!


 
KSergey ©   (2007-02-09 14:16) [102]

> wicked ©   (09.02.07 14:14) [100]

Разницу между С и С++ знаем?


 
Игорь Шевченко ©   (2007-02-09 14:17) [103]

homm ©   (09.02.07 14:10) [97]


> Вы хотите сказать что он у Вас дешевеет?


Я хочу сказать, что он дешевеет везде.


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


Если вас не затруднит, скажите пожалуйста, за счет чего достигается именно "более быстрый запуск", насчет занимания памяти - это, извиняюсь, вы какую память имеете в виду - private bytes или working set ?


> На самом деле мне кажется что многие уже пишут под кол потому
> что знают его лучше ВСЛ, и не видят выгоды в переходе на
> него. Я довольно сносно знаю КОЛ Изнутри, и мне намного
> проще и удобнее писать на нем, чем на ВСЛ (кога все-же есть
> такая необходимость).


Тут такое дело - многие пишут под VCL, потому что им надо кушать. И с VCL этот процесс, от писания до еды как-то быстрее проходит.

Моих многих гораздо больше, чем твоих :)

И кстати, ладно вы в своем KOL от форм delphi"йских отказались, но зачем вы не от TObject наследуетесь, можно узнать ?


 
KSergey ©   (2007-02-09 14:19) [104]

> wicked ©   (09.02.07 14:14) [100]
KSergey> и именно и только стрелочку можно будет перегрузить :)

Имелось в виду "имено  и только" относительно точки: ее епергрузить нельзя.
Про другие операторы я не говорил.

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


 
KSergey ©   (2007-02-09 14:22) [105]

> Игорь Шевченко ©   (09.02.07 14:17) [103]
> И кстати, ладно вы в своем KOL от форм delphi"йских отказались,
>  но зачем вы не от TObject наследуетесь, можно узнать ?

Я думаю им претит RTTI как бесполезно занимающая место :)


 
homm ©   (2007-02-09 14:25) [106]

> но зачем вы не от TObject наследуетесь, можно узнать ?

1 - это класс
2 - виртуальные методы - самая большая дыра для "мертвого кода".


> Если вас не затруднит, скажите пожалуйста, за счет чего
> достигается именно "более быстрый запуск"
За чсет отсутствия инициальзации всякого мусора, котрый возможно и не понадобится в приложении. Вы часть Screen пользуетесь? А он создается...


> насчет занимания памяти - это, извиняюсь, вы какую память
> имеете в виду - private bytes или working set ?
Я имею ввиду выдленую системой виртуальную память... а из меньшего обращения к ненужным объктам, и собственно компактности кода самих этих объктов и вытекает меньшее использование физической пямяти для работы.


> И с VCL этот процесс, от писания до еды как-то быстрее проходит.

С чего Вы взяли? КОЛ - такая-же RAD система. Естественно для Вас то справедливо, т.к. на всл огромый опят, а о кол только поверхностное представление.


> Моих многих гораздо больше, чем твоих :)
Это даже удивления не вызывает :) причины на поверхности... Но не думаю что дело в самом КОЛ.


 
KSergey ©   (2007-02-09 14:29) [107]

К стати, относительно того, что есть в дельфи, но нет в си: Variant
Только не надо мне рассказывать про ATL-ный вариант! Чур меня чур! :)

А с COM из С++? А?
Даже при наличии ATL - удавиться. Хотя много уже легче, конечно. А уж без ATL... приличных слов у меян просто нет.

Но никакая ATL не идет в сравнение с variant, особенно при позднем связывании.
А ведь это, по сути, средство языка в паскале. Хотя, тут не спорю. может и стоит признать, что внутри оно - полностью compiler magic и жестко Windows-ориентированное.


 
homm ©   (2007-02-09 14:29) [108]

> Я думаю им претит RTTI как бесполезно занимающая место :)

Она еще и жуко тормозная. Сравнение принадлежности класса к конкретному экземпляру сделано явно через одно место.
Нет, я не против RTTI, пусть живет, просто не нужно как к поноцее к ней относится, она правда тормозная


 
sabu   (2007-02-09 14:33) [109]

KSergey ©   (09.02.07 14:29) [107]

>К стати, относительно того, что есть в дельфи, но нет в си: Variant

boost::any
boost::variant

>А с COM из С++?

using в MSVC генерирует довольно удобоваримые врапперы.


 
KSergey ©   (2007-02-09 14:40) [110]

> sabu   (09.02.07 12:14) [65]
> Во внутреннем устройстве stl по-моему невозможно разобраться,
>  так как разработчики применили очень своеобразный стиль
> кодирования.

Мдя... вот так и рождаются дебильные мифы... За всю STL говорить не буду, конечно, может быть понять "с нуля" без описания нафиг оно сдалось - и заьруднительно в достаточном объеме, но лишь ввиду объема. Но те куски, которые у меня вызывали вопросы - я брал и читал, снимая вопросы. Поверьте, голова у меня очень посредственная. Знаю людей, которые делают это быстрее и еще и наизусть помнят да еще и знают почему оно так сделано.
К стати, компилятор тоже его понимает и компилирует, не смотря на "своеобразный стиль кодирования". Хочется перейти на личности.

Горазно труднее мне даются понимания идей из boost. Вот тут точно мозги должны быть "не избалованные Delphi" :)
Хоят закоренелые сишники от нее торчат. Все же убежден, что лишь от незнакомства с Delphi. :(

> Игорь Шевченко ©   (09.02.07 12:05) [64]
> Вот можно ли программисту без особо выстроенных извилин
> разобраться в коде boost или stl ? :)

Да, возможно, я в этом уверен. Более того, после этого мозги становятся устроенны правильно. С точки зрения понимания. Насчет прочего - иногда меня терзают сомнения :)


 
Игорь Шевченко ©   (2007-02-09 14:47) [111]

homm ©   (09.02.07 14:25) [106]


> 1 - это класс
> 2 - виртуальные методы - самая большая дыра для "мертвого
> кода".


Я сильно извиняюсь, а что, у вас в KOL виртуальных методов нету ? Раз это такая вот дыра...


> За чсет отсутствия инициальзации всякого мусора, котрый
> возможно и не понадобится в приложении. Вы часть Screen
> пользуетесь? А он создается...


Я - безусловно пользуюсь Screen, Application и "прочим мусором". Но, опять же, желателен более подробный анализ "быстрого запуска", можно с циферками...Например, VCL-приложение запускается столько-то миллисекунд, а аналогичное на KOL - столько-то. Наверняка факт быстрого запуска KOL-приложений был получен опытным путем, а не теоретизированием.


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


Опять же, цифирки бы неплохо - вот программа на VCL занимает столько-то, а аналогичная программа на KOL в два раза меньше. Не затруднит ?


> С чего Вы взяли? КОЛ - такая-же RAD система. Естественно
> для Вас то справедливо, т.к. на всл огромый опят, а о кол
> только поверхностное представление.


Я, уважаемый, имел удовольствие ознакомиться с исходными текстами программы на KOL, автор здешний, плагин для TotalCommander"а писал. После этого говорить про RAD-системы по сравнению с разработкой на VCL мне даже не хочется.

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


> Это даже удивления не вызывает :) причины на поверхности.
> .. Но не думаю что дело в самом КОЛ.


Дело не в KOL. Дело в разнице между Borland и Кладовым сотоварищи. У Borland"а толще во всех отношениях.


 
KSergey ©   (2007-02-09 14:55) [112]

> sabu   (09.02.07 14:33) [109]
> >А с COM из С++?
> using в MSVC генерирует довольно удобоваримые врапперы.

Ню-ню :)
Нет, работать можно, разговора нет. Но счастья - тоже нет.
К стати, про позднее связывание - я ведь не напрастно упомянул. Врапперы - они ведь не про то, если я все верно понимаю.

Вообще моща Си и С++ конечно же в том, что то, что мы по сути обсуждаем - лишь библиотеки, созданные на тех же самых языках! Хотя и стандартизованные, конечно.
Сами же языки имеют весьма компактный (по описанию) синтаксис с весьма небольшим набором инструментов собсвенно языка. Все конструкции Си, думаю, и вовсе описываются на одной странице.
Правда, к этому компактному описанию идет еще книжка в 600 страниц Страуструпа про оисание нюансов. И то не всех :) (что касается С++; для Си - это актуально, но все же объем нюансов несоизмеримо меньше.)

В противовес Delphi language имеет массу compiler-magic функций и процедур, аналоги которых на самом языке и вовсе нереализуемы. Зато и "дуракаустойчивость" получается много выше.

К стати, об этих вот нюансах Cи/С++: всегда читая о них, я думаю о Delphi: от чего в книгах по Delphi о них ни слова? Ведь так вот прикидываешь - сами по себе эти нюансы часто имеют место быть. И толи просто школа не сложилась их преподавания, толи все же просто язык таков, что про все эти нюансы нет смысла думать, т.к. они хоть и есть, но на них никогда не наступаешь, т.к. такой уж синтаксис языка, а все это уж пусть разработчики компиляторов додумывают сколько и какой объект должен жить, чтобы проблем с ним не возникало в принципе?
Может кто знает ответ?


 
Игорь Шевченко ©   (2007-02-09 14:58) [113]

"Полезно взглянуть на два языка программирования - PL/1 и C. Язык PL/1 был
разработан корпорацией IBM в 60-ые годы, так как поддерживать одновременно FORTRAN и COBOL и слушать при этом ворчание ученых о том, что Algol лучше, чем FORTRAN и COBOL, вместе взятые, было невыносимо. Поэтому был создан комитет для создания нового языка, удовлетворяющего запросам всех программистов: PL/1.
Этот язык обладал некоторыми чертами языка FORTRAN, некоторыми особенностями языка COBOL и некоторыми свойствами языка Algol. Проект потерпел неудачу, потому что ему недоставало единой концепции. Проект представлял собой лишь набор свойств, конфликтующих друг с другом, к тому же язык PL/1 был слишком громоздким и неуклюжим, чтобы программы на нем можно было эффективно компилировать.

Теперь взглянем на язык С. Он был спроектирован всего одним человеком
(Деннисом Ритчи) для единственной цели (системного программирования). Успех его был колоссален, и это не в последнюю очередь объяснялось тем, что Ритчи знал, чего хотел и чего не хотел. В результате спустя десятилетия после своего появления этот язык все еще широко распространен. Наличе четкого представления о своих целях является решающим."

(с) Эндрю Таненбаум


 
Psychedelic ©   (2007-02-09 15:01) [114]

>> Я хочу сказать, что он дешевеет везде.

Украина - 60 коп час  с calback >> с первого января сего года 2 грн час (в 3 раза) -
все провайдеры от 1.50 минимум

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

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


 
Romkin ©   (2007-02-09 15:01) [115]


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

Ты уверен? Ты видел, сколько страниц в LangGuide для Object Pascal и для C++?


 
homm ©   (2007-02-09 15:02) [116]

> Опять же, цифирки бы неплохо - вот программа на VCL занимает
> столько-то, а аналогичная программа на KOL в два раза меньше.
> Не затруднит ?

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


> Я - безусловно пользуюсь Screen, Application и "прочим мусором".
Я имею ввиду в КАЖДОМ приложении?


> Я, уважаемый, имел удовольствие ознакомиться с исходными
> текстами программы на KOL, автор здешний, плагин для TotalCommander"а
> писал.
Возможо имеется ввиду "читый" КОЛ? Проект MCK знаком?


> А с чего я взял - с того, что на KOL я не видел программ,
> за которые денег платят достаточных для еды.
Об этом лучше спросить самого Владимира, MTsv DN и mdw. Может еще кого, я просто не знаю точно кто из кол комьюнити именно зарабатывает написанием программ на кол.


 
Psychedelic ©   (2007-02-09 15:04) [117]

Ну вот, как я и думал: Вы уже для себя разделили некоторых на вас и нас. :)


 
Игорь Шевченко ©   (2007-02-09 15:08) [118]

homm ©   (09.02.07 15:02) [116]


> Я имею ввиду в КАЖДОМ приложении?


Разумеется. Ведь эти объекты используются внутри самой VCL, и довольно успешно. Например, внутри методов объекта Application реализован цикл выборки сообщений потока.


> Возможо имеется ввиду "читый" КОЛ? Проект MCK знаком?


Безусловно знаком, даже, если мне память не изменяет, именно с использованием MCK это произведение и было написано.
Впрочем, можно у автора спросить, надеюсь, он не будет против, если я его упомяну - это Speller.


> Об этом лучше спросить самого Владимира, MTsv DN и mdw.
> Может еще кого, я просто не знаю точно кто из кол комьюнити
> именно зарабатывает написанием программ на кол.


Дело в том, что платят обычно не за те приложения, в которых важен размер. Тут довольно много программистов на Delphi, они могут рассказать, за какие примерно приложения платят денег на еду. Реализовывать подобные проекты на KOL - лучше сразу застрелиться :)


 
KSergey ©   (2007-02-09 15:08) [119]

> Romkin ©   (09.02.07 15:01) [115]
> Ты уверен? Ты видел, сколько страниц в LangGuide для Object
> Pascal и для C++?

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


 
Игорь Шевченко ©   (2007-02-09 15:09) [120]

Psychedelic ©   (09.02.07 15:01) [114]

а по существу вопроса можно ? Я вроде задавал вопрос - в чем практическая ценность KOL



Страницы: 1 2 3 4 5 6 вся ветка

Форум: "Прочее";
Текущий архив: 2007.03.11;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.75 MB
Время: 0.068 c
2-1171739873
DimitrySDA
2007-02-17 22:17
2007.03.11
Статистика подключения к Internet


1-1169040865
Strate
2007-01-17 16:34
2007.03.11
Потоки


1-1169047638
alpha5
2007-01-17 18:27
2007.03.11
Область прокрутки у компонента TListView


3-1165846925
kymnyoff
2006-12-11 17:22
2007.03.11
Настройка BDE


15-1171440613
Джо
2007-02-14 11:10
2007.03.11
Помогите перевести на английский





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский