V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  FrankHB  ›  全部回复第 87 页 / 共 92 页
回复总数  1830
1 ... 79  80  81  82  83  84  85  86  87  88 ... 92  
2016-06-19 09:19:00 +08:00
回复了 hunk 创建的主题 程序员 做一个 win 平台下桌面应用,大家说说是用 QT 还是 vs C++?
@21grams Java 桌面的话, AWT/Swing/SWT ?(先不说部署问题估计不会合 LZ 胃口了。)
大致上 Swing 和 WPF 是一类、 SWT 和 Qt 这样的是一类、剩下的 AWT 和 MFC 和 wx 是一类奇葩。老调重弹没有新意。
也就 Swing 架构还算规整造轮子能(找 Sun 的白皮书)抄,然而不管是效果还是性能或者是实现质量普遍惨不忍睹。剩下的不是 Java 厨估计无法忍受……
2016-06-19 08:52:51 +08:00
回复了 hunk 创建的主题 程序员 做一个 win 平台下桌面应用,大家说说是用 QT 还是 vs C++?
@hunk 不管是要练手还是开发实用 app ,耗不起资源的话,我的忠告:远离 C++、远离 Win32 、远离桌面 GUI 。
掐指一算,我撸 C 艹 GUI 好像有 7 年啦……虽然就 GUI 而论是三天打渔两天晒网的,前 3 年和 Win32 其实也没什么关系,最近几年可是有一大半浪费在 Win32 这坨辣鸡上了。(虽然讲道理, Android 和 X11 更辣鸡……)
https://github.com/FrankHB/YSLib
就这么个轮子敲捣你给出的需求还得费些劲。
2016-06-19 08:31:09 +08:00
回复了 hunk 创建的主题 程序员 做一个 win 平台下桌面应用,大家说说是用 QT 还是 vs C++?
从 0 开始? Win32 那坨不用倒腾了,基本上只配被封装的料。自己造轮子撸个十年八年的顺眼了再说。
虽然 Qt 一坨私货金玉其外败絮其中,然而矮子里挑将军倒是没什么疑义……眼前勉强算是个“能用”的。不过要是在乎部署,一不小心和.NET 半斤八两。 PyQt 的话,搞不好从 0 开始的工作量翻两倍。
MFC ? wx ?不是拿来给现有项目擦屁股还不如直接 Win32 呢……
2016-06-17 13:10:32 +08:00
回复了 murmur 创建的主题 程序员 大家都是互联网公司的,那么我来分享下企业开发中的黑暗吧
@BSD ——“不是你买的闭嘴。”
不过说实话,其实和程序员也没太大关系……
就是作为最终用户买的也该自裁,很多市场就是被这坨逗比代婊了主流配置而搞烂的。合着真正搞对需求的用户计算成本的时候反而还得迁就这种惯坏逗比用户的行情花冤枉钱才叫正义了?
2016-06-12 12:09:59 +08:00
回复了 herogui 创建的主题 程序员 与野生程序员一起撸代码是一种什么体验?
@dphdjy Worse Is Better 不是一群图样应付 YY 出来的需求的么。
都 it is slightly better to be simple than correct 了嘛。
这看来不能算是学院式,但要笼统说成面向需求,脸皮也太厚了点。
所以是啥。
2016-06-11 05:40:11 +08:00
回复了 hongfeiyu 创建的主题 程序员 windows 下最好的命令行方案是什么?
……最好?要说贴近需求,当然是自己实现。
现在就 ConEmu+MSYS2 凑数。主要是 pacman 简单暴力而且 MinGW 原生包够多日常打 Cygwin 不成问题……虽然迟早都得重新倒腾(反正对 conhost/pty 互操作没兴趣,不是难点)。
Win10 的那个山寨笨兔现在相比之下就是玩具阶段所以一般人就不用浪费时间了。
2016-06-11 05:24:39 +08:00
回复了 SaintSeiya 创建的主题 程序员 科班出身的程序员,水平到底如何?
看人。
然后得看问题领域。比如说倒腾 C ,一时不会也通常不是什么大问题,反正九成九都挺渣的……很多基础科目教育质量包括教师和参考资料的水平就满是槽点,这样下来还真不见得就打得过培训班。
想象不清楚的话出来几年就习惯了。
2016-06-11 05:17:35 +08:00
回复了 zby0826 创建的主题 C 请教一个 c++问题, auto 定义多个对象时的指针类型推演
什么 base type ……现在的“入门”书已经没节操在这里生造概念了吗……难怪某糖看不起“底火”……
有点正确的基础的话真的就是一句话的事情……
WG21/N4594
7.1.6.4 auto specifier [dcl.spec.auto]
1 The auto and decltype(auto) type-specifiers are used to designate a placeholder type that will be replaced
later by deduction from an initializer. ...
(当然怎么 deduce 就要倒腾 Clause 14 了,没问题就可喜可贺。)
2015-12-20 14:44:08 +08:00
回复了 luohaha 创建的主题 Linux 关于 c 语言结构体的命名问题
因为基本上_t 都是文件作用域外部名称,所以你临时性地在块内 typedef 一下_t 的用法是不受限制的。不过排除了最有用的用法,似乎也没多大卵用就是了……
@halibut735 _t 约定俗成也就是 type 的意思。
不过最近似乎有越用越集中的趋势,像 ISO C++ 14 已经到处后缀_t 表示 typename *::type 了……甚至还有直接当 alias template 的: https://github.com/ericniebler/range-v3/blob/4ae2b5bd7b36ce2281f34abb40dab0e88f81e519/include/meta/meta.hpp#L147
2015-12-20 14:37:54 +08:00
回复了 luohaha 创建的主题 Linux 关于 c 语言结构体的命名问题
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html
包含任意 POSIX 头(文件)的翻译单元的文件作用域内保留_t 后缀作为外部链接的标识符(给 POSIX 标准或实现),所以你要 strict conforming to POSIX 自然不能随便用,否则一旦实现提供了扩展或者更新了使用的 POSIX 版本就可能冲突,慢慢重构去吧……
但如果你的项目本身就是在实现 POSIX 或者 ISO C ,自行添加扩展当然是允许的(兼容性问题自负),如:
https://www.cygwin.com/ml/cygwin/2009-08/msg00376.html
ISO C 没有保留后缀只是提供了一些_t 的名称,所以不管 POSIX 就无所谓。
题外话, C++的成员因为类和非全局命名空间都有单独的作用域而不是 C 那种名称空间(name space) 来区分,所以不受类似的限制,只是全局命名空间以及 ISO C 的保留标识符限制仍然类似;除此以外不踩到宏的坑就能无视。
2015-12-20 13:42:14 +08:00
回复了 tracyone 创建的主题 生活 “玩物丧志”是否可取?
“好好读书”?如果是口癖也罢,否则一句 you can you up 八成能打回原形了。说这种话的出发点一般也就是“不理解”和“看不惯”罢了,未必就有个听者有心的预期,往往更像是牢骚;另一方面,功利点地说,没有进一步具体意见,就是拿没有卵用的空话浪费时间。因此真会“读书”的先辈,若目的是善意的,通常不会幼稚到这般点到为止。
至于被念的……分类讨论。
玩到对什么是玩什么不是玩都没发言权的,活该被玩。
也有不懂瞎 bb 成瘾的,还有脸自居父母或者长辈倚老卖老的。平日里谁惯坏的?上梁不正下梁歪,多少也是活该。
反过来,要是连要解决的问题是什么都不知道,连什么是工具都分不清楚,被抽脸又能怪谁?
2015-06-19 20:22:46 +08:00
回复了 silianbo 创建的主题 程序员 为什么 要这样说:人生苦短,我用 Python
@ryanking8215
你至少搞错了两点。
1.你楼上讨论的除了一个在黑python的的都是动态类型语言和静态类型语言,什么时候在说动态语言和静态语言了?两者完全不是一回事,前者是指类型检查发生的时机,后者是指是否在运行时允许改变程序自身的构造。(顺便,上面那个动态语言的说法没有问题。)
2.强类型和弱类型这样的说法的意义早就乱了,各种鸡同鸭讲所以不能指望在不确定具体上下文时知道意思。非得要直接给一个定义来强行说清楚反而是有问题的。
如果要说原意,强类型=要求类型检查,弱类型=不要求类型检查,就是“有”和“没有”的区别,不是现在许多人经常以为的只有相对含义却说不清界限的玩意儿。
2015-06-17 00:10:59 +08:00
回复了 jjtx 创建的主题 C C++模板会不会增加冗余
@YuJianrong 简而言之同一个翻译单元内违反ODR一般就是编译错误,然而不同翻译单元之间的不匹配并不要求检查(no diagnostics required),所以可能链接出错也可能啥事没有但是就错的(ill-formed),不能指望什么有合理的结果,于是炸了也活该——这部分相当于C的undefined behavior的一个子集(事实上ISO C也就直接明确类似的违反就是UB了)。于是实际上没法保证是否有这些情况,虽然我用过的靠谱的工具链一般是链接错误。
1 ... 79  80  81  82  83  84  85  86  87  88 ... 92  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   6221 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 54ms · UTC 02:33 · PVG 10:33 · LAX 19:33 · JFK 22:33
Developed with CodeLauncher
♥ Do have faith in what you're doing.