[我看着我的 ts 代码中的===陷入了深思，难道我写的不是 ts 吗？]

开共享泄露了怎么办

我也不会。

没我这离谱，我们这公网就只有 10m 的龟速，甲方仓库只能一台设备登一个人登录，都是用微信传输项目来协调开发进度。开发直接沟通也用微信，一开始还很抗拒，用了几个月也就不管了。

这个操作和 c++有啥必然关系吗

@jonty #4

我是不是可以这么理解，一名资深高学历的 c++开发者，可以是只会写代码，不会与代码无关的电脑知识？

如果是这样的话，那我就很好奇他们是咋做系统开发的了，毕竟资历也有 10~15 年了，这些都算是电脑的基本操作吧

@chouvel #3

你这个是实际情况只能这样。

我们的话是代码都在手上，没有保密要求，目前在配置环境的阶段，我看到的这个奇观

不会用某个工具是一件很正常的事吧

另外，大把的 C 开发者抗拒使用 Windows 系统，而是用某个 Linux 发行版做主系统

局域网共享会被被子网和防火墙影响，真不好用

@zogwosh #8
不过我们的情况是局域网是一个路由器，底下只有一个 192.168.1.0/24 ，整个公司就 10 来个设备


@listenerri #7
不过我面试的 c++好多都是在 win 上搞 qt 的，我才有这疑问

U 盘比设置 windows 文件共享然后访问方便多了，尤其现在 windows 11 菜单藏得反人类

@listenerri #7

不会某个工具我是可以理解的，但是没选用其他工具我就不是很懂，毕竟现在流行的 nas ，本质也是局域网 smb 分享。

不过按我的推理，他们开始接触电脑应该是从 win 开始，肯定经历过以前拨号上网的年代，那么以前在学校玩电脑肯定涉及局域网相关的游戏或者文件分享，要么就是 Windows 共享，要么就是 u 盘，然后我看他们项目的依赖有 30 多个 g ，如果是这样的大小的话，我肯定不会想到用 u 盘这个方案的，更何况还不一定有 u 盘在身上。

不过自从公司有 c++开发后，我对这块的开发流程和工具链都开了眼界了。毕竟我前端和 go 玩多了 hhhh 。

@dajj #10

神奇的就是我们局域网是千兆口的，他那个 u 盘才 30 多 m 一秒，复制进去要花时间，复制出来也要花时间。lol 我都能开两局了都

关键不是他用什么传输，而是他能否实现需求。

@aonshuy #13

当然不管什么办法都能实现需求。这里只是讨论如何用更合适的方法而已。

如果是我的话，我会选择打成 7z ，然后本地开一个 http 服务，然后对面机器 wget 即可，其次就是直接共享 D 盘，对面机器直接访问。

@wunonglin 是你们公司的 IT 太差了。稍微像样点的公司内网都会有个 NAS 来共享文档。难到你让每个人都在自己的电脑开个 SMB 共享然后给同事共享？而且其实 windows 上的 SMB 开起来一堆莫名其妙的权限问题。

@felixlong #15

小公司，没 IT ，共享文件的话入职到现在大家都从没有过这个需求，只是 c++的同事来了之后碰到的见闻。

文档之类的都是放在服务器的 gitlab ，文档用腾讯的。前端都是 pnpm i ，后端 go mod tidy ，没啥需要共享的东西

不要拿你知识衡量别人. 我是做逆向 驱动 C++的. 我也不会用共享. 有些人会有些人不会很正常. 但你要说会 C++ 不会相关系统 api.这个就是有问题的. 你那些涉及到网络设备路由什么的.这些都交给管理网络的人实现去了.

术业有专攻

优越感来的莫名其妙。

按照你的逻辑。

我用了快 10 年的 vscode ，依旧记不住选中多行的快捷键是啥。

不得被你在 V 站首页挂个半年。

不会用挺正常的，你就说程序员懂电脑配置正常吗，不知道 CPU 型号啥的，这种人大把存在。

不会用挺正常的，你就说程序员懂电脑配置正常吗，不知道 CPU 型号啥的，这种人大把存在。专业的人干专业的事就行了

@ibinary #17
这点对的。给了你个


@weixind #19
你很奇怪。我感觉你更优越。
经历过那个年代的话，分享文件的方式无非就是 qq 、局域网共享、u 盘，我疑惑的是就目前的场景下，可以有更好的方式而已。
毕竟他们为了这个东西，从中午搞到了下午，我下班了才发现他们代码还没跑起来。


@cnightmare #20
不懂配置的确实大有人在，其实这也是不良商家能存活下去的很大原因。

"我看着我的 ts 代码中的===陷入了深思，难道我写的不是 ts 吗？"啥意思？没理解 OP 的想法

@7gugu #23

hhhh ，下面 imgur 的配图没加出来。知乎的一个看到的一个笑话，意思是自己写的是啥都不知道

@elechi #25
居然还有人记得飞鸽传书 hhhh ，当年局域网就靠这个活了。
现在的话太古老了，跨平台也不太好，推荐这个：localsend ，v2 也有人分享过

可是用网络共享分享依赖也还是抽象

完了我也不会

@mcfog 可能 c++领域和其他不一样吧，这个我无法作出评价。

看了半天没搞明白这个跟 c++有关系，你是不是被 c++或者之前写 c++的人伤害过

u 盘 cv 最简单直接，在不清楚公司网络状况以及相关规定的时候，最靠谱。
其实没必要纠结，这么做的人可以是大佬，也可以是菜鸟。

@rahuahua #30
原因我没说明白我的问题。

补充下，是因为我面试的时候看到的 c++绝大多数都是 80 后，90 出头的，在这个行业内都比较资深的，所以我认为他们在很早的年代就接触了计算机，在那个年代网络不发达，传输文件其实都是很大的问题，所以当时的 u 盘、tf 卡都比较火，用这种方式来传输资料是较为通用的解决方案，那么在局域网的话，小学和大学，流行的基本上都是 win 自带的网络共享以及飞鸽传书这种方案，后面逐渐互联网发达，家宽进行降费提速，使小文件使用聊天工具发送的方案使用率逐步提升，占据了一个大头，另外一部分就是网盘的崛起。

好了，有了这些前提，那么那个年代过来的程序员应该都会接触过类似的文件传输方案，现在的场景是两个 c++的程序员在入职后，需要分享依赖 or 环境啥的（我也不清楚）我看到文件夹大小有 30 个 G ，那么在这个场景下，用了个普速的 u 盘进行 cv ，而不是用局域网传输的方案来传递文件，我很疑惑。

仅此。

@rainbowhu #31 是的，如何实现我管不着。但是占用了大量时间了，这是个迭代需求，环境搞那么久，开发时间不是被压缩了么。

搞了一下午，我感觉不是拿什么传输的问题，如果上一个人依赖没管理好我甚至觉得是正常现象。

打个比方啊，拿有包管理的 npm 打个比方吧，你再稍微想象一下 c++没有包管理,你要自己构建的依赖情况

```
npm install https://127.0.0.1:3021/user/json1.git # 7 years ago may build with vs2005 ，like maybe node-gyp dep python2
npm install https://127.0.0.1:3023/user/json2.git # 5 years ago may build with vs2012, like node-gyp dep python3

# where is the https://127.0.0.1:3021/user/json1?
# wait what the f**k with json1 and json2? vs2005? they still make you?


"scripts": {
"build": ...,
"pre-build" : "rsync D:/foo/bar/json E:/foo/bar/json3" # windows rsync, it's really cool! you made it mo**f**ker, but where is the f**king D:/foo/bar/json?

}
```
上面这些都是有依据可循的，在 vs 或者 qt 的配置里面你可能要在各个角落里面找到它们
或者会遇到 qmake ，cmake ，xmake ，vcpkg ，canon ，bazel 甚至混用的。。。

在这里再次感谢 npm ，pip ，nuget, cargo

@nevermoreluo #34

没错没错，所以我才很疑惑，第一次与 c++的同事进行开发。

再次庆幸有 npm 、maven 、go mod 、php composer 这些依赖管理方案 hhhhh 。