V2EX › BGLL 的所有回复 › 第 39 页 / 共 59 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 35 36 37 38 39 40 41 42 43 44 ... 59

❮

❯

2014-12-28 22:09:41 +08:00

回复了 liprais 创建的主题 › 分享发现 › 无聊的写了个脚本分析了下我的 iPhoto 图库

N9好评.

2014-12-28 20:51:44 +08:00

回复了 davidlau 创建的主题 › 问与答 › 如何长期保存数码照片？

永远不要把重要的东西放在一个篮子里

硬盘本地备份1、2个
国内云服务备份1、2个
国外云服务再备份1、2个
（最好加密并带恢复记录压缩后再上传）

2014-12-28 18:54:33 +08:00

回复了 aaronlam 创建的主题 › 前端开发 › 感觉 360 前端常用公共库弱爆啊！

中科大断过。嗯

2014-12-28 14:17:35 +08:00

回复了 Yamade 创建的主题 › 问与答 › 请问 http://pic.browser.360.cn/t0129be5a3970e5d046.jpg 这样的图片外链哪里可以上传?

V2EX上吗，V2EX只支持 imgur 、 V2EX Image Hosting、和微博3种图床的图

2014-12-28 11:50:33 +08:00

回复了 cjjia 创建的主题 › 随想 › 突然觉得人类(身体)太低级了。

抛弃肉体就好了，Matrix。
其实只要人类发现刺激人脑得到满足感的方法就好了，人类不需要做任何事，只要被刺激大脑，得到满足感天天快乐哈哈哈哈哈

2014-12-28 11:47:00 +08:00

回复了 itfanr 创建的主题 › 随想 › 为什么我要劝独立博主在 github 等 git 平台写博客

"虽然独立博客能有很大的自主性，但是一旦你哪天不续费了，博客就无法访问，很多好文章就打不开了....."
--没有网络服务能长久，微软厉害不？多少人被MSN空间坑了，Github能维持多久不关？谁也说不好

”在git平台写博客依然可以绑定域名，其他人可以很方便的fork源码和主题，文章也容易被保存和传播...。“
--不算优势，只是说这方面没劣势，fork文章也是......

”哪天自定义域名无法访问了，文章依然在，继续发挥余热几千年。“
--同第一条哪天Github像MSN空间、Google Reader一样关了.......还几千年...自己的主机空间一样可以备份,而且备份的更完整

要我说真正的优势只有一个暂时免费
但是劣势有很多，最大的就是不知道哪天就被墙了

2014-12-28 11:21:01 +08:00

回复了 ljcarsenal 创建的主题 › 问与答 › v2ex 的默认头像是根据账号自动生成的么？

这个自动生成的真丑

2014-12-28 11:13:04 +08:00

回复了 xinghuan 创建的主题 › 问与答 › 关于猜疑链

@MajestySolor
难道不能是人和野猪相遇一样，野猪被奴化成家猪
只是人科技水平有限不能从遗传物质层面奴化

水平够高，直接把人从生殖向导变成为了它们服务为向导

2014-12-28 11:09:30 +08:00

回复了 xinghuan 创建的主题 › 问与答 › 关于猜疑链

@a154312237
难道不是博弈论……

按我说
黑暗丛林法则还是无法解释费米悖论，文明数量够多，产生的几率够大，必然有文明在一定阶段是向外友善型的，必然会向外发出信息，像目前的人类一样，

消灭也不是最好的办法，遗传物质层面奴化才是最好办法。

2014-12-28 10:49:27 +08:00

回复了 typcn 创建的主题 › 站长 › 我都不知道原因，被莫名其妙攻击了好几天

难道不是有人些看到你的《根据 Hashcash 做的反机器人 CC 攻击算法》……

2014-12-28 10:43:06 +08:00

回复了 pcx3802482 创建的主题 › 问与答 › 大家现在还看电视么？

看cctv啊，新闻联播，学习社会主义核心价值观

2014-12-28 09:32:45 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@jox

是啊文件结尾会改变
C++里 ios::end 代表文件末尾指针，f.seekg(0,ios::end) 把读取指针定位到文件末尾指针。
文件改变了，取到的文件结尾也就不同。

你例子中的while(!f.eof()){...}，要是读取中文件变长了会接着读到新结尾，变短了还是会读到原来长度（因为有缓存机制）

要完全实时读取，得每写一个字节重新向系统获取一次文件结尾。

@msg7086
你说是簇吧簇是文件系统最小分配空间，扇区是磁盘最小分配空间，由硬盘上的固件决定。
要一个扇区存储多个文件对于文件系统来说貌似要多很多操作步骤间接完成感觉性能上不划算啊，各种小众文件系统就不知道了，反正NTFS、Ext 二大文件系统是只能一个扇区写一个文件。“inode之类的地方内嵌小文件了"把连续数据块一起处理省略 inode 的 extents？LLinux的东西我不了解。

2014-12-28 00:15:58 +08:00

回复了 alexapollo 创建的主题 › 程序员 › 最强的技术公司是哪一家？

@riaqn 百度难道不是IT部门很大的公关公司？

2014-12-28 00:04:22 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@jox
@jox

现在主流系统就Windows还兼容这种老掉牙的规则了。

也就是说现在的系统下程序得到一个文件就从磁盘系统知道文件的精确到字节起始和结束位置了（也就是起始指针和结束指针），文件尾的定义不就是结束指针的位置吗。

同时写入读取不矛盾啊，当然没有绝对的同时，还是有先后顺序的。有时候会用因为条件限制会用一个文件进行程序间的通信。

Unix下也和Windows一样通过磁盘系统得到文件头、尾啊。

@msg7086 现在的系统里文件也一样，一个扇区也只能存一个文件，只是磁盘系统封装了记录找到文件尾的操作。

2014-12-27 23:21:05 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@jox
跟内核是什么没关系，只是为了兼容过去的标准，微软特别注重兼容性（比如为了兼容CR、LF两种换行标准，windows下换行符直接就是CR+LF）。

简单的来说，程序从系统得到文件就是文件起始指针和结束指针，Windows下为了兼容性在文本模式时特别的把ASCII 26的位置当结束位置了。

2014-12-27 23:12:20 +08:00

回复了 bellchu 创建的主题 › 分享发现 › 迅雷真的修炼成流氓雷了

@wohenyingyu01 我也一直用的迅雷VIP版，暂时还没出现这种情况

2014-12-27 23:02:35 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@jox

系统从磁盘系统得到文件就知道文件首尾指针了。
具体怎么实现是磁盘系统的事了，程序不用管，大多数是把文件尺寸放在文件分配表里(FAT)。

以文本模式打开文件是特别的存在，有这个模式主要为了兼容性（该死的换行符，就因为这个换行符耗费了多少人的生命）顺便方便处理简单的文本。DOS特别为了兼容过去的CP / M系统（它的磁盘系统没法精确定位文件结束位置，因为它的记录文件大小只到扇区，一个扇区128字节，一个文件的结束可能在第1个字节也可以在第111字节，所以要一个结束符标记（关键他磁盘系统不把这个操作封装起来，交给人们在文件末尾写额外标识符））
然后Windows为了兼容DOS......

2014-12-27 21:33:52 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@jox
没错，所有的，包括现在的Windows8.1，SUB(ASCII 26)都是被当作文本末尾的
以标准的文本模式打开文件遇到SUB(ASCII 26)就会被当作结尾了，以二进制文件模式打开就不会有这个问题。

记录文件大小那是磁盘系统的事情了。

2014-12-27 21:04:41 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@jox EOF只是找到末尾后返回的“信号”，我说的是那个末尾
你说的“以前的系统”就是Windows，所有Windows中SUB(ASCII 26)都会被当作文本末尾

2014-12-27 20:43:49 +08:00

回复了 JoshOY 创建的主题 › Python › 关于读超大文件的问题

@JoshOY
你应该找到断点位置，看看断点是什么

1 ... 35 36 37 38 39 40 41 42 43 44 ... 59

❮

❯