- 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
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
#include <conio.h>
#include <stdio.h>
const int SIZE = 33;
void DecToBin (unsigned int num, char *bin)
{
int i,j;
char tmp[SIZE];
for(i=0; num; num>>=1, i++)
tmp[i] = (num&1)?('1'):('0');
for(j=0; j<i; j++)
bin[j] = tmp[i-j-1];
bin[j]='\0';
}
unsigned int shl(unsigned int num, int shift)
{
return (num << shift) | (num >> 32 - shift);
}
void main()
{
int n, m;
scanf("%d", &n);
char bin[SIZE];
DecToBin(n,bin);
printf("%s\n", bin);
m = shl(n, 35);
DecToBin(m,bin);
printf("%s\n", bin);
_getch();
}
Еще одна очередная лаба, но уже код преподавателя, который он дал в качестве примера. Сказал что код на C++ (к вопросу, где здесь с++), и что нам нужно переписать его на "яве".
Follow us!
это законно и в с++, если implementation это позволяет (например, вижуал студия)
г++ это не позволяет (имеет право), поэтому и ругается
rol
http://ideone.com/1fGuw
Что оказалось. С стандартные библиотеки - не предоставляют, зато можно в восьмеричном. Распечатать число за произвольным основанием нельзя (printf). Штатные инстументы С++ (cout) - тоже можно, как и в С, за основанием 10, 16, и 8, ни бинарного, ни произвольного нет. Буст (format) - тоже надо писать самому. Но зато есть в Qt QString.
char * itoa(int value, char * str, int base);
ну а касательно плюсов - для хелловорлда можно и std::bitset приладить для этого (см мой коммент выше) :)
какбы считается что программист может в уме справиться с квартетом бит
а октальную систему не хоронят ради традиций 197х и tar
32 разрядное число займет четверть экрана, вот и прикиньте вероятность опечататься и/или пропустить опечатку в этой каше из ноликов и единичек
поэтому вопрос переведен в категорию профпригодности
Ну а если серьезно, то мне в реальной жизни нужно было один раз написать сериализацию double, и нужно было распечатывать все биты в двоичном представлении, чтобы точно понять правильно я это делаю или нет. Так что аргумент абсолютно надуманый.
для одного случая в жизни можно соединить вместе два колеса, руль и педаль, тем более для отладки
Поэтому из-за одного-двух раз в жизни включать вывод в двоичной системе в стандартные библиотеки имхо глупо. Кому надо - за 5 минут навелосипедит себе реализацию. Так что аргумент абсолютно надуманый.
Подскажите-ка нам, как нам в CL получить аргументы командной строки
Лисп - пример осымсленного подхода к проблеме. Во многих языках подход такой же. Если нужно распечатать число за произвольным основанием, есть какая-нибудь штатная функция для этого. А в С с какого-то перепуга есть вместо сделать одну универсальную функцию, сделали 3 не-универсальные. В итоге, как практика показала, одна из них вообще практически никогда не нужна.
Недостаток языковых средств взаимодействия с окружением просто так восполнить нельзя.
> В Лиспе еще много чего нет
Зато там много чего совершенно ненужного.
Самый богатый и удобный язык в плане стандартной библиотеки, с моей точки зрения, - python. На сишку же грешить смысла нет - она никогда не претендовала на роль удобного в использовании языка с богатой библиотекой, и она прекрасна в своей наготе.
Бусты всякие не претендовали на роль языка с богатой билбиотекой? Та че, правда чтоле?
http://ideone.com/7wCkF
Поэтому это не печать, а что-то другое.
http://liveworkspace.org/code/be68efe5509626b3a34806e2a896b46c
да и про вот такой штатный способ (еще раз):
Видимо, я пользуюсь крайне нетрадиционным подходом...
Почему на python, к примеру, очень даже имеет смысл, а на Lisp нет?
Питон и так написан на Си, и поэтому общается с системой на "понятном" ей языке. Т.е. это по-сути Си программа-интерпретатор, котрая выполняет Си-же код.
Ну и, понятное дело, что речь идет о реализациях, не предназначенных для встраивания в другие окружение. Для последних сама по себе идея аргументов командной строки не имеет смысла.
Юниксовая архитектура каналов и фильтров достаточно гибка, чтобы объединять программы, написанные на любых языках, способных к вводу/выводу.
Юниксовая система предполагает, что все что в ней используется использует Сишные конвеции вызовов функций. Я не понял в чем тут гибкость проявляется. Любой другой язык / среда, которые будут рабоать с системой должны делать это посредством Сишных АПИ, ну или повторить их в точности... других вариантов нет.
Что касается выполнения кода - то, например, у SBCL - свой формат исполняемых файлов с машинным кодом, не похожий вообще на ELF, и если специально системные вызовы не используются (т.е. нет вызовов через foregin function interface), то и соответственно, нет никаких обращений к Си рантайму.
Ну собственно логично. Вещь в себе. И если к системе, использующей сишные апи, лисп прикрутить можно, и он даже работает, и отлично пользуется средствами системы, то к лисп машине нельзя прикрутить ни одного другого языка. Вообще. Разве что DSL на лиспе, или интерпретируемые им же скрипты.
А мои жабо-программы хранятся в .class-файлах, упакованных в .jar архивы, но это никак не мешает мне передавать им аргументы командной строки или использовать их в пайпах
Его рантайм является. Он кстати написан на си, и довольно маленький. А вот сам интерпретатор лиспа и прочее хранятся в снапшоте, который подгружается этим рантаймом.
Ага. Многометровый снепшот оперативки. К которому опционально подклеен рантайм. (Писали тетрис на CL в SBCL, знаем).
Аль совсем башкой залип?..
Где бы что ни говорили --
Все одно сведет на Лисп!
ошибочка вышла: не напрямую с ядром, а напрямую с устройствами, заставляя пикселы на вашем мониторе светиться без участия ядра
Юниксовая система предполагает, что в конечном счёте вызываются функции ядра для записи в файл и чтения из файла, и ничего более. Язык реализации и принятые в нём конвенции вызовов не имеют никакого значения.
Функции открытия и закрытия файлов смотрят на вас с недоумением.
Хм. Ну одними stdin'ами и stdout'ами сыт не будешь... А как же работать с устройствами, с прочими файлами?