Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Последние темы форума

Показать новые сообщения »

Почтовая рассылка

Подписчиков: 6311
Последний выпуск: 19.06.2015

Функция main(). Вам она тоже не нравится?

7
08 июня 2009 года
hardcase
4.5K / / 09.08.2005
Господа, открываю Main-холивар.
Интересует ваше отношение к точке входа в программе.
Что удобнее из трех вариантов. Если вспомните еще - добавлю. :rolleyes:

(З.Ы. за begin-end наверно всеж стоит благодарить Д.Бэкуса...)
(З.З.Ы. под program-begin-end обобщенно понимаю синтаксическое выделение точки входа программы на уровне языка, main же в этом контектсе не имеет синтаксического выделения - с виду такая же функция как и остальные)
Страницы:
7
08 июня 2009 года
hardcase
4.5K / / 09.08.2005
Мое мнение таково - program-begin-end. Этот способ синтаксически выделяет точку входа - это наиболее сильный и безбажный способ. Таким образом, мы избавляем себя от необходимости резервирования прототипа функции main и необходимости её выбора, если в исходных текстах этой main 2 штуки.
Способ оформления точки входа в виде всего содержимого файла оправдано только для коротких скриптов, при наличии "злобных" средств обеспечения модульности вида #include <anotherfile.xxx> этот способ приводит к дополнительным багам и глюкам (апеллирую к кодинг-стайлам PHP).
249
08 июня 2009 года
Sanila_san
1.6K / / 07.06.2005
ИМХО, нет большой принципиальной разницы: лично я отдаю предпочтение духу языка – в том плане, что если писать на С, то там подобает использовать main, если на паскале и т.п. - там уместен скрытый main, ну а на скриптовых языках я не писал сколько-нибудь серьёзно. Тут у меня аналогия такая: в казахском языке сказуемое всегда последнее слово в предложении (иногда похоже на речь Йоды), в немецком, если не ошибаюсь, та же ситуация; в русском сказуемое стоит в зависимости от смысла и стиля предложения, в каких-то других языках наверняка есть подобные особенности. Это если о частях речи. А в японском нет ругательств. Так что сам я проголосовал бы за все три пункта одновременно.

P.S. Конечно, дело не в духе языка, а в каких-то достаточно весомых для разработчика языка причинах сделать так, а не иначе. IMHO.

P.P.S. Пока писал ответ, hardcase ответил первым. По-моему, аргументированно. Присоединяюсь с оговоркой, изложенной в P.S.
63
08 июня 2009 года
Zorkus
2.6K / / 04.11.2006
Учитывая, что этот код все равно генерится визардом на практике (моей по крайней мере), и меняется этот код (и читается) впоследствии весьма редко - то я вообще никакой не вижу разницы.

Но вот, в чисто функциональных языках, там используется точка входа в виде функции, и для них другие варианты вообще не подходят в силу самой парадигмы.
6
08 июня 2009 года
@pixo $oft
3.4K / / 20.09.2006
Мне больше по вкусу Begin-End.Из ассемблера пошло:)
Просто привык в таком стиле асмовую программу оформлять

Несмотря на то,что я ещё и VB пользовался(в котором как раз-таки больше к main склоняется),тот стиль мне нравится больше
411
08 июня 2009 года
grgdvo
323 / / 04.07.2007
А почему нет четвертого варианта? "А нужен ли вообще main?"

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

Поскольку программирую на C++ и пока не думаю переходить на какой-то другой язык, отдаю голос за main.
2
08 июня 2009 года
squirL
5.6K / / 13.08.2003
main наше всьо! :)

я даже на perl'е программы оформляю как:

sub main {}

main();
5
08 июня 2009 года
George
4.1K / / 05.01.2007
main'ьяки :D
87
08 июня 2009 года
Kogrom
2.7K / / 02.02.2008
Я бы предпочел некий комбинированный вариант. То есть, чтобы точка входа была вначале файла, который является файлом точки входа.

Типа, есть файл со стандартным именем "main.start" и в нем примерно такой код:

 
Код:
#include "somefile.xxx"
SomeNameSpace::Run();

Это если я использую "свободную" функцию. Если нужен главный объект, то как-то так:

 
Код:
#include "somefile.xxx"
mainObject = SomeObject(param); // если динамическая типизация
mainObject.Run();


И чтоб файл этот лежал на самом видном месте.

Рассуждал я не как программист, а как пользователь, который пытается разобраться в чужом коде. 2-3 строчки кода дадут мне начало пути.
244
08 июня 2009 года
~ArchimeD~
1.4K / / 24.07.2006
 
Код:
#include <iostream>

using namespace std;

#define begin int main (void){
#define end return 0;}

begin
        cout << "бггг" << endl;
end

:D
341
08 июня 2009 года
Der Meister
874 / / 21.12.2007
Цитата: ~ArchimeD~
 
Код:
#include <iostream>

using namespace std;

#define begin int main (void){
#define end return 0;}

begin
        cout << "бггг" << endl;
end

:D

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

239
08 июня 2009 года
aks
2.5K / / 14.07.2006
Дык и в наследниких С/С++ обычно так же может быть множество main-ов и при старте указывается нужная точка входа. =)
7
08 июня 2009 года
hardcase
4.5K / / 09.08.2005
Цитата: aks
Дык и в наследниких С/С++ обычно так же может быть множество main-ов и при старте указывается нужная точка входа. =)


В паскале точки входа модулей отрабатывают все. :p

239
08 июня 2009 года
aks
2.5K / / 14.07.2006
Ктож спорит.
3
08 июня 2009 года
Green
4.8K / / 20.01.2000
Цитата: grgdvo
А почему нет четвертого варианта? "А нужен ли вообще main?"

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


Во-первых, уходя т.о. от обычного main, ты никуда не деваешься от CRT-main, а управлять её по-хорошему почти не представляется возможным.

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

411
09 июня 2009 года
grgdvo
323 / / 04.07.2007
Цитата: Green
Во-первых, уходя т.о. от обычного main, ты никуда не деваешься от CRT-main, а управлять её по-хорошему почти не представляется возможным.

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



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

87
09 июня 2009 года
Kogrom
2.7K / / 02.02.2008
Цитата: grgdvo
Несмотря на то, что сейчас везде трубят - как круто будет жить в многоядерном (многопроцессорном) "мире", кардинально никаких улучшений не наблюдается. По сути все остается последовательным - одна точка входа в программу (как бы кто ее не называл)!



Не могу совместить логически последние 2 предложения. Вход один, но после запуска можно распараллеливаться как хочешь (см. потоки, процессы и т.д.). А ОС может распределять процессы по процессорам. Разве нет?

5
09 июня 2009 года
George
4.1K / / 05.01.2007
человек хочет, чтобы в программу можно было сразу с разных сторон заходить. че ж тут поделаешь... :D
87
09 июня 2009 года
Kogrom
2.7K / / 02.02.2008
Цитата: Washington
человек хочет, чтобы в программу можно было сразу с разных сторон заходить. че ж тут поделаешь... :D



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

5
09 июня 2009 года
George
4.1K / / 05.01.2007
угу. Но увы, нынешние оси неспособны на такую крутоту :(
276
09 июня 2009 года
Rebbit
1.1K / / 01.08.2005
Цитата: Green
во-вторых, "статически" крайне затруднительно инициализировать объекты в необходимой последовательности.


Тут нам может помочь точка входа. В main которая не имеет ссылки ни на один из наших классов (едакий стартер програмы который не знает о нашей програме ничего кроме названий наших классов) в одном потоке подтягиваем их в память рефлексией в нужной последовательности. :D
Извените за полный бред.

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

ЗЫЫ. По теме - первые два варианта меня полностю удовлетворяют. Третий - нет. Так можно файлы заинклудить один в другой и получим полную кашу.

302
09 июня 2009 года
makbeth
1.0K / / 25.11.2004
Я за main, хотя бы ради того, что параметры командной строки явно передаются :)
259
09 июня 2009 года
ahilles
1.5K / / 03.11.2005
Когда структура begin/end это как-то больше похоже на низкоуровневость, а когда есть функция main() всегда есть ощущение, что ещё что-то подготавливает для неё параметры и запускает её.
я против main, мне это изначально в языке С не нравится, но куда деваться... в Visual Studio вообще _tmain - меня это вообще выводит из себя. Для меня это всё равно что: "да плевали мы на ваши стандарты, в нашем компиляторе будет так"
5
09 июня 2009 года
George
4.1K / / 05.01.2007
а тут еще и макбет нашу гильдию поклонников паскаля предал. Не ну что за жизнь то :)
5
09 июня 2009 года
George
4.1K / / 05.01.2007
да, насчет передачи параметров. Лично я не виду большой разницы между paramstr и массивом аргументов в методе мэйн. Разве что во втором варианте параметры по именам хранятся... (или нет?)
302
09 июня 2009 года
makbeth
1.0K / / 25.11.2004
Не.. не предал :) Я всегда был за main, просто мне кажется, что это более логично. А вообще по отношению к языкам - я космополит. Так что не нужно меня в предатели так сразу определять :)
А вот за что люблю Delphi, так за явную инициализацию и завершение в модулях (initialization-finalization-end).
7
10 июня 2009 года
hardcase
4.5K / / 09.08.2005
Цитата: Washington
да, насчет передачи параметров. Лично я не виду большой разницы между paramstr и массивом аргументов в методе мэйн

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

3
10 июня 2009 года
Green
4.8K / / 20.01.2000
Цитата: ahilles
а когда есть функция main() всегда есть ощущение, что ещё что-то подготавливает для неё параметры и запускает её.


Ну так оно и есть, подготавливают и запускают.

Цитата: ahilles

в Visual Studio вообще _tmain - меня это вообще выводит из себя. Для меня это всё равно что: "да плевали мы на ваши стандарты, в нашем компиляторе будет так"


А при чем тут стандарты и компилятор?
_tmain - это макрос, который раскрывется в main.
Никакого противоречия стандарту.
Не нравится _tmain, ну напиши main.

1
10 июня 2009 года
kot_
7.3K / / 20.01.2000
а чего кстати тема в общалке? перенесите в общие вопросы - вполне интересный и серьезный вопрос
5
10 июня 2009 года
George
4.1K / / 05.01.2007
Цитата: hardcase
И тот и другой способы одинаково тошнотворны и требуют дополнительной головной боли для разбора флажков и прочих параметров.


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

14
10 июня 2009 года
Phodopus
3.3K / / 19.06.2008
Я как-то одинаково комфортно чувствую себя и с мэйном в Сях и без оного в Пасе. Ведь как говорится
Цитата:

- А в чем сила, брат?
- В main()-е брат!
- Ну вот, будет у тебя много main()-ов, и чего?

87
10 июня 2009 года
Kogrom
2.7K / / 02.02.2008
Цитата: Phodopus
Я как-то одинаково комфортно чувствую себя и с мэйном в Сях и без оного в Пасе.


Мне все равно что и как (потому и не проголосовал). Но почему-то в Питоне даже в однофайловых программках строю конструкции типа:

 
Код:
def main():
    # my code

if __name__ == "__main__":
    main()


Наверно, это просто привычка из C++. Если бы переходил с Java, то наверно бы объект для точки входа определял...
259
10 июня 2009 года
ahilles
1.5K / / 03.11.2005
Цитата: Green
Ну так оно и есть, подготавливают и запускают.


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

Цитата: Green

А при чем тут стандарты и компилятор?
_tmain - это макрос, который раскрывется в main.
Никакого противоречия стандарту.
Не нравится _tmain, ну напиши main.


я знаю что это макрос и мне всё равно это не нравится. пойду убьюсь ап стенку.

411
11 июня 2009 года
grgdvo
323 / / 04.07.2007
Цитата: Kogrom
Не могу совместить логически последние 2 предложения. Вход один, но после запуска можно распараллеливаться как хочешь (см. потоки, процессы и т.д.). А ОС может распределять процессы по процессорам. Разве нет?



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

7
11 июня 2009 года
hardcase
4.5K / / 09.08.2005
Цитата: grgdvo
При этом логика взаимодействия процессов (потоков) останется такой же, как если бы ты написал один майн с кодом распараллеливания.


Никому такое распараллеливание не нужно. Потому как перед распараллеливанием приходиться проинициализировать внутренние структуры: подготовить начальные данные, прикинуть, сколько потоков нужно создать и еще прочее всякое произвести (кароче, закон Амдала вспоминаем - без "последовательной" части не обойтись).
Гораздо полезнее было бы заполучить хоть как-то типизированный механизм передачи аргументов в процесс, а не злобный массив строк. Во многих (наверно всех) языках есть библиотека для разбора аргументов, а в OS Singularity вообще протокол (контракт) передачи аргументов реализован и на его основе оболочка тебе сообщает хинт - чего ввел неверно и что вообще ожидается. :)

239
11 июня 2009 года
aks
2.5K / / 14.07.2006
Цитата: grgdvo
Но нафига писать дополнительный код распараллеливания, если можно БЫЛО БЫ указать сразу несколько точек входа в программу, с которых начиналось бы по отдельному процессу (или потоку).


Сразу вспоминается эпическая тема с гэймдева про диагональное программирование. =)

399
11 июня 2009 года
ArtemS2006
272 / / 12.01.2008
эх, мне бы ваши пробеммы XD
9
11 июня 2009 года
Lerkin
3.0K / / 25.03.2003
Цитата: ArtemS2006
эх, мне бы ваши пробеммы XD


Проблем здесь нет, но как пожелаешь, братан.

411
12 июня 2009 года
grgdvo
323 / / 04.07.2007
Цитата: hardcase
Никому такое распараллеливание не нужно. Потому как перед распараллеливанием приходиться проинициализировать внутренние структуры: подготовить начальные данные, прикинуть, сколько потоков нужно создать и еще прочее всякое произвести (кароче, закон Амдала вспоминаем - без "последовательной" части не обойтись).



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

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

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

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

Извините, что много текста ;)
Видимо пора заканчивать дискуссию.


To aks:

Цитата:
Сразу вспоминается эпическая тема с гэймдева про диагональное программирование. =)



Нашел, посмеялся. Народ, конечно, от души простебал (порадовала программа на паскале :) ), но какой вопрос, такой и ответ.

7
12 июня 2009 года
hardcase
4.5K / / 09.08.2005
Цитата: grgdvo
А какое такое распараллеливание? Что мешет те же действия по инициализации делать в каждом процессе (потоке) отдельно, а общую память инициализировать соответствующими дополнительными декларациями в языке.

Это называется "распухание дизайна" (в таком виде, в каком вы предлагаете). В Ada есть расширения для параллельного программирования - и неплохие кстати! Но они никак не связаны с точкой входа в программу.

Цитата: grgdvo
Разбор параметров здесь мне кажется вообще не причем.

Вам приходилось писать консольные утиллиты? Разбор параметров в том виде, в каком это происходит сейчас - типичный синтаксический анализ. Теперь думаем - синтаксический анализ используют ВСЕ консольные программы, фактически это совершенное дублирование кода.

Цитата: grgdvo
Взаимодействие через пайпы тоже можно рассматривать как передачу входных и возвращение выходных параметров.

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

Цитата: grgdvo
Я лишь пытаюсь подумать, какие выигрыши может принести наличие дополнительных "параллельных" расширений, которых сейчас нет, но которые возможно окажутся полезными в свете развития параллельных вычислений.

Параллельные расширения есть. В Ada на уровне синтаксиса (рандеву и прочее). В C++ это OpenMP в виде директив компилятору. В C# есть ParallelExtensions работающий посредством последовательностей (IEnumerable<T>). В Nemerle можно вообще придумать и разработать свой собственный синтаксис - было бы время и желание (и конечно Main "расфоркать" ;) )

Цитата: grgdvo
все чем мы сейчас пользуемся в программировании имеет последовательную основу: тут хоть из 1000 потоков будет состоять программа, но пока один main не отработает и не скажет каждому - запустись - ничего ускоряться не будет.

Процесс инициализации ну невозможно исключить - принципиально, это, можно сказать, следствие закона Амдала. Будь ты хоть в памяти ПиСишки (С), будть ты на физическом кристалле (VHDL) - в первом случае пишется код "main", во втором случае обрабатывается сигнал сброса по фронту тактового генератора.



З.Ы. А чо, собсна, берем Nemerle, строим вашу модель распараллеливания - это не так сложно - и пробуем использовать. Удобно? Круто, поздравляю. Нет? Ну, значит не судьба...

411
16 июня 2009 года
grgdvo
323 / / 04.07.2007
Цитата: hardcase
Это называется "распухание дизайна" (в таком виде, в каком вы предлагаете).



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

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

Цитата: hardcase
З.Ы. А чо, собсна, берем Nemerle, строим вашу модель распараллеливания - это не так сложно - и пробуем использовать. Удобно? Круто, поздравляю. Нет? Ну, значит не судьба...



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

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог