V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  GeruzoniAnsasu  ›  全部回复第 18 页 / 共 140 页
回复总数  2783
1 ... 14  15  16  17  18  19  20  21  22  23 ... 140  
@villivateur

> 如果是其他部分的 bug ,但我这里的 testVec 是局部变量。难道是其他地方把堆区破坏了吗?

vector 实际用到的内存一律在堆上,跟对象本身分配在栈上还是堆上无关。
这种崩溃 bug 基本上都是 heap corruption ,建议还是开一下 santinizer 或者 valgrind 看看有没有帮助。



heap corruption 是最难调的…… 因为导致污染的地方和触发 crash 的地方可能相差十万八千里…… 祝好运
你知道自己身体指标不正常后,你能做什么?

哦,医生告诉你了一些措施 —— 但难道你身体出毛病之前就不知道那些措施吗?
总之先记住这句话:

绝望感只是错觉。


/t/687320 #66
/t/581133 #255
/t/495443 #70
/t/570928 #13
/t/581133 #65
/t/490763 #4
2023-05-12 13:44:50 +08:00
回复了 wayne3602 创建的主题 问与答 来到大学,感觉进入了社会
我觉得只是人家跟你真没那么熟。大学连课都不完全重合,你细想一下大家真正交往的时间有多少?


大多数同学其实也还是陌生人,维持陌生人的关系依赖的是契约(人情和利益交换本质上也算借贷契约),不靠也不需要推心置腹的情绪共同体。
2023-05-11 10:28:07 +08:00
回复了 kaiseryang 创建的主题 生活 如果不考虑生活成本,大家最想居住的城市是哪里
阿勒泰
Garmisch Partenkirchen
Queestown

四季轮流住
@andyJado 因为通常发这种内容的人想不到什么深刻或重大的变革事件,他一说「行星」,那我想所有人都知道的,与「我熟知的事物『颠覆』了」能对应上的只有这个了。


—— 除非他是把自转或进动效应之类的天体运动想象成「颠覆」,那也可以,那也挺乐的
@acerest 句子再长也是主谓宾定状补。时刻检查语句的主语,确保与自己想表达的主要对象一致,确认每个定语短语和从句的结构也都正确,且使用了恰当的连接词。语法结构正确清晰,传递的信息明确又够精炼,阅读感受就「流畅」了。

打字写文章这种事比说话还是容易不少的,我口头表达也容易磕绊,但写字是有充足的反复阅读检查写出来的句子的机会的。


ref: https://www.v2ex.com/t/898465#r_12396787
2023-05-09 16:20:26 +08:00
回复了 luworld 创建的主题 问与答 一天三千块钱买菜,你会怎么规划?
一家三口人……

你都是一个一天能消费三千块用于买菜的家庭了

你还只做三个人的饭???



你的司机在不在你家吃?厨师呢?网管呢?清洁阿姨呢?孩子家教呢?瑜伽老师呢?你家还有两只阿拉斯加和 10 只布偶猫呢,它们不能只吃商品粮吧?

孩子的夜宵点心得准备点蛋糕吧?一两百块的便宜货你能放心?

每天都得喝的咖啡茶酒水,一罐一千也就泡两三壶,这不多吧?咖啡豆也差不多这个价,100 克够喝几天啊?
不是 OP 的表达能力有问题,而是他在一厢情愿地自我发散,把主题附会到根本不相关的事物上。

- 蚊帐从挂绳进化到支架根本不是什么「自我推翻」,这是材料工艺进化和产品不断升级的结果。你今天用到的蚊帐全是带支架的不是因为蚊帐有自主能动性,而是有很多即使生产传统产品利润很低也在不断思考怎样改善产品缺陷的实业从业者。

- 冥王星从行星降级为矮行星也与「推翻」毫无关联,它是人类长达一个世纪以来的天文观测换来的对科学体系的修订。类似的事还有基因工程对动植物分类学的修订,这些事件体现的是「假设-求证」这条科学之路对真实世界的不断趋近,证明我们的科学研究手段是有效的、正确的。

- 「一切在自我推翻的速度会越来越快」没有因果上下文,这是 OP 的无端想象。

- 「不敢或不能推翻自我的被时代抛得越远」,同上。
2023-05-08 08:02:31 +08:00
回复了 itechnology 创建的主题 程序员 怎么设计一张表来保存数字区间和单选类型的配置数据?
@itechnology

如果要存进 mysql 里,那隐含的含义就是,这些数据是要相互建立查询关系的。如果确实如此,那我真建议先用 UML/ER 之类的图表辅助手段搞清楚每个对象主体包含哪些字段,字段和实体的相互关系如何(多对一?一对多?)


我前面的回复给了一个保存多区间(实际上是保存二元判定函数)的例子,那个方法可以保存由任意多简单逻辑组合成的二元判定。

但直到目前的描述我还是不确定你是否遇到的是需要保存任意复杂二元判定的场景。「标准」是否是一个可保存的实体(意味着很可能需要一个以「标准」作为 primary key 的表)?还是实体上的 bool 字段(意味着要先搞清楚哪个实体要保存「是否标准」这个字段)?


而且当你把两个问题放在一起的时候就更显得迷惑,如果按照问题 1 的描述,系统模型应该是前者,一个属性对应一个「标准」对象和一个「非标准」对象,每个标准 /非标准对象对应若干由逻辑符号(开 /闭)和数字组成的判例;而问题 2 中又在描述一个属性对应若干但固定数量的判断,每个判断是一个标准 /not 标准的二元结论,这描述的就是后者的场景。




或者可以不直接从数据库层面考虑,程序面向对象的建模与数据库建模是完全一致的,代码里的 class 对应数据库中的表,class 的字段对应表中的列,如果程序中对这些结构已经有良好定义的表示,照着 orm 的思路抄进数据库里就完事了,如果程序也还不能处理,那完全可以先尝试把不落库的逻辑实现出来,这是可以反复实验的,等代码模型可以用了再转化成数据库模型。
2023-05-07 23:12:34 +08:00
回复了 itechnology 创建的主题 程序员 怎么设计一张表来保存数字区间和单选类型的配置数据?
虽然这么说有点不太尊重,先道个歉…… 但我每次看到这种无法把需求抽象成概括性问题的帖总会觉得,这人想不出做法是一点也不冤。


首先要考虑的问题:这些数据谁来处理?可计算吗?向量维度是可变的吗



--------

比如你提的第一个需求,假设(反正你没说清)这种数字区间是用来做判断的,比如系统有个功能叫「设定标准」,标准=一组区间。那么是否存在 「判断(判断即计算,因为必然存在算数过程)给定输入是否符合已定义的标准」 的功能?如果有,是你负责的部分要进行这个判断,还是你只是在做数据持久化的中间件,你只关心数据的序列化形式不关心它的解析?向量维度的意思是,一个「标准」是否固定地只有上下界两个参数,还是有一个复杂的关联,包含了一系列数字区间?

如果一个条目里(或者你打算设计的表,一行中)只存在唯一一个区间,那显然只需要两个代表上下界的数字和两个代表开闭区间的逻辑符号即可,简单地 4 个列就能完成需求。或者更学究一点可以用 mask 数字来代表逻辑符号。

但如果「标准」这个条目和「区间数量」的关系是不确定的,一个条目中能关联任意多个不同区间,那显然不可能只用一张表实现。视乎具体需求的复杂度,可能需要

- 表 A ,保存「标准」的 id
- 表 B ,保存定义「标准」时可用的项目枚举,如「层高」=1 、「面积」=2
- 表 C ,保存「标准」包含的条目关系,如 [标准 id,项目枚举 id, 逻辑符号, 数字],[1,1,>,2.5],[1,1,<=,4],[1,2,>,10]

上述例子就表示 id=1 的「标准」包含 ( 2.5<层高<=4 且 面积>10 )两组区间

当然了,如果系统中不存在判断「是否符合标准 1 」的场景,那上述这些设计并不是必要的,甚至于假如处理数据的主体并不直接与数据库交互,它接收的是某种中间表示,那完全可以直接把它的结构化表示作为字符串存进数据库里,如 json {id:1, name:"标准 1", rules:[{"层高":[">2.5","<=4"]},{"面积":[">10"]}]}


--------

第二个要考虑的问题: 你真的是想「保存单选类型的数据」?

单说这个抽象后的问题「如何把 options 存进数据库」,那任何但凡有程序思维(他不用会写)的人都能想到用枚举表示 options ,然后把枚举值存起来即可,最多再额外存一下枚举值和字面表示的对应(如果不在代码里写死的话)。如果你遇到的是类似「如何保存非预定义(可任意新建和自定义)的枚举」的问题。那么这个答案是「字典表」。如果不是,那么你的第二条说明就不仅没能概括问题,还表述了完全错误的方向


还有第三个问题: 为什么要把区间和 option 枚举两个看不出逻辑关系的东西,糅合进同一个表里?在你的问题里并没有体现仅用一个表来同时完成两个需求的必要性。如果有,那能不能解释一下这个表的 primary key 是什么? 为什么上述两个「配置」都会与这个 key 唯一对应?


p.s.题外话,突然发现软件工程那些没人在意的 UML 建模什么的,或许还真的对某些特定场景有帮助,比如当你想不出业务里的对象关系时
> 你们道听途说的“富人”氪金玩家确实存在,但远撑不起游戏自然运营和预期的利润

嗯……不知道 OP 自己玩游戏充不充钱。 你要是也充过三五万的,那些「道听途说」玩家就不是传说,他们会真实地沉淀在你的好友列表(「交易」分组)里。

除开那些每次充 6 位数的挥金如土的非常人玩家,大多数一个游戏里总投入不到 6 位数的都是些普通人,这其中有大学生,有程序员,有捧着铁饭碗事业单位的,有寺庙里打杂吃贡品的,有干医药研发的。 我这句话列的每一个人包括了自己都在同一个公会群里,大家同一个游戏逐渐退坑后反正群也没解散,每天聊些有的没的。这里的每个人同一个游戏投入额度都在 1w 到 5w 左右,游戏时长平均在 3 年。

再强调一次,普通玩家,年均投入一万。
只要全服有一千个这样的普通玩家,就能支撑得起年研发资金几百万的数量级。
而一千个人,用来给排行榜玩家陪跑辅助的人数都远不止这么点
2023-05-01 21:20:05 +08:00
回复了 yagamil 创建的主题 程序员 为啥 js 语言里面 那么喜欢嵌套,匿名
感觉楼上都没说到点子上。

「喜欢用匿名函数」的原因是,你正在使用的 function 要求传入一个 transformer , 由于这个 transformer 往往是定域的局部逻辑,因此基本上不会复用。不会复用,也就不用非得为它赋予一个公共名字,不需要命名自然就不命名了。

然后,为什么 js 写的代码更容易见到「传入 transformer 」这样的约定,本质上是因为前端的代码究其根本就是一系列状态转换函数。我们可以把 fetch 后端数据到渲染成 html 这个流程抽象为有一个 函数 F ,对后端传来的 json O 应用 F() 得到我们想要的 html:document = F(O) = "<html>...</html>"

这时候应该就很容易理解这与函数式编程的理念和思维方法不谋而合,我们逐渐把 F 细分,F(O) = Apply(O, Render1, Render2, ...) = Apply(O, (o)=>{renderComponent1(o.part1),renderComponent2(o.part2)},Render2, ...) ,然后把其中的某个部分,比如 renderComponent1 挖空逻辑变为接口,它自然就要求实现者实现具体的逻辑了:

type O = {part1:any}

function renderComponent1(o:O,impl:(o:O)=>HTMLElement) { // 要求传入一个把 O 转换为 DOM 的函数
document.appendChild(impl(o))
}

//你实际要写的
export function impl(o:O):HTMLElement{
const e = new HTMLDivElement()
e.innerText = o.part1
return e
// return ( <div>{o.part1}</div> )
}

这时候应该可以理解为什么传递函数作为参数是必要且常见的写法了。

不过这时候还有另一个问题,为什么非得是匿名函数不能是 function
—— 一句话来说,只有匿名函数(箭头函数)才可以完美 capture 上下文,这与 js 的语言债有关,作为半吊子就不展开了,可以自行翻阅关于 this 的前端八股文。
2023-04-24 19:43:30 +08:00
回复了 zangzang 创建的主题 问与答 你们相信玄学吗
@stillsilly

结论是






N+1 维引力物理可以用 N 维的非引力物理来计算。






就类似于 2D 全息能保存 3D 物体投影信息一样,所以这个理论叫全息理论,与什么决定论半毛钱关系都没有。

这个理论的主要作用是为处理引力量子效应提供思路,但目前的理论模型都尚不能计算真实世界的物理,只发现了非真实宇宙的,其它维度上的时空发生的物理效应确实可以用这个对偶 /等效关系互相转换。



全息这个词与「全悉」过于类似,容易被神棍曲解为「完全信息」,实际上对应的英文词根 holo- 指代的东西仅限于那种裸眼看起来像立体的幻象图,甚至这个词根本身就有幻境的语义在。与中文神棍相去甚远。










你和其它神棍犯的错误是通用的:物理其实只是机械的实验和数学问题,未解之谜=算不出来,重大发现=发明了微积分,与可供人幻想的哲学体系其实水火不容
2023-04-24 01:01:10 +08:00
回复了 zangzang 创建的主题 问与答 你们相信玄学吗
@stillsilly 看不懂就对了,我想说的就是,不懂装懂瞎扯一气
2023-04-23 21:41:22 +08:00
回复了 zangzang 创建的主题 问与答 你们相信玄学吗
2023-04-18 18:19:31 +08:00
回复了 milukun 创建的主题 程序员 小调查:各位每天的实际代码工作时间有多长?
hr 看到这帖乐死了
1 ... 14  15  16  17  18  19  20  21  22  23 ... 140  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2829 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 45ms · UTC 08:26 · PVG 16:26 · LAX 01:26 · JFK 04:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.