- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
class SumClass
{
int A, B;
public:
void Set_A(int A) {this->A = A;}
void Set_B(int B) {this->B = B;}
int Sum() {return A+B;}
}
class MultiSumClass
{
SumClass Sum;
int count;
public:
void Set_A(int A) {Sum.Set_A(A);}
void Set_B(int B) {Sum.Set_B(B);}
void Set_Count(int count) {this->count = count;}
int GetSum() {return Sum->Sum()*count;}
}
void main()
{
MultiSumClass MSC;
MSC.Set_A(5); MSC.Set_B(10);
MSC.Set_Count(2);
cout << MSC.GetSum();
}
Follow us!
http://ideone.com/MBMeo
В этом плане IDE не помощник
там точка входа public static void main(String[] args),
код завершения можно передать только через System.exit(code);
и в то же время завершение проги через System.exit() считается дурным тоном (не рекомендуется), т.к. безусловно убивает всю VM без завершения всяких там финализаторов и проч.
плюс еще security manager может это дело запретить.
trollface.jpg
Выхода нет...
"It shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char * argv[]) { /* ... */ }".
Еще вопросы есть?
P.S. Ну и в g++ void main() тупо не компилится. Так что вариантов у меня особо нет.
Чем меньше вы пользуетесь "фишками" (читай выебонами) текущей платформы - тем больше вероятность того, что этот код будет собираться другим компилятором, или тем же самым через несколько лет.
Чем меньше вы пользуетесь недокументированными возможностями (читай багофичами) - тем больше вероятность того, что ваш код будет работать после очередного обновления операционки или каких-либо библиотек.
Лол. Так можно довыебываться до того что когда приспичит срочно портировать код - будет страшный процесс дрочева "шоб оно компилилось", вместо того чтобы не особо напрягаясь приучиться писать нормально.
Был бы в этом хоть какой-то сакральный смысл.
Борьба с системой же!
UPD: Но к int надо еще и return
В main можно опустить return - это эквивалентно return 0
Да я в курсе... просто не понимаю, зачем они сделали этот дурацкий частный случай. Поэтому я всегда пишу return в main(). Если приведете веские аргументы в пользу его неписания - может быть и перестану ;)
а ещё экономия места на диске
Имхо, глупо делать исключения на ровном месте ради сомнительной экономии одной строчки на проект. Причем в С89 такой код вызывает UB, но тем не менее компилируется (с ворнингом), а во всех дальнейших с\с++ подразумевается return 0.
думаю, накопилось достаточно кода, написанного для какого то лояльного компилятора, позволяющего ничего не возвращать из main - вот и легализовали это на бумаге
к слову, в С99 есть аналогичный пункт про отсутствие return, а в С11 вообще намекают на то, что main может возвращать incompartible with int
зы в С++11 тоже есть намек на отличие вовращаемого типа от int - традиционно implementation defined
Если гора не идет к Магомету...
Преобразовали бы язык что-ли, дабы он леворекурсивным парсером нормально обрабатывался.
A return statement in main has the effect of leaving the main function (destroying any objects with auto-
matic storage duration) and calling exit with the return value as the argument. If control reaches the end
of main without encountering a return statement, the effect is that of executing
return 0;
1) Старые программы, которые вместо #include <errno.h> писали extern int errno... "Зачем инклудить какую-то херню ради одной переменной?", думали программисты, и получили хуем в лоб, когда в libc появилась поддержка тредов.
2) Куча софта, использующего memcpy вместо memmove потому что оно работает... Все это поломалось на очередном обновлении libc, в котором memcpy решили сделать более шустрым.
3) Тот же MySQL с его кастом инта в велосипедный бул размером в чар... Кого ебёт то, что memcmp возвращает int а не char? Да никого, потому, что до некоторых пор все сравнивалось побайтно и результат, по счастливой случайности, не вылезал за пределы чара.
Вот из-за таких как вы, забивающих на стандарты, и любящих пользоваться UB и недокументированными фишечками, и случаются все эти проблемы, которых могло бы и не быть. А фиксить эти проблемы приходится не вам, а авторам компиляторов, и библиотек, оставляя костыли и теряя возможность сделать более вменяемые или быстрые реализации.
Конечно интересует. И, я согласен, что иногда нужно положить болт на стандарты, и сделать чтобы работало. Но не надо делать из раскладывания болтов смысл жизни, и писать хуйню (читай void main() в с++) тогда, когда все прекрасно работало бы и по стандарту.
Да ради бога! В таких случаях и я с радостью прощу автора.
Но проблема в том, что опытный разработчик, который умеет нормально проектировать, как правило и не позволит себе, без веской на то причины, отклоняться от стандарта и документированных возможностей...
> знаеш
ведь не так уж сложно не нарушать стандарты русского, например.
Q.E.D.
ололо lazy evaluation
cout << MultiSumClass(1,2,3)();
Ну тогда уж сделать конструктор, с передачей A, B и оператор int().
http://ideone.com/auqwp
Вот ленивое умножение я могу себе представить: если первый операнд 0, второй вычислять не нужно.
А ленивое сложение... Может чего-то не знаю, поясните пожалуйста.
Т.е. сложение будет выполнено только тогда, когда понадобится его результат.
>игрстрй
ExceptionClass { ... };
printfFunction( ... );
ColorEnum { clBlack... };
xDouble = 0.1;
yString = "...";
И финал:
template <...> class vectorTemplateClass { };
template <...> void compareTemplateFunction( ... );
compareTemplateFunctionResultBoolArment1 AnyArgument2Any
... кстати выше bool а не void как результат.