Поиск методом аппроксимации

[8Observer8]

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

#include <iostream>
#include <stdlib.h>

int main()
{
    std::cout << rand() << "\n";

    return 0;
}

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

А если написать С++-заголовок, то сразу понятно, что std::rand - стандартная. Для избежания конфликтов имён придумали пространства имён. Такой код читается легко и нет конфликтов имён. Это обычная практика:

#include <iostream>
#include <cstdlib>

namespace ms {
    double rand()
    {
        // ...
        return 0.0;
    }
}

int main()
{
    std::cout << std::rand() << "\n";

    std::cout << ms::rand() << "\n";

    return 0;
}

[rrrFer]

А если написать С++-заголовок, то сразу понятно, что std::rand - стандартная. Для избежания конфликтов имён придумали пространства имён. Такой код читается легко и нет конфликтов имён. Это обычная практика:

Да, как я писал в первом посте - единственный выигрыш от cmath - пространство имен. Однако, есть 2 НО:
1) ТС заюзал using. Да, это плохо, сам он виноват.
2) когда придумываешь имена - надо стараться не брать имена из стандартной библиотеки. Это просто факт.
3) вот ты написал свой код, ну допустим у тебя есть библиотека ms (как выше) и юзер начал ее использовать. Что будет если юзер выполнит using ms и using std ? - да, юзер сам будет виноват, но и разработчику библиотеки в ms не стоило использовать имена из стандартной библиотеки, т.к. с большой вероятностью она будет подключена и за-using-а.

[8Observer8]

1) ТС заюзал using. Да, это плохо, сам он виноват.

Вот на этом и надо было акцентировать внимание. Сказать, что не юзай std, а напиши std::rand и #include <cmath>

2) когда придумываешь имена - надо стараться не брать имена из стандартной библиотеки. Это просто факт.

Не спорю. Всегда так надо делать. Обычно все функции - это методы какого-то класса. А если свободные, то их по смыслу лучше сгруппировать в пространство имён с подходящим именем

3) вот ты написал свой код, ну допустим у тебя есть библиотека ms (как выше) и юзер начал ее использовать. Что будет если юзер выполнит using ms и using std ? - да, юзер сам будет виноват, но и разработчику библиотеки в ms не стоило использовать имена из стандартной библиотеки, т.к. с большой вероятностью она будет подключена и за-using-а.

Это его проблемы. Надо писать ms:: так безопасно

Да всё просто. Пишем #include <cmath>, а в коде std::rand и сразу видно откуда функция

[rrrFer]

Вот на этом и надо было акцентировать внимание. Сказать, что не юзай std, а напиши std::rand и #include <cmath>

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

мне кажется, что cmath от math отличается тем, что заворачивает имена в пространство std. Но если прямо следом ты пишешь using namespace - то имена все равно попадают в глобальную область видимости и профита от cmath нет (по крайней мере я не вижу).

Это его проблемы. Надо писать ms:: так безопасно

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

Вопрос был не о именах вообще, а о панике, которую на abit навел код, а именно math.h - он явно воспринял это как катастрофу. Он явно считает, что С++ лучше чем Си во всем.

тут я уже теряю надежду на C++, но третья строка

using namespace std;

говорит таки о C++

Дак вот директива using, которая вроде как "говорит о С++ и поэтому хорошо" вовсе не такая хорошая, в частности.

четвёртая строка "int show (int *Mas,int n)" это не просто устаревший C++ это чистый Си, давайте делать всё таки в C++

Он выделяет "чистый Си", "устаревший С++" и "все таки С++". Поэтому я поинтересовался чем они друг от друга с его точки зрения отличаются.

Если ты так плотно влез в диалог - отвечай

[BaTpyXaaa]

Сообщение от abit

Странно, что никто Вам не ответил, да вот я не по ленился...
итак, с первой строчкой встречаем

#include<iostream>

отлично C++ нас ждёт и дальше вижу

#include <math.h>

ой, жаль, должно быть <cmath>, кстати зачем он тут?

тут я уже теряю надежду на C++, но третья строка

using namespace std;

говорит таки о C++, хватит это терпеть!
давайте по поряду, если речь идёт именно о C++, во первых...
четвёртая строка "int show (int *Mas,int n)" это не просто устаревший C++ это чистый Си, давайте делать всё таки в C++, проходится по строкам дальше не вижу вообще никакого смысла, там всё ясно... лучше расскажу основные приницпы как это должно выглядеть и что тут не так:
1) если глядеть на "int show (int *Mas,int n)" сразу заметно, что эта функция только показывает что-то, не надо int* Mas, лучше const int& Mas, а ещё лучше перегрузить friend оператор << для iostream
2) int Sort(int *Mas,int n) - не нужно, есть std::sort
3) по причине выше спускаюсь вниз и говорю сходу int *Mas= new int [n]; - рудимент, избавьте себя от этого, сейчас в C++ new/delete не в почёте, кстати а где вообще у вас delete? утечку памяти делаем? во первых есть std::vector для вашей задачи и уж совсем идеально std::map
4) пока внизу программы смотрю на код якобы "брал с Pascal", вижу " writeline", да это помойму Вас обманули, похоже на Visual Basic, а не Паскаль
5) по поводу самого метода поиска - решаемо в пару строчек в std::map (в варианте самобалансирующихся бинарных деревьев) но если вам нужно по отсортированному массиву это провернуть самостоятельно, то поясните что это вообще такое, я никогда не слышал про "поиск методом аппроксимации", к своему стыду, и гугл мне ничем помочь не смог, исходя из кода, который вы тут написали на якобы Паскале я делаю вывод что речь идёт о бинарном поиске, который замусолен где только возможно

Метод аппроксимации

Необходимо подсчитать количества выполненных операций сравнения для данного поиска.
То что я написал выше, не работает.

[rrrFer]

int *a;
int n;
int val;

int left = 0, right = n;

int nop = 0;

for (;;) {
  if (va == a[left] || val == a[right]) {
    nop += 2;
    cout << "+";
    break;
  }
  if (right - left < 2) {
    cout << "-";
    break;
  }
  int idx = left + (right - left)/2;
  ++nop;
  if (a[idx] > val)
    right =idx;
  else 
     left = idx;
}

Схематично, не проверял. Тут явно тьма ляпов (но тыж студент - исправишь).

[8Observer8]

Студентов нужно учить современному C++11, а не забивать им голову чистым Си и устаревшим C++98

Подведём итог

1) Не писать using namespace std; А писать явно std::rand

2) Всегда использовать заголовки с буквой c:

#include <cmath>
#includd <cstdlib>

3) Вместо обычных массивов использовать контейнеры. Пример:

#include <iostream>
#include <vector>

void showArray( const std::vector<int> &arr );

int main()
{
    std::vector<int> arr( 10 );

    // Fill arra
    for ( size_t i = 0; i < arr.size(); ++i ) {
        arr[i] = i;
    }

    return 0;
}

void showArray( const std::vector<int> &arr )
{
    for( int v : arr ) {
        std::cout << v << std::endl;
    }
}

[rrrFer]

Студентов нужно учить современному C++11, а не забивать им голову чистым Си и устаревшим C++98

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

Подведём итог

1) Не писать using namespace std; А писать явно std::rand

2) Всегда использовать заголовки с буквой c:

Тебе лечица надо.

[8Observer8]

Вредно учить студентов смеси Си и С++98 и при этом не иметь никакого представления о C++11 и С++14. Очень вредно. Это одна из причин почему получаются говнокодеры. И, к сожалению, это происходит, потому что некоторые преподаватели сами недоучки. Они нахватались поверхам информации из книжек, интернета, форумах, а практики никакой не имеют. Совершенно не понимают реалей и как эволюционируют языки Си и С++ и почему они развиваются именно так. Обязательно нужно показывать какие раньше были проблемы, как их решали костыльным способом и как теперь эти проблемы красиво решаются, и какие ещё есть проблемы, которые планируют решить в следующих версиях языка, например, в C++17

Си программа должна компилироваться сишным компилятором. Для этого можно, например, создать в VS консольный проект и создать файл с расширением main.c (не main.cpp!). Тогда компилятор не позволит говнокодить и вставлять C++ конструкции в Си программу. Языку Си нужно обучать отдельно от C++ и ни в коем случае не мешать их в кучу

[rrrFer]

Вредно учить студентов смеси Си и С++98 и при этом не иметь никакого представления о C++11 и С++14. Очень вредно. Это одна из причин почему получаются говнокодеры. И к сожалению это происходит, потому что некоторые преподаватели сами недоучки. Они нахватались по верхам информации из книжек. И совершенно не понимают реалей и как эволюционируют языки Си и С++ и почему они развиваются именно так. Обязательно нужно показывать какие раньше были проблемы, как их решали костыльным способом и как теперь эти проблемы красиво решаются, и какие ещё есть проблемы, которые планируют решить в следующих версиях языка, например, в C++17

Я тебе еще раз грю, в вузе учат программированию, а не конкретному языку.
Нафиг не нужны фичи и тонкости С++ 99% выпускников.
С++ в вузах берут потому что есть куча си-подобных языков, но при этом в той же джаве нет проблем с утечками в том виде, в котором они есть в Си и не надо там программисту использовать умные указатели (как и в куче других языков, в том же пхп, питоне и прочих). В пхп нет таких крутых как в С++ шаблонов, а шаблоны в С++ - это еще один язык (причем совсем другой - на функциональщину смахивает). МОжет не надо грузить бедных стдуентов тонкостями типа сокрытия имен при наследовании шаблонов в С++ ?- ни в одном другом языке они этих проблем не огребут.

Си программа должна компилироваться сишным компилятором. Для этого можно, например, создать в VS консольный проект и создать файл с расширением main.c (не main.cpp!). Тогда компилятор не позволит говнокодить и вставлять C++ конструкции в Си программу

Ты стопудово знаешь, что у С++ эпически высокий порог вхождения.
У Си порог вхождения несравненно ниже.
Страуструп считает, что изучение С++ надо начинать с подмножества Си и потом постепенно начинать использовать всякие фичи (ты про это можешь в его книге прочитать).
Мейерс аж в первом правиле (из 55) говорит что относиться к С++ надо как к конгломерату из 4 языков (в том числе Си).

А так то да, ты можешь рассказывать про эволюцию реалий С++