С++ как сделать метод с необязательными аргументами

сделай структуру, и принимай ссылку на неё — в функции..

# P.S.: ох как чувствую на меня полетят помидоры щаз.. но всё равно — я своё мнение высказал :-)

Я не понимаю, можешь примером небольшим написать?

1. Перегрузка функций 2. void foo(int inumber, float fnumber = 0.0);

Я не понимаю, можешь примером небольшим написать?

нет, не могу. последний раз я писал на C++ кучу лет назад — и щаз наверно и двух строчек без ошибок не напишу :-) ..

блин — ну структура она же и в африке структура (типа класса, но у которого поумолчанию всё публично)

Ну почитайте уже книги жеж.

Зачем базовые вещи-то спрашивать на форумах?

Ну почитайте уже книги жеж.

1000 страниц мокулатуры лопатить нет желания, этот C++ можно было описать в 30 страницах если бы автор действительно задался целью объяснения языка а не «майского денька» (С) Жак Фреско.

пцъ...

fnumber = 0

этот C++ можно было описать в 30 страницах если бы автор действительно задался целью объяснения языка

Качай студенческие методички по плюсам. Но знания языка они тебе всё равно не дадут.

// тред не читал

void lalka(int inumber, float fnumber = 0);

Как его переписать так, что бы один из аргументов был не обязательным для заполнения, например последний float?

man «ЗНАЧЕНИЯ ПАРАМЕТРОВ ПО УМОЛЧАНИЮ»

ЗЫ важный момент: «Если вызов функции опускает значение определенного параметра, то должны быть опущены и значения всех последующих параметров»

ЗЗЫ надеюсь объяснять что такое «определение», «вызов» и опрочие основы программирования на крестах не требуется...

ЗЫ важный момент: «Если вызов функции опускает значение определенного параметра, то должны быть опущены и значения всех последующих параметров»

это и есть самый главный дибильный нюанс, из-за которого я рекламирую структуры :-)

C++ можно было описать в 30 страницах

Кресты слишком монструозны, на 30 страницах лишь грамматика поместится.

это и есть самый главный дибильный нюанс, из-за которого я рекламирую структуры :-)

Это в большинстве случаев не уместно. И вообще больше попахивает недоООП из C без крестов.

недоООП из C без крестов

«недоООП из C без крестов» — мне кажется оно клёвое ^__^ ..

если бы не отсутствие shared_ptr и отсутствие вызовов исключений (throw)..

вообще, в C++ же много всяких интересных плюшек! кроме классов-этих-всяких-разных! ды хотя бы взять например namespace (куда без него?) !

нет ведь ничего плохого если писать на плюсах, но без классов? некоторые люди я слышал так делают :-)

Или перегрузка, или дефольтное значение. Определитесь, что вам нужно.

Я так и не понял, почему автору не подходит перегрузка.

Даже learncpp любой, сделал бы темя дном меньшим на

1000 страниц мокулатуры лопатить нет желания, этот C++ можно было описать в 30 страницах если бы автор действительно задался целью объяснения языка а не «майского денька» (С) Жак Фреско.

А тебе реально тупо охота потрепаться на лоре ^_^

недоООП из C без крестов» — мне кажется оно клёвое ^__^ ..

Как тот лемур из Мадагаскара?

нет ведь ничего плохого если писать на плюсах, но без классов? некоторые люди я слышал так делают :-)

Ну некоторые живут в человеческом теле, а мозгами не пользуются. ;)

Ну некоторые живут в человеческом теле, а мозгами не пользуются. ;)

а как же те люди которых классы — раздражают? :-)

зачем этих людей лишать: namespace, shared_ptr, throw, ... ?

Как тот лемур из Мадагаскара?

кто-то был.. но кто именно конкретно я не помню :-)

а как же те люди которых классы — раздражают? :-)

зачем этих людей лишать: namespace, shared_ptr, throw, ... ?

а как приятно наверно иногда передать в аргумент функции — указатель на другую функцию! это же сразу должно вызывать чувство прекрасного!

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

Когда ж тебя, гниду, забанят уже?

автору может она и подошла бы, да ведь не знает он о подобном. книжку влом почитать.

а как же те люди которых классы — раздражают? :-)

К психологам пусть обращаются... Инструмент надо выбирать под задачи тот что подходит, а не на основе собственных комплексов. Кодеры боящиеся и/или необоснованно ненавидящие парадигмы, паттерны, ЯП и прочее не способны адекватно делать свою работу. Программист должен уметь отделять важное от второстепенного и находить эффективное решение поставленных задач. Если используется ООП, очень желательно использовать и инструментарий для этого предназначенный. Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла. Целенаправленное усложнение кода своими велосипедами - признак неадекватного ребячества.

Классы в крестах наглядный и стандартизированный инструмент, избегать их использования нет никакого смысла

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

[впрочем, уже чутьли не научно доказано что «наследование» это порочная практика — и об этом много кто говорил.. а в современных языках стараются вообще убрать «наследование» (на крайний случай заменить «наследование» на «примеси»)... так что тут я много говорить не будут и так всё ясно :)]

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

неужали программисту и времени-то своего деть некуда, кроме как думать на тему "как же я организую взаимодействие классов в своём коде?" (ответ: "ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода")

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

ООП это когда данные (объекты) лежат в основе алгоритма (всё вертится вокруг объектив и их состояний).. а мне может быть больше нравится когда в основе алгоритма лежат функции а не данные :-) — психолог лечит такие случаи? :-)

если в Классах используется наследование — то как мне глядя на код метода класса понять — используется ли именно этот код или же он где-то там перегружен в наследнике? (просматривать каждого наслденика?)

Надуманная проблема, если ты работаешь с объектом тебя не касается как и где реализован метод, в том вся соль инкапсуляции.

а если в классе НЕ используется наследование\перегрузка — то вообще какой тогда толк от такого класса? ну засунули группу функций под фигурные скобки и назвали не «функция» а «метод» и типа так стало круче? (в ООП это называется «инкапсуляция»)

а какой толк от инкапсуляции? :-)

Это позволяет как минимум стройно группировать функции к типам для рабты с которыми они предназначены. А наглядность заголовочных файлов в хорошо организованном проекте говорит сама за себя (самодокументация), а если ещё и добавлены ясные и лаконичные комментарии... Инкапсуляция не есть средство улучшения качества итогового исполняемого кода, она для упрощения понятности исходников, по сути своей просто расширяет модульный принцип программирования.

как мне определить — должна ли очереная «функция» быть «методом», или же реализовать её обособленно всё-таки как «функцию»?.. где эта грань?

Глупый вопрос. Зависит от назначения этой функции. Если это универсальная функция сортировки (хороший пример из Qt: qSort, qMin) то как и в голову здоровому человеку не придёт её в класс пихать. Если это функция специфична для класса (из того же Qt: QObject::parent, QObject::sender) для неё инкапсуляция и придумана. Если такие очевидные вещи являются сложностью для программиста, такой погромист должен менять профессию.

а парить себе мозги на тему protected\public и friend — зачем это было бы нужно, если бы вместо класса у нас просто была бы структура и внешние функции которые с ней работают? :-)

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

неужали программисту и времени-то своего деть некуда, кроме как думать на тему «как же я организую взаимодействие классов в своём коде?» (ответ: «ды ни как не организлвывай! просто наделай кучу функций и всё! при случае не забудь и передавать указатели на функции, в моменты когда нужно делегировать различные алгоритмы различным частям кода»)

А потом, спустя год ковыряй цать часов свой (хорошо если не пришлось чужой) говнокод, чтоб внести правку в пару строк. На что в нормальном ООП проекте уйдёт пять минут. Каша вместо кода - плохо, код должен быть понятным. Есть соревнования на самый запутанный код, но это же специальная олимпиада а не эталон профессионализма.

то есть я говорю о том что минимазилм в использовании классов — взят не из-за комплексов — а и из-за вполне практичных соображений :-)

C++ как частный пример очень фичастый и навороченный ЯП. Если ставить целью использовать побольше фич, хорошего не выйдет ничего. Минимализм правильная штука, но как всё хорошее он тоже хорош лишь в меру. Всему своё место и время. При проектировании с классами не всегда нужен полиморфизм и/или наследование. Шаблоны, друзья и прочее (а там чем дальше тем хуже) инструменты, которые стоит использовать когда именно они решают задачу оптимальным способом. Если начинать всё это пихать в код ради «крутизны», результат всегда плачевный. И кстати изучать их вплотную стоит только тогда, когда тебе они становятся действительно нужны. Столько говнокодеров понавырастало из товарищей стремящихся изучить и освоить все фичи ЯП и побольше паттернов и прочих плюшек. Стремление запихать везде и не к месту весь свой багаж знаний входит в привычку, впрочем как и ненависть к каким-то из них. Лучше бы изучали как работает ваш код, во что компилирует компилятор ваш int main() и прочие коды, как всё же работает стек, как устроенна куча и почему плохое проектирование ведёт к утечкам, разбирались бы для начала что такое указатель, что такое нить исполнения, как происходит передача управления и возврат из функции.

ООП это когда данные (объекты) лежат в основе алгоритма (всё вертится вокруг объектив и их состояний).. а мне может быть больше нравится когда в основе алгоритма лежат функции а не данные :-) — психолог лечит такие случаи? :-)

Где лечат не знаю. Мне нравится ООП, но я далеко не всегда прибегаю к нему. Всему своё место. ООП тоже не всегда оправдан. Основная тенденция сводится к тому, что чем сложнее проект тем логичнее использование ООП, но не всегда это так. Скажем ООП для потоковой обработки информации даст скорее накладники на вызовах конструкторов распарсенных из потока объектов, чем сделает исходник программы более понятным.

Но ведь невозможно одновременно пользоваться мозгами и плюсами, это вещи взаимоисключающие.

Мне нравится ООП

А разве в плюсах есть ООП? Это распространенное заблуждение. Причем распространено оно, преимущественно среди школьников и офисного планктона, пишущего на плюсах.

void x(int inumber, float fnumber, double dnumber = 0, float fnumber2 = 1)
{
...
}

2 последних аргумента — необязательны.

это очевидный нюанс

во-первых, он не уточнил, описать для кого — для действительно хорошо понимающего С/Паскаль — м.б. во-вторых, он это сказал до появления С++11 в актуальном состоянии

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

ну про «рисование GUI» я пожалуй соглашусь :-)