#include "somefile.xxx"
SomeNameSpace::Run();
Функция main(). Вам она тоже не нравится?
Господа, открываю Main-холивар.
Интересует ваше отношение к точке входа в программе.
Что удобнее из трех вариантов. Если вспомните еще - добавлю. :rolleyes:
(З.Ы. за begin-end наверно всеж стоит благодарить Д.Бэкуса...)
(З.З.Ы. под program-begin-end обобщенно понимаю синтаксическое выделение точки входа программы на уровне языка, main же в этом контектсе не имеет синтаксического выделения - с виду такая же функция как и остальные)
Интересует ваше отношение к точке входа в программе.
Что удобнее из трех вариантов. Если вспомните еще - добавлю. :rolleyes:
(З.Ы. за begin-end наверно всеж стоит благодарить Д.Бэкуса...)
(З.З.Ы. под program-begin-end обобщенно понимаю синтаксическое выделение точки входа программы на уровне языка, main же в этом контектсе не имеет синтаксического выделения - с виду такая же функция как и остальные)
Мое мнение таково - program-begin-end. Этот способ синтаксически выделяет точку входа - это наиболее сильный и безбажный способ. Таким образом, мы избавляем себя от необходимости резервирования прототипа функции main и необходимости её выбора, если в исходных текстах этой main 2 штуки.
Способ оформления точки входа в виде всего содержимого файла оправдано только для коротких скриптов, при наличии "злобных" средств обеспечения модульности вида #include <anotherfile.xxx> этот способ приводит к дополнительным багам и глюкам (апеллирую к кодинг-стайлам PHP).
Способ оформления точки входа в виде всего содержимого файла оправдано только для коротких скриптов, при наличии "злобных" средств обеспечения модульности вида #include <anotherfile.xxx> этот способ приводит к дополнительным багам и глюкам (апеллирую к кодинг-стайлам PHP).
ИМХО, нет большой принципиальной разницы: лично я отдаю предпочтение духу языка – в том плане, что если писать на С, то там подобает использовать main, если на паскале и т.п. - там уместен скрытый main, ну а на скриптовых языках я не писал сколько-нибудь серьёзно. Тут у меня аналогия такая: в казахском языке сказуемое всегда последнее слово в предложении (иногда похоже на речь Йоды), в немецком, если не ошибаюсь, та же ситуация; в русском сказуемое стоит в зависимости от смысла и стиля предложения, в каких-то других языках наверняка есть подобные особенности. Это если о частях речи. А в японском нет ругательств. Так что сам я проголосовал бы за все три пункта одновременно.
P.S. Конечно, дело не в духе языка, а в каких-то достаточно весомых для разработчика языка причинах сделать так, а не иначе. IMHO.
P.P.S. Пока писал ответ, hardcase ответил первым. По-моему, аргументированно. Присоединяюсь с оговоркой, изложенной в P.S.
P.S. Конечно, дело не в духе языка, а в каких-то достаточно весомых для разработчика языка причинах сделать так, а не иначе. IMHO.
P.P.S. Пока писал ответ, hardcase ответил первым. По-моему, аргументированно. Присоединяюсь с оговоркой, изложенной в P.S.
Учитывая, что этот код все равно генерится визардом на практике (моей по крайней мере), и меняется этот код (и читается) впоследствии весьма редко - то я вообще никакой не вижу разницы.
Но вот, в чисто функциональных языках, там используется точка входа в виде функции, и для них другие варианты вообще не подходят в силу самой парадигмы.
Но вот, в чисто функциональных языках, там используется точка входа в виде функции, и для них другие варианты вообще не подходят в силу самой парадигмы.
Мне больше по вкусу Begin-End.Из ассемблера пошло:)
Просто привык в таком стиле асмовую программу оформлять
Несмотря на то,что я ещё и VB пользовался(в котором как раз-таки больше к main склоняется),тот стиль мне нравится больше
Просто привык в таком стиле асмовую программу оформлять
Несмотря на то,что я ещё и VB пользовался(в котором как раз-таки больше к main склоняется),тот стиль мне нравится больше
А почему нет четвертого варианта? "А нужен ли вообще main?"
Предпочитаю думать о программе (о задаче), как о наборе взаимодействующих объектов, часть из которых должна появиться при старте программы и существовать, пока она не закончиться, часть (большая) заводиться и удаляться по мере работы программы. Тогда суть main сводиться к банальной инициализации первой части объектов. Такую инициализацию можно делать и статически без main.
Поскольку программирую на C++ и пока не думаю переходить на какой-то другой язык, отдаю голос за main.
Предпочитаю думать о программе (о задаче), как о наборе взаимодействующих объектов, часть из которых должна появиться при старте программы и существовать, пока она не закончиться, часть (большая) заводиться и удаляться по мере работы программы. Тогда суть main сводиться к банальной инициализации первой части объектов. Такую инициализацию можно делать и статически без main.
Поскольку программирую на C++ и пока не думаю переходить на какой-то другой язык, отдаю голос за main.
main наше всьо! :)
я даже на perl'е программы оформляю как:
sub main {}
main();
я даже на perl'е программы оформляю как:
sub main {}
main();
main'ьяки :D
Я бы предпочел некий комбинированный вариант. То есть, чтобы точка входа была вначале файла, который является файлом точки входа.
Типа, есть файл со стандартным именем "main.start" и в нем примерно такой код:
Это если я использую "свободную" функцию. Если нужен главный объект, то как-то так:
И чтоб файл этот лежал на самом видном месте.
Рассуждал я не как программист, а как пользователь, который пытается разобраться в чужом коде. 2-3 строчки кода дадут мне начало пути.
Типа, есть файл со стандартным именем "main.start" и в нем примерно такой код:
Код:
Это если я использую "свободную" функцию. Если нужен главный объект, то как-то так:
Код:
#include "somefile.xxx"
mainObject = SomeObject(param); // если динамическая типизация
mainObject.Run();
mainObject = SomeObject(param); // если динамическая типизация
mainObject.Run();
И чтоб файл этот лежал на самом видном месте.
Рассуждал я не как программист, а как пользователь, который пытается разобраться в чужом коде. 2-3 строчки кода дадут мне начало пути.
Код:
#include <iostream>
using namespace std;
#define begin int main (void){
#define end return 0;}
begin
cout << "бггг" << endl;
end
using namespace std;
#define begin int main (void){
#define end return 0;}
begin
cout << "бггг" << endl;
end
:D
Цитата: ~ArchimeD~
Код:
#include <iostream>
using namespace std;
#define begin int main (void){
#define end return 0;}
begin
cout << "бггг" << endl;
end
using namespace std;
#define begin int main (void){
#define end return 0;}
begin
cout << "бггг" << endl;
end
:D
Не-не-не, не эквивалент. В паскале прокачан модульный подход, там каждый модуль может иметь собственную точку входа. Так что Мыколе Вирту зачот.
Дык и в наследниких С/С++ обычно так же может быть множество main-ов и при старте указывается нужная точка входа. =)
Цитата: aks
Дык и в наследниких С/С++ обычно так же может быть множество main-ов и при старте указывается нужная точка входа. =)
В паскале точки входа модулей отрабатывают все. :p
Ктож спорит.
Цитата: grgdvo
А почему нет четвертого варианта? "А нужен ли вообще main?"
Предпочитаю думать о программе (о задаче), как о наборе взаимодействующих объектов, часть из которых должна появиться при старте программы и существовать, пока она не закончиться, часть (большая) заводиться и удаляться по мере работы программы. Тогда суть main сводиться к банальной инициализации первой части объектов. Такую инициализацию можно делать и статически без main.
Предпочитаю думать о программе (о задаче), как о наборе взаимодействующих объектов, часть из которых должна появиться при старте программы и существовать, пока она не закончиться, часть (большая) заводиться и удаляться по мере работы программы. Тогда суть main сводиться к банальной инициализации первой части объектов. Такую инициализацию можно делать и статически без main.
Во-первых, уходя т.о. от обычного main, ты никуда не деваешься от CRT-main, а управлять её по-хорошему почти не представляется возможным.
Т.о. во-вторых, "статически" крайне затруднительно инициализировать объекты в необходимой последовательности.
Цитата: Green
Во-первых, уходя т.о. от обычного main, ты никуда не деваешься от CRT-main, а управлять её по-хорошему почти не представляется возможным.
Т.о. во-вторых, "статически" крайне затруднительно инициализировать объекты в необходимой последовательности.
Т.о. во-вторых, "статически" крайне затруднительно инициализировать объекты в необходимой последовательности.
Спорить не буду. Твои замечания справедливы. Но в этом, собственно, и скрывается основная проблема ограниченности среды исполнения программы (читай ОС). Несмотря на то, что сейчас везде трубят - как круто будет жить в многоядерном (многопроцессорном) "мире", кардинально никаких улучшений не наблюдается. По сути все остается последовательным - одна точка входа в программу (как бы кто ее не называл)!
Цитата: grgdvo
Несмотря на то, что сейчас везде трубят - как круто будет жить в многоядерном (многопроцессорном) "мире", кардинально никаких улучшений не наблюдается. По сути все остается последовательным - одна точка входа в программу (как бы кто ее не называл)!
Не могу совместить логически последние 2 предложения. Вход один, но после запуска можно распараллеливаться как хочешь (см. потоки, процессы и т.д.). А ОС может распределять процессы по процессорам. Разве нет?
человек хочет, чтобы в программу можно было сразу с разных сторон заходить. че ж тут поделаешь... :D
Цитата: Washington
человек хочет, чтобы в программу можно было сразу с разных сторон заходить. че ж тут поделаешь... :D
Типа с одной стороны зашел - вот тебе текстовый редактор, с другой стороны зашел - вот тебе редакторный тестатор или даже роткадер йывотскет... круто...
угу. Но увы, нынешние оси неспособны на такую крутоту :(
Цитата: Green
во-вторых, "статически" крайне затруднительно инициализировать объекты в необходимой последовательности.
Тут нам может помочь точка входа. В main которая не имеет ссылки ни на один из наших классов (едакий стартер програмы который не знает о нашей програме ничего кроме названий наших классов) в одном потоке подтягиваем их в память рефлексией в нужной последовательности. :D
Извените за полный бред.
ЗЫ. Насколько мне извесно такой подход иногда используется для отображения прогреса загрузки большых програм в память.
ЗЫЫ. По теме - первые два варианта меня полностю удовлетворяют. Третий - нет. Так можно файлы заинклудить один в другой и получим полную кашу.
Я за main, хотя бы ради того, что параметры командной строки явно передаются :)
Когда структура begin/end это как-то больше похоже на низкоуровневость, а когда есть функция main() всегда есть ощущение, что ещё что-то подготавливает для неё параметры и запускает её.
я против main, мне это изначально в языке С не нравится, но куда деваться... в Visual Studio вообще _tmain - меня это вообще выводит из себя. Для меня это всё равно что: "да плевали мы на ваши стандарты, в нашем компиляторе будет так"
я против main, мне это изначально в языке С не нравится, но куда деваться... в Visual Studio вообще _tmain - меня это вообще выводит из себя. Для меня это всё равно что: "да плевали мы на ваши стандарты, в нашем компиляторе будет так"
а тут еще и макбет нашу гильдию поклонников паскаля предал. Не ну что за жизнь то :)
да, насчет передачи параметров. Лично я не виду большой разницы между paramstr и массивом аргументов в методе мэйн. Разве что во втором варианте параметры по именам хранятся... (или нет?)
Не.. не предал :) Я всегда был за main, просто мне кажется, что это более логично. А вообще по отношению к языкам - я космополит. Так что не нужно меня в предатели так сразу определять :)
А вот за что люблю Delphi, так за явную инициализацию и завершение в модулях (initialization-finalization-end).
А вот за что люблю Delphi, так за явную инициализацию и завершение в модулях (initialization-finalization-end).
Цитата: Washington
да, насчет передачи параметров. Лично я не виду большой разницы между paramstr и массивом аргументов в методе мэйн
И тот и другой способы одинаково тошнотворны и требуют дополнительной головной боли для разбора флажков и прочих параметров.
Цитата: ahilles
а когда есть функция main() всегда есть ощущение, что ещё что-то подготавливает для неё параметры и запускает её.
Ну так оно и есть, подготавливают и запускают.
Цитата: ahilles
в Visual Studio вообще _tmain - меня это вообще выводит из себя. Для меня это всё равно что: "да плевали мы на ваши стандарты, в нашем компиляторе будет так"
А при чем тут стандарты и компилятор?
_tmain - это макрос, который раскрывется в main.
Никакого противоречия стандарту.
Не нравится _tmain, ну напиши main.
а чего кстати тема в общалке? перенесите в общие вопросы - вполне интересный и серьезный вопрос
Цитата: hardcase
И тот и другой способы одинаково тошнотворны и требуют дополнительной головной боли для разбора флажков и прочих параметров.
вот и я о том же... ))
поэтому особой логики в мэйне не усматривается, а плюсы паскалевской точки входа вроде расписали )))
Я как-то одинаково комфортно чувствую себя и с мэйном в Сях и без оного в Пасе. Ведь как говорится
- А в чем сила, брат?
- В main()-е брат!
- Ну вот, будет у тебя много main()-ов, и чего?
Цитата:
- А в чем сила, брат?
- В main()-е брат!
- Ну вот, будет у тебя много main()-ов, и чего?
Цитата: Phodopus
Я как-то одинаково комфортно чувствую себя и с мэйном в Сях и без оного в Пасе.
Мне все равно что и как (потому и не проголосовал). Но почему-то в Питоне даже в однофайловых программках строю конструкции типа:
Код:
def main():
# my code
if __name__ == "__main__":
main()
# my code
if __name__ == "__main__":
main()
Наверно, это просто привычка из C++. Если бы переходил с Java, то наверно бы объект для точки входа определял...
Цитата: Green
Ну так оно и есть, подготавливают и запускают.
так оно и есть в обоих случаях.
Цитата: Green
А при чем тут стандарты и компилятор?
_tmain - это макрос, который раскрывется в main.
Никакого противоречия стандарту.
Не нравится _tmain, ну напиши main.
я знаю что это макрос и мне всё равно это не нравится. пойду убьюсь ап стенку.
Цитата: Kogrom
Не могу совместить логически последние 2 предложения. Вход один, но после запуска можно распараллеливаться как хочешь (см. потоки, процессы и т.д.). А ОС может распределять процессы по процессорам. Разве нет?
Да, есть такое - пользуюсь, успешно :) Но нафига писать дополнительный код распараллеливания, если можно БЫЛО БЫ указать сразу несколько точек входа в программу, с которых начиналось бы по отдельному процессу (или потоку). При этом логика взаимодействия процессов (потоков) останется такой же, как если бы ты написал один майн с кодом распараллеливания.
Цитата: grgdvo
При этом логика взаимодействия процессов (потоков) останется такой же, как если бы ты написал один майн с кодом распараллеливания.
Никому такое распараллеливание не нужно. Потому как перед распараллеливанием приходиться проинициализировать внутренние структуры: подготовить начальные данные, прикинуть, сколько потоков нужно создать и еще прочее всякое произвести (кароче, закон Амдала вспоминаем - без "последовательной" части не обойтись).
Гораздо полезнее было бы заполучить хоть как-то типизированный механизм передачи аргументов в процесс, а не злобный массив строк. Во многих (наверно всех) языках есть библиотека для разбора аргументов, а в OS Singularity вообще протокол (контракт) передачи аргументов реализован и на его основе оболочка тебе сообщает хинт - чего ввел неверно и что вообще ожидается. :)
Цитата: grgdvo
Но нафига писать дополнительный код распараллеливания, если можно БЫЛО БЫ указать сразу несколько точек входа в программу, с которых начиналось бы по отдельному процессу (или потоку).
Сразу вспоминается эпическая тема с гэймдева про диагональное программирование. =)
эх, мне бы ваши пробеммы XD
Цитата: ArtemS2006
эх, мне бы ваши пробеммы XD
Проблем здесь нет, но как пожелаешь, братан.
Цитата: hardcase
Никому такое распараллеливание не нужно. Потому как перед распараллеливанием приходиться проинициализировать внутренние структуры: подготовить начальные данные, прикинуть, сколько потоков нужно создать и еще прочее всякое произвести (кароче, закон Амдала вспоминаем - без "последовательной" части не обойтись).
А какое такое распараллеливание? Что мешет те же действия по инициализации делать в каждом процессе (потоке) отдельно, а общую память инициализировать соответствующими дополнительными декларациями в языке. Разбор параметров здесь мне кажется вообще не причем. Взаимодействие через пайпы тоже можно рассматривать как передачу входных и возвращение выходных параметров.
Подчеркну свою мысль. Я не собираюсь хаять единственность точки входа в программу, и уж тем более не собираюсь кому-то навязывать свою точку зрения. Я лишь пытаюсь подумать, какие выигрыши может принести наличие дополнительных "параллельных" расширений, которых сейчас нет, но которые возможно окажутся полезными в свете развития параллельных вычислений.
Закон Амдала, кстати, относится к проблеме эффективности выполнения параллельной программы, он не говорит, что нельзя обойтись без "последовательной части". Отсутствие последовательной части лишь приведет к величине усорения в p раз для p процессов.
Такой результат в современных условиях не достижим. Потому что все чем мы сейчас пользуемся в программировании имеет последовательную основу: тут хоть из 1000 потоков будет состоять программа, но пока один main не отработает и не скажет каждому - запустись - ничего ускоряться не будет.
Извините, что много текста ;)
Видимо пора заканчивать дискуссию.
To aks:
Цитата:
Сразу вспоминается эпическая тема с гэймдева про диагональное программирование. =)
Нашел, посмеялся. Народ, конечно, от души простебал (порадовала программа на паскале :) ), но какой вопрос, такой и ответ.
Цитата: grgdvo
А какое такое распараллеливание? Что мешет те же действия по инициализации делать в каждом процессе (потоке) отдельно, а общую память инициализировать соответствующими дополнительными декларациями в языке.
Это называется "распухание дизайна" (в таком виде, в каком вы предлагаете). В Ada есть расширения для параллельного программирования - и неплохие кстати! Но они никак не связаны с точкой входа в программу.
Цитата: grgdvo
Разбор параметров здесь мне кажется вообще не причем.
Вам приходилось писать консольные утиллиты? Разбор параметров в том виде, в каком это происходит сейчас - типичный синтаксический анализ. Теперь думаем - синтаксический анализ используют ВСЕ консольные программы, фактически это совершенное дублирование кода.
Цитата: grgdvo
Взаимодействие через пайпы тоже можно рассматривать как передачу входных и возвращение выходных параметров.
Данные в пайпах тоже нужно типизировать. Без общей системы типов на уровне ОС это ещё хуже - каждая программа будет придумывать свой двоичный формат, но это уже совсем иная история, не относящаяся к топику.
Цитата: grgdvo
Я лишь пытаюсь подумать, какие выигрыши может принести наличие дополнительных "параллельных" расширений, которых сейчас нет, но которые возможно окажутся полезными в свете развития параллельных вычислений.
Параллельные расширения есть. В Ada на уровне синтаксиса (рандеву и прочее). В C++ это OpenMP в виде директив компилятору. В C# есть ParallelExtensions работающий посредством последовательностей (IEnumerable<T>). В Nemerle можно вообще придумать и разработать свой собственный синтаксис - было бы время и желание (и конечно Main "расфоркать" ;) )
Цитата: grgdvo
все чем мы сейчас пользуемся в программировании имеет последовательную основу: тут хоть из 1000 потоков будет состоять программа, но пока один main не отработает и не скажет каждому - запустись - ничего ускоряться не будет.
Процесс инициализации ну невозможно исключить - принципиально, это, можно сказать, следствие закона Амдала. Будь ты хоть в памяти ПиСишки (С), будть ты на физическом кристалле (VHDL) - в первом случае пишется код "main", во втором случае обрабатывается сигнал сброса по фронту тактового генератора.
З.Ы. А чо, собсна, берем Nemerle, строим вашу модель распараллеливания - это не так сложно - и пробуем использовать. Удобно? Круто, поздравляю. Нет? Ну, значит не судьба...
Цитата: hardcase
Это называется "распухание дизайна" (в таком виде, в каком вы предлагаете).
Это не называется "распухание дизайна", потому что разбор простых входных параметров вполне можно уместить в один-два класса или вообще воспользоваться уже готовыми библиотеками. Если хотите типизации, то это уже какой-никакой язык получается, которым вы всенепременно воспользуетесь внутри вашей же программы. В любом случае это не имеет никакого отношения к разбиению задачи на процессы и уже тем более к количеству точек входа в программу. Классы уже написаны и вы можете ими воспользоваться в любом процессе в любом месте.
Про остальные расширения спорить бесмысленно, потому что их действительно много и в разных языках они имеют разное предназначение, но это опять же не имеет никакого отношения к количеству точек входа в программу.
Цитата: hardcase
З.Ы. А чо, собсна, берем Nemerle, строим вашу модель распараллеливания - это не так сложно - и пробуем использовать. Удобно? Круто, поздравляю. Нет? Ну, значит не судьба...
Ну, это не моя модель распараллеливания, да и моделью это назвать нельзя - простое желание упростить себе жизнь. А за ссылочку спасибо, любопытно.