排序后我得到了奇怪的输出
如果使用scanf
提供输入,则该行会导致错误。输出是一些奇怪的安排。 (我评论了这一行)
如果我使用cin
,输出就可以了。此问题也不存在于在线编译器中。同样的事情发生在不同的计算机上。
例如,如果我输入
5
23 44 32 2 233
输出
32 23 233 2 44
代码:
#include <iostream>
#include <cstdio>
#include <cstring>
#include <cmath>
#include <algorithm>
#include <iomanip>
using namespace std;
int main()
{
unsigned long long int n=0,i=0;
// cin>>n;
scanf("%llu",&n);
unsigned long long int arr[n];
for(i=0;i<n;i++)
{
// cin>>arr[i]; //if use this no error but if use next line it is
scanf("%llu",&arr[i]); //causing error
}
sort(arr,arr+n);
for(i=0;i<n;i++)
{
// cout<<arr[i]<<" ";
printf("%llu ",arr[i]);
}
return 0;
}
答案 0 :(得分:0)
如果使用cin
有帮助,那么可能%llu
是给定指针的错误标志。检查编译器的文档并查看long long
对它的含义,并查看库的printf/scanf
doc。
答案 1 :(得分:0)
可能发生的事情是%llu
对于您的编译器是错误的
例如,如果您使用-Wall
标志在MinGW中使用g ++编译程序以获取所有警告,则可以得到:
a.cpp: In function 'int main()':
a.cpp:16:20: warning: unknown conversion type character 'l' in format [-Wformat=]
scanf("%llu",&n);
因此编译器将忽略额外的l
并将输入扫描为%lu
。
如果您在32位系统上进行编译,则长整数最多可能是32位长,即4个字节
因此,扫描的数字将占用内存中的4个字节,因为arr[n]
数组是一个长长数组,即每个元素是64位--8个字节,每个元素的前4个字节将由scanf写入。登记/>
假设您使用的是小端系统,这4个字节将是long long元素中最不重要的部分。最重要的部分将不会被写入,并且可能包含垃圾。
然而,排序算法将使用每个元素的完整8个字节进行排序,因此将使用每个元素最重要部分中的垃圾对数组进行排序。
由于您在Windows 32位系统上使用代码块,请尝试使用"%llu"
替换所有出现的"%I64u"
。
答案 2 :(得分:0)
有各种可能的解释。最有可能的是编译器(或库或运行时),其中scanf()
不能正确支持%llu
类型的long long unsigned
格式。
long long
类型不是C的正式部分,而不是C ++之前(来自内存)2011标准的一部分。结果是,根据编译器的年龄,支持从不存在到部分(您所看到的)完成。
实际上,由于C ++流功能(operator>>()
等)的组织方式,更改C ++流以支持新类型(如long long unsigned
)比更改CI更容易/ O。根据设计,C ++流更加模块化(operator>>()
是为每种类型重载的函数,因此更容易添加对新类型的支持,而不会破坏处理现有类型的现有代码)。 CI / O函数(如scanf()
)以允许更多单一实现的方式指定 - 这意味着,为了添加对新类型和格式说明符的支持,有必要更改/调试/验证/验证更多现有函数码。这意味着它可以合理地花费更多的精力 - 因此是时间 - 来改变C I / O而不是C ++ I / O.当然,YMMV在这个论点中 - 取决于图书馆开发人员的技能。但是,实际上,标准C ++流的实现更加模块化 - 因此更容易维护 - 通过各种措施而不是C I / O功能是公平的选择。
此外,虽然您没有问,但unsigned long long int arr[n]
n
所在的构造std::vector
是无效的C ++。最好使用标准容器,例如#version 440 core
#extension GL_ARB_texture_buffer_object : enable
#extension GL_EXT_texture_buffer_object : enable
。