считывание из файла чисел формата double

Цитата shm @ 23.06.17, 08:54

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

в одной функции встречаеются функции с одинаковым названием из разных либ? и такое часто случается?

Добавлено 23.06.17, 08:58

Цитата shm @ 23.06.17, 08:55

И на мой взгляд пространства имен - это более элегантное решение

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

Да и через std:: быстрее набрать тип через подсказку, чем вспоминать как он там пишется uniqe или uniqueue или unique, если конечно не в блокноте пишешь.

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

Цитата KILLER @ 23.06.17, 08:59

через std:: быстрее набрать тип через подсказку

+ удобно искать соответствующие "ветки" пространств имён, вот пример из реального проекта:

#pragma once
#include "../servlets.h"
#include "../../DB/dao/SpecificDAO.hpp"
#include "../../DB/dao/GuestsDAO.hpp"
#include "../../Model/GuestDTO.hpp"
 
 
namespace Servlets {
 
    class get_guests : public Servlet {
    public:
 
        get_guests() : Servlet("/get_guests", DBO::ADMIN) { }
 
        void doGet (HttpRequest *request, HttpResponse *response) { }
 
        void doPost(HttpRequest *request, HttpResponse *response) {
            
            unsigned int count    = request->getIntParameter("count");
            unsigned int offset   = request->getIntParameter("offset");
 
            if(count>100){
                count=100;
            }
 
            Properties   filters  = request->getPrpParameter("filters");
            DBO::DTOList guests;
            guests = DAO::GuestDAO::getGuests(&filters,offset,count); // получаем всех гостей из базы данных
            std::string data = HTTP::Service::JSON::create(guests,"data"); // преобразуем список гостей в json объект
 
            out<<data; // отправляем json данные
 
        }
 
    };
 
}

В подпространствах DAO - видны все сервисы под разные базы данных и таблицы, в конкретном сервисе видны все функции связанные именно с этой таблицей или сущностью. В общем, это реально упрощает жизнь.

Цитата _lcf_ @ 23.06.17, 09:02

киля, надо поменьше дыва дуть, тогда и запомнишь

А дыво то тут причем? Ты мне сходу скажешь сейчас как называется класс для работы с строковыми потоками и в каком хидере это находится? Когда ты часто что то используешь - оно у тебя откладывается в подсознании и ты пишешь это все на автомате. А когда ты раз в год какую то вещь используешь, то хоть дуешь ты дыво, хоть не дуешь - хрен ты запомнишь.
Так вот хорошим тоном, как выше сказали, правильно не открывать все пространство имен, а использовать только то, что тебе нужно. Если лень писать каждый раз std:: то можно написать например: using std::cout;
И использовать его. Хотя у меня уже на автомате пишется std:: и никак это не напрягает.

Любое явное лучше, чем неявное. Чёткое указание используемого интерфейса делает хорошо всем, и компилятору в последнюю очередь.

ну еще скажите this-> пишете? (конструкторы, операторы не в счёт)

Цитата _lcf_ @ 23.06.17, 11:58

ну еще скажите this-> пишете? (конструкторы, операторы не в счёт)

Если слишком много наследования, сложные классы и куча всего, да еще и не ты это все писал, то почему бы и нет? А как ты ищешь? Пол часа лазаешь по всем классам и наследованию, или поиском ищешь?

Добавлено 23.06.17, 12:15
Другое дело, что после того как нашел нужный метод, this-> можно и удалить, для гармонии.

Цитата KILLER @ 23.06.17, 12:14

А как ты ищешь?

ну обычно я с другой стороны прихожу - usages

Цитата _lcf_ @ 23.06.17, 11:58

ну еще скажите this-> пишете?

Естественно Даже там где это не требуется, просто потому что сразу видно что это не переменная взятая откуда-то, а поле текущего экземпляра.

Короче, _lcf_, как писать - дело твоё, но, смысл всех этих договорённостей можно понять только на практике, когда у тебя огромный проект, который живёт уже больше 5 лет, и ты должен его активно поддерживать, дополнять и изменять, без всего этого никто тебе ничего доказать не сможет, потому что ты не видишь реального преимущества такого подхода

хм, ну наш проект собирается 9 минут на 40ядерном ксеоне + 128Гб. и ему не 5 лет. последнее время одну глобальную штуку правлю, комиты - изменения в 70-80 файлах, и что-то я, блин, не вижу там обилия :: как и не страдаю от отсутствия каких-то подсказок. интерфейс класса - вот он, иерархия - вот она, использование - вот оно. скорее проблемы со всякими моделями - где, что, как и почему меняется, но это никак с пространством имен не связано

Цитата VisualProg @ 23.06.17, 13:37

просто потому что сразу видно что это не переменная взятая откуда-то, а поле текущего экземпляра.

ну почти в любом коде-стайле есть какое-то соглашение на этот счёт, у нас стандартное m_
да, и чистых сей у нас не так много, кутэ + куча своих враперов.

Сообщение отредактировано: _lcf_ - 23.06.17, 13:52

Цитата _lcf_ @ 23.06.17, 11:58

ну еще скажите this-> пишете?

Без надобности нет, все элементы класса уже в текущей области видимости. Та же ситуация, что и с пространствами имён, впрочем. Если бы ты был внимательнее, то заметил б прошлом посте к существительному "интерфейс" прилагательное "используемый".
Та же getline() в коде выше – вот что за getline() заюзал VisualProg в своём примере, если б не std:: перед ней? Ещё какая-то функция, которую он забыл расположить рядом со split()? Конечно, using бывают полезны и могут использоваться в ряде случаев, но не везде направо и налево. В локальной области видимости некой функции, например, вполне, т.к. используемые ею интерфейсы обычно известны. Глобальные же они только мешают. Если уж сильно напрягает длинная явная квалификация, лучше вместо using использовать namespace = .

Цитата Qraizer @ 23.06.17, 13:52

Глобальные же они только мешают.

а глобально это как? кто-то в хидерах юзинг пишет? или сипишники по стопицот строчек?
ну не должно быть объективных причин писать что-нибудь типа:

std::chrono::high_resolution_clock::now();

да еще и цать раз в пределах одной функции.
хотя, я думаю мы просто про разные вещи говорим, но глядя на код VisualProg, using на всю харю напрашивается

Цитата _lcf_ @ 23.06.17, 14:05

ну не должно быть объективных причин писать что-нибудь типа:

    std::chrono::high_resolution_clock::now();

да еще и цать раз в пределах одной функции.
хотя, я думаю мы просто про разные вещи говорим, но глядя на код VisualProg, using на всю харю напрашивается

Для меня предпочтительней именно такая запись, особенно если нужно ее вызвать не более 2-3 раз. А если тебе нужно писать такое 100500 раз(что крайне сомнительно), тогда можешь просто укоротить неймспейс как тебе Qraizer выше написал, аля:

namespace my_space = std::chrono::high_resolution_clock;

помоему это паранойя вспомнился анекдот про еврея, десять замков и цепочку. может оно, конечно, и правильно, но как по мне так избыточно.
вот с точки зрения компиля аргумент интересный, но я в этом не силен. типо явное указание пространства как-то ускоряет парсинг, сокращает время сборки или что?

Сообщение отредактировано: _lcf_ - 23.06.17, 14:18