V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  nevermoreluo  ›  全部回复第 4 页 / 共 9 页
回复总数  161
1  2  3  4  5  6  7  8  9  
153 天前
回复了 KJH 创建的主题 程序员 感觉.NET 比 Java 难多了
用.net 搞过两三个项目
感觉用 vs 上手.net 干活极快,有点基础就能干活,之前有个项目组都是其他语言转的同学看了两天直接干活的,没有负担

.net 这一套我想要吐槽的只有
- framwork 升级到 core 难受,历史包袱受限可以理解
- gui 框架太杂了,跨平台方案现在都没个定论,但是 win 上 wpf 确实好用,简单的直接 mfc 也行
- asp 那一套不习惯,看着难受
- 微软文档虽然啥都告诉你,但是有时候有点绕,干活来不及看
作为会计毕业的菜鸡来说说,你是无法从逻辑上跟我说通的,因为我进项少了。
你其实必须给再开 1200 元的发票,我明白你们业务逻辑没用,对我来说你只给我 1 元的发票就是账实不符,无法入账就这样。
到时候税务来查账,我肯定解释不出来,是不是还要拉你一起去税务局给解释解释?

税务专员: 哟?新说法,嗯,我听着,你继续
我有个问题
把 base64 去掉的时候,对程序做额外处理了吧,如果还用 string 传包体,图片还完整吗?怎么处理的,直接存到 string 然后\0 就不管了吗?
有没有部分图片小了很多很多?
所以有没有可能问题一直有 只是把 base64 去掉的时候,搞错东西了
157 天前
回复了 Chad0000 创建的主题 游戏开发 游戏开发都用啥电脑
该说不说的,有些 bug 就要差的机器才能复现。
单人开发感觉配置不要太好,不要太脱离群众,我看显卡 1050ti 就行 ( doge
158 天前
回复了 gl3081 创建的主题 程序员 开源了一个游戏服务中台,欢迎大家 Star
游戏中台这个词很陌生,不过一看到我就想到 GM ,然后居然没有。。。
而且 go 写的似乎也很小众,场景服务拿啥去搞个物理引擎
个人感觉房间的帧同步放中台感觉中台有点重了?
158 天前
回复了 MrZhangLo 创建的主题 生活 遇到了人生重要的选择
没腰斩不错了,回老家别想着有什么技术上深耕的岗位
不过 27 可以再犹豫一下,攒两年钱再回去也行,太早回去该给你催婚了,哈哈哈哈
还有周六那天双倍工资,一般大没事都不敢请,够吃几顿疯狂星期四了
之前没体验过单休的,除非缺钱,否则这边建议不考虑
单纯从利益角度双倍工资大概要上浮 17%
但是实际上体感很差,单休那周有点事情会让你更累,个人建议涨薪不到 25%以上感觉划不来,真的。。。
@Melville 太猛了,这种我以为只有新闻里面才有
@joker622 干他丫的,早点发起还有的赔,有个房产的朋友即使发起仲裁了也只能等着
@kera0a 这个行业不太需要竞争力,需要关系,但是关系这东西,离我这个打工仔太远,触摸不到
以下是在家不玩网络游戏不办公的个人建议

你可以先买一个 mesh 路由放客厅,先试试效果,大概率是不行,在买一个,再试→_→ 看起来三个应该就够了

不玩游戏无线应该也能随便组,最多客厅书房主卧各放一个应该就绰绰有余了,小米,linksys 都可以。
小米 ax6000+2 个 ax3000 ,或者直接 linksys 一组 3 个。

你可以先买两个,一个客厅一个卧室,在看看你书房隔了两堵墙之后效果咋样。之后看情况海鲜市场再淘一个

ax6000 放客厅,入口的门,厨房里的冰箱,中央空调,阳台的洗衣机,平时活动都要连这个的,其他放 ax3000


另外楼上说的智能门要 2.4G 其实有些空调啊,智能插头啊也是这个要求→_→

linksys 和小米都用过,没太过细致的测试,大致感觉 linksys 多少稳定点,隔堵墙小米 ping 有波动,但是小米便宜。linksys 白的容易发黄

玩游戏的话要不还是上有线吧,虽然 p 社单机战士表示又不是不能玩
没玩过肉鸽,但是暴鲤龙多重鳞片 电系自带电气场地。。。
爽文既视感,哈哈哈哈哈,下班可以试试
163 天前
回复了 raullf 创建的主题 Python 服务 10 多秒才返回是什么情况
1. 内网测试环境能不能复现
2. 打开前端页面点开 network ,看 timing ,至少排除前端或者证书问题
3. 我记得很多年前用过 django 就有 debug 模式(不过别用线上环境跑),https://github.com/jazzband/django-debug-toolbar ,排除 sql 问题
4. 如果前端和 sql 都没问题。。。。。 你懂我想说什么
@lasuar
应该不是的,他并没有做溢出处理,而是在编译时精确的计算了。
你可以简单打印以下这几个值看看。如果按他最大基础类型 uint64 算的话,溢出处理,和实际结果不对。

const Big = 18446744073709551617;
const OtherBig = Big + 1;
const BigI = OtherBig - 3;
@zonyitoo
因为没有声明类型,先入为主的以为跟 c++的 auto 一样编译时推断了。
看起来这个 const 在 go 里面有很多细节处理,学习了,谢谢大佬。
看到这个
https://stackoverflow.com/questions/38982278/how-does-go-perform-arithmetic-on-constants/38982889#38982889

大概理解了,在编译时把这个值处理了,运行时就不用考虑了,所以企图打印他会在编译时报错,但是计算可以。
谢谢各位大佬
@aminobody 1 << 100 超出 int 的存储范围了
@uiosun
这篇我看了 但是还是没搞明白这个 Big 到底属于什么类型。
或者说我的问题应该改为
对于 go 来说他既然可以运算 Small 的值,那么在运行时他拿什么类型处理 Big 这个超出他规定基础类型的对象的?
1  2  3  4  5  6  7  8  9  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2700 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 03:34 · PVG 11:34 · LAX 19:34 · JFK 22:34
Developed with CodeLauncher
♥ Do have faith in what you're doing.