Ура! Заработало!

[AMD]

Еще вопросик. Зачем нужны short и long, нельзя было что-ли сделать только одну int? А то я так и не понял смысла их приминения.

int - размер машинного слова, с ним гарантируется масимальная скорость работы
char - целое размером 1
short - между ними, зачем нужен не знаю, обычно это 2 байта.
long - больше или равно int-у, максимальное целое, с которым можно работать
ещё есть long long, но это кажется нестандартный тип.

вроде так, может где соврал.

что то я непонял?

int по идее имеет 2byte и он от -32767 до +32767

Ты хотел сказать что char имеет 1byte наверное?

long насколько я помню имеет 4байта

Вопрос сколько байт имеют short и longlong?

[Red Gremlin]

Еще вопросик. Зачем нужны short и long, нельзя было что-ли сделать только одну int? А то я так и не понял смысла их приминения.

int - размер машинного слова, с ним гарантируется масимальная скорость работы
char - целое размером 1
short - между ними, зачем нужен не знаю, обычно это 2 байта.
long - больше или равно int-у, максимальное целое, с которым можно работать
ещё есть long long, но это кажется нестандартный тип.

вроде так, может где соврал.

что то я непонял?

int по идее имеет 2byte и он от -32767 до +32767

Ты хотел сказать что char имеет 1byte наверное?

long насколько я помню имеет 4байта

Вопрос сколько байт имеют short и longlong?

int системно-зависим, поэтому и существуют short и long - они фиксированные

[AMD]

int системно-зависим, поэтому и существуют short и long - они фиксиированные

short имеет 2byte и он от -32767 до +32767

а int равен либо short либо long в зависимости от системы

[rr-rustik]

В своих программах я пока использую только #include <iostream> Вопросы вот в чем: хде находятся такие включаемые файлы? Какие они вообще есть. И второй вопрос немного забегая фпиред. Таким эже способом я могу включать и свои файлы? Например для работы файла my2.cpp мне нужно использовать файл my1.cpp Я его буду включать #include <my1.cpp> или по-другому? Эта инфа пока просто для сведения. До этого по учебнику я пока не дошел.

[Red Gremlin]

В своих программах я пока использую только #include <iostream> Вопросы вот в чем: хде находятся такие включаемые файлы? Какие они вообще есть. И второй вопрос немного забегая фпиред. Таким эже способом я могу включать и свои файлы? Например для работы файла my2.cpp мне нужно использовать файл my1.cpp Я его буду включать #include <my1.cpp> или по-другому? Эта инфа пока просто для сведения. До этого по учебнику я пока не дошел.

По порядку:
находятся они в /usr/include
есть они самые разные
сам cpp включать ты скорее всего не будешь (если не совсем ненормален), а включать ты будешь .h
#include "my1.h" как в my1.cpp, так и my2.cpp; в обшем еще узнаешь

[rr-rustik]

В своих программах я пока использую только #include <iostream> Вопросы вот в чем: хде находятся такие включаемые файлы? Какие они вообще есть. И второй вопрос немного забегая фпиред. Таким эже способом я могу включать и свои файлы? Например для работы файла my2.cpp мне нужно использовать файл my1.cpp Я его буду включать #include <my1.cpp> или по-другому? Эта инфа пока просто для сведения. До этого по учебнику я пока не дошел.

По порядку:
находятся они в /usr/include
есть они самые разные
сам cpp включать ты скорее всего не будешь (если не совсем ненормален), а включать ты будешь .h
#include "my1.h" как в my1.cpp, так и my2.cpp; в обшем еще узнаешь

Спасиб за инфу, премного благодарен.

[v04bvs]

Еще вопросик. Зачем нужны short и long, нельзя было что-ли сделать только одну int? А то я так и не понял смысла их приминения.

int - размер машинного слова, с ним гарантируется масимальная скорость работы
char - целое размером 1
short - между ними, зачем нужен не знаю, обычно это 2 байта.
long - больше или равно int-у, максимальное целое, с которым можно работать
ещё есть long long, но это кажется нестандартный тип.

вроде так, может где соврал.

что то я непонял?

int по идее имеет 2byte и он от -32767 до +32767

Ты хотел сказать что char имеет 1byte наверное?

long насколько я помню имеет 4байта

Вопрос сколько байт имеют short и longlong?

sizeof(char) = 1
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

это всё, в чём можно быть уверенным.

сам cpp включать ты скорее всего не будешь (если не совсем ненормален),

справедливости ради стоит отметить, что иногда можно разделять интерфейс и реализацию шаблонных классов по разным файлам и подключать последний в конец первого.
Т.е.
blah.h
template<typename N> class Blah { ... };
#include "file.cpp"

blah.cpp
template <typename N> Blah<N>::Blah() { }
...

[sergio]

Еще вопросик. Зачем нужны short и long, нельзя было что-ли сделать только одну int? А то я так и не понял смысла их приминения.

int - размер машинного слова, с ним гарантируется масимальная скорость работы
char - целое размером 1
short - между ними, зачем нужен не знаю, обычно это 2 байта.
long - больше или равно int-у, максимальное целое, с которым можно работать
ещё есть long long, но это кажется нестандартный тип.

вроде так, может где соврал.

что то я непонял?

int по идее имеет 2byte и он от -32767 до +32767

Ты хотел сказать что char имеет 1byte наверное?

long насколько я помню имеет 4байта

Вопрос сколько байт имеют short и longlong?

sizeof(char) = 1
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

это всё, в чём можно быть уверенным.

Остается добавить, что слово byte, кем-то употребленное, некорректно без уточнений. В этом конктексте имеется в виду машинный байт - это минимальная адресуемая единица памяти на платформе. Она не обязательно 8 бит.
Из-за этой бурды, словом байт не пользуются. Там где речь идет об информации (битах) - во всех стандартах оперируют термином "октет" (8 бит), а в Си и Си++ - термином char. Согласно легендам, в некоторых более других платформах, char может быть и 32бит. И может оказаться, что sizeof(char) == sizeof(short) == sizeof(int), к примеру.

Тип long long есть стандартный тип для C99. В GCC он разрешен для Си ++ (или может быть разрешен/запрещен) как GNU extension.

Гм, помимо того, кажется, размеры типов (long) могут отличаться для i386 и amd64, и, кажецо, там были различия в них между Линукс и выньдовс на amd64 (?). Надо бы уточнить...

По инклудам.
Можно #include "my.h"
Можно запускаться с, кпримеру,

Код: Выделить всё

gcc ... -I ~/include ...

и тогда #include <my.h>, а свои "стандартные" заголовки держать в своей инклуд директории. Можно один раз прописать путь к ней в переменную в профиль, и запускать компилятор как всегда...

[elf74]

Маленькое замечание - лучше не писать using namespace std, это "ленивый" подход. Пиши вместо cout - std::cout.

Что-то мысль пришла... Да еще первого сентября...
А нельзя этот std::cout задефайнить?

Вопрос сколько байт имеют short и longlong?

sizeof(short) и sizeof(long)...
Все зависит от архитектуры машины и распределения памяти.

[Uncle_Theodore]

Что-то мысль пришла... Да еще первого сентября...
А нельзя этот std::cout задефайнить?

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

[sergio]

Что-то мысль пришла... Да еще первого сентября...
А нельзя этот std::cout задефайнить?

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

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

[v04bvs]

Что-то мысль пришла... Да еще первого сентября...
А нельзя этот std::cout задефайнить?

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

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

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

Код: Выделить всё

switch (var) {
case MY_VALUE_1: fprintf(stderr, "var = MY_VALUE_1");
...
case MY_VALUE_20: fprintf(stderr, "var = MY_VALUE_20");
}

очевидно же, что код

Код: Выделить всё

 switch (var) {
#define CASE(x) case X: fprintf(stderr, "var = " #x)
CASE(MY_VALUE_1);
 ...
CASE(MY_VALUE_20);
#undef CASE
 }

быстрее писать, в нём меньше шансов ошибиться, проще сопровождать, и тд тп. И этого кроме как прямой текстовой заменой никак не сделать.
Бывают конечно абсолютно идиотские применения, но это с любым мощным инструментом бывает.

[elf74]

В своих программах я пока использую только #include <iostream> Вопросы вот в чем: хде находятся такие включаемые файлы? Какие они вообще есть. И второй вопрос немного забегая фпиред. Таким эже способом я могу включать и свои файлы? Например для работы файла my2.cpp мне нужно использовать файл my1.cpp Я его буду включать #include <my1.cpp> или по-другому? Эта инфа пока просто для сведения. До этого по учебнику я пока не дошел.

Есть такое понятие "модульное программирование". Оно бывает нужно тогда, когда возникает нужда разбить код на функциональные части независимые друг от друга. К примеру, в указанной ранее Вами задаче №2 части 3 (или №3 части 2 ) из главной функции main() вызываются две другие функции, написанные Вами. Вот их и можно было выделить (это исключительно для примера) в два отдельных header-файла, допустим foo1.h и foo2.h, которые уже можно было подключить после строчки
#include <iostream>
следующим образом
#include "foo1.h"
#include "foo2.h".
Как-то, в качестве эксперимента, я пробовал помещать свои собственные h-файлы в /usr/include, чтоб не копировать их из проекта в проект, и вызывать их приходилось уже как
#include <foo1.h>
#include <foo2.h>...

[sergio]

Есть такое понятие "модульное программирование".
Вот их и можно было выделить (это исключительно для примера) в два отдельных header-файла, допустим foo1.h и foo2.h, которые уже можно было подключить после строчки
#include <iostream>
следующим образом
#include "foo1.h"
#include "foo2.h".
Как-то, в качестве эксперимента, я пробовал помещать свои собственные h-файлы в /usr/include, чтоб не копировать их из проекта в проект, и вызывать их приходилось уже как
#include <foo1.h>
#include <foo2.h>...

Класть свои собственные в общесистемный каталог - сомнительное решение, однако.
Кроме того, в заголовках .h по канону не должно быть определений (невстраеваемых) функций, только объявления... иначе зряшная работа компилятору и другие беды...

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

Все так, но товарищ интересовался дефайном чтоб отделаться от std:: и заодно не набирать using namespace...
Разумеецо случаи - они всякие бывают. Но осмелюсь предположить, что в Си++ макросы чаще всего - либо ненужны просто, либо нужны как костыли, чтобы уменьшить борьбу и ввод в чьей-то чужой кривой архитектуре. В Си - там немножко другое, там потребности в них ширше.

[v04bvs]

Класть свои собственные в общесистемный каталог - сомнительное решение, однако.

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

[sergio]

Класть свои собственные в общесистемный каталог - сомнительное решение, однако.

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

...более чем одним пользователем - тогда да.
Но и то - не факт. Поскольку если несколько пользователей работают не просто с общими заголовками, а с общим проектом - то у них и для проекта есть папка или аккаунт с групповым доступом... тогда инклуд можно туда.
Если заголовки пользуются юзерами каждым для своих целей - тогда пакет и в системные каталоги..

[elf74]

Все так, но товарищ интересовался дефайном чтоб отделаться от std:: и заодно не набирать using namespace...

rr-rustik, выздоравливайте быстрее, а то тема с этими дефайнами и инклудами шустро вкривь уйдет

[v04bvs]

...более чем одним пользователем - тогда да.

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

[sergio]

Соответственно создавать себе проблемы из за идеологии смысла не вижу.

Ну скажем, еще такие соображения.
Если мы ставимся пакетом в системные директории, мы рискуем конфликтами по именам
- пакета
- файлов.h и поддиректорий системного include
(со вторым траблы конечно можно огрести неменьшие и в своем инклуде, если перекрыть что-то косвенно кому-то нужное...)
И, если это _свои_ хедеры - есть вероятность, что в них что-то придется доделывать по ходу работы (над проектами) ==>> придется править исходники пакета, пересобирать пакет, sudo, и его upgrade-ить...
Т.е. все реально, но во-первых для этого надо освоить идеологию и процедуру изготовления пакетов, во-вторых - настроить и автоматизировать весь этот процесс, т.е. освоить инфраструктуру с инструментарием... иначе как раз вот тут и будут проблемы. Дело конешна хорошее и правильное, но у программеров оперативная память с цпутайм тоже не беспредельны.

[v04bvs]

я плохо понимаю, почему оно так получается, но судя по тому, что в дебиане более 15 тысяч пакетов (и я думаю, хедеров в них хватает), конфликты имён файлов/пакетов - ситуация редкая. Кстати пакетный менеджер кажется предупреждает, когда один пакет устанавливает файл, который уже установил другой пакет. Т.е. при определённой культуре наименований это легко не допустить.

Создание пакетов - действительно штука необычная, и требующая времени для освоения. Впрочем когда инфрастукрута создана - пакет собирается одной командой. Кстати если над проектом работает несколько человек - теоретически можно организовать центральный репозиторий, с которого всем будет достаточно просто обновлятся. Впрочем я сомневаюсь в жизнеспособности этого варианта по разным причинам.
Да и вообще для пользователя debian-а рано или поздно возникаеи компромисс - делать свой пакет или создавать бардак в системе
Кстати говоря, если разработчик пишет open source-ную программу, многие будут ему благодарны за папочку debian в каталоге с проектом

[eduard_pustobaev]

Кстати пакетный менеджер кажется предупреждает, когда один пакет устанавливает файл, который уже установил другой пакет.

Более того, apt его даже ставить не захочет. А если поставить, то broken депенденсом будет значится в системе.
P.S. Подумал чуток, могу ошибаться. Но вроде так оно и было.

[sergio]

я плохо понимаю, почему оно так получается, но судя по тому, что в дебиане более 15 тысяч пакетов (и я думаю, хедеров в них хватает), конфликты имён файлов/пакетов - ситуация редкая. Кстати пакетный менеджер кажется предупреждает, когда один пакет устанавливает файл, который уже установил другой пакет. Т.е. при определённой культуре наименований это легко не допустить.

Когда очередной пакет добавляется/обновляется мэйнтейнерами в дистрибутив - конфликты решаются, файлы переименовываются.
Если ваш пакет не в составе дистра, то:
- остается проверить, что ни один из устанавливаемых вашим паком файлов не находится в дистрибутивном Contents. Возможно, в инструкциях создателя пакетов даже написано, как это эффективнее сделать.
- молиться, чтобы в какой-нибудь из 15 тыщ пакетов дистра не добавили файл, совпадающий с вашими - дистроводы-то о ваших не в курсе. =)

Словом, надо разбираться - и тогда все будет хорошо.
Тот кто спрашивал - хелло ворлды осваивает, ему пока что-нить попроще надоть. =)