在 win 下，批次档是 *.bat 在 unix like 下（含 mac)，变化就多了 从前在 win 下如果我有复杂的需求，会写一个 C++ 专案，编成 exe 执行 因为专案管理需求，自己写些执行档做管理，而不是卖给客户用的 也许 dos shell command 做得到，但 dos shell 实在也没很熟 如果写大了，debug 更是地狱；无法步进执行，要一直 log unix like 下，perl 常看人用，但 perl 我也不熟 工具当然以自己熟练的为主（不长进 ~^_^~) 碰到 java 倒很方便，从 C++ 带来的基础算好转移 而且在 eclipse 下可以跨 win & unix like,也能步进执行 所以我才积极希望能用命令列执行；也成功了 不过好像没看人这麽用，perl 仍是主流 而且 C 号称可携性佳，我只是没学一下 g++ compiler 也许无痛转移可以比 java 还容易？ 但没学之下，我就无法想像 C++ 怎麽在 unix 下步进执行 （抱歉，也许我该自己找答案；但 java 在命令列下执行我已花了好几天， 现在也凌晨了） 我其实真的是把 java 当 C++ 在写自己的工具程式 很方便的解决了一些问题 而且因为有 gc,这太方便，我也回不去了 ~^_^~ (C也许可以更低阶，更有效率；但工具程式只求正确，速度并不很要求） -- 睡前不该想你 会让你走入梦里 梦里轻声笑语 询问是否还要继续 那两年前未竟的嬉戏 我却不敢当真,怕又被你放弃 楼下奔来铁骑 电影中才有的场景 蜂火,警笛,还有搜索令 这一幕结束在变调里 你又再一次从我怀里被夺去 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 60.251.197.63 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/java/M.1411591353.A.3D6.html 听起来反而很神奇，像程式产生器的做法 但自我参考变化的程式，debug 是地狱啊.. C like 我学过 php,它也可以在命令列执行 不过问题在 debug 脚本 （嗯，我总是用词不精确；你这词才对，幸好大家看懂我的意思） 用脚本语言可以改一行马上跑，不用 build 但它没一个像 eclipse 的环境让我监看变数，写 log 很辛苦 一开始都会喜欢它不用 build 的便利 但愈写愈大後就受不了 尤其是大型专案的 make file 竟然还是 perl 写的 真是受不了 这个也很出名 －－－－－ 同事说'你熟什麽就用什麽'，很宽容 （反正他又不看我程式，他只要我做出来） 我想我的关键在'我无法靠 log 去 debug 太大的程式' 依据我的个性，当然脚本语言就都摆一边了 （还是哪个 script 又可以步进，又是 c like?) 我要做的也不全是脚本啦 有时也会有中介於 compiler 阶段的程式或资料要动态产生 反正前端资料同事给，我又要产生什麽给同事 比较通俗的说法好像叫 parser 所以都有一堆开档读写， scan, printf 等等 因此以前才用 c 写 exe 进来操作 ※ 编辑: HuangJC (60.251.197.63), 09/25/2014 12:03:29 有一次的任务是购买来的 source code （连 compiler 整套一起买） 程式超大，我们要替它做多语系，patch 一下贴牌变我们的产品 :P 程式大到没空看懂是一回事 但字串搜寻一下，大概就知道怎麽代换人家的程式了 翻译社当然不想看程式，他们会给的像这样 Eng:Love Cht:爱 Jap:(阿宅只懂亚美蝶，但这好像不是爱 XD） 总之啦，在进入购买来的 compile 前端之前 我要再 patch 一个 precomiler; 也许是很多余，但至少我不用去懂它 resource.txt <= 买来的 source code 中的翻译表，有某种格式，非常不适合阅读及整理 （多打个 tab or space 就会导致翻译错乱） translate.txt <= 翻译社给的翻译表，以换行当分格，还算好阅读 以上两个读进去，产生新的 resource.txt 严格依照其格式；以程式产生，不由人类阅读及整理 这种东西我当然写 exe 做啊 －－－－－－－－－ 最近的任务是：参考中文常用字文件，列举所有 unicode 中文常用字 5401 字，以 big5 来看算是区块连续，有两百多个区块 以 unicode 看并不连续 所以，以 forloop 去跑 big5, 再做 big5 => unicode 全转好後得到 5401 个 unicode, 再排序後输出 这次我用 java 做了，还不错 :) 其实也是我自找麻烦，因为我改用 mac 了 所以环境能换 mac 就换 当然装个虚拟机在里面灌 win7 & vc 来跑也可以 但我想想头皮发麻啊 所以在 mac 灌 java 我觉得比较直接 哪天我又回到 win 环境下，java 又可以直接用 哇，这就是它的优点啊，这才是人生～ （阿宅工程师自我满足） > bitlife: 算统计、转档类的资料批次性作业? 那Java确实是不错,jit > bitlife: 集中在热点回圈後效率也不差 这边不了解，请教一下 jit 就是我所谓的整合环境 debug 吗？ 然後又什麽集中热点回圈？ 刚才又跑了个 java 写的程式（android 开发 tool 中，画 9-patch 那个） 能画图，跨 win & mac 啧啧，并不是只有 stdio 这让我很混乱了，当初公司为什麽全力使用 VC+MFC 开发产品 敝公司是自有硬体的小周边商 不过硬体不稀奇，一向以软体在行销硬体（利用绑硬体的方式） 光软体会被破解，都赚不到 光硬体则竞争对手也有做，我们也没比较便宜 硬体出来後，也一直有客户问 linux driver 等等 照这样看，其实只要用 c 写 driver 然後应用程式用 java 写，可以很快取得相容性，各平台发行 这样不是比较好嘛 －－－－－－－－－－－－－－ 目前我们的架构是硬体出来後 会先出 Android app, 再出 iOS app (以前着力在 PC 端软体，现在着力在手机端软体） 虽然逻辑可以搬，domain knowledge 一样 但 UI 这一块是最不相容的 一个不好就是 Android 上写得出来，iOS 上写不出来 粉辛苦滴.. Java & Object C 都是泛C 一族，做起来颇有 porting 的感觉 不过底层嘛... 比如，我们想发送一则推文至脸书，Android 端写出来了， iOS 端又要重看... ※ 编辑: HuangJC (60.251.197.63), 09/25/2014 22:37:50 懂了，原来 JIT '广义' 来说，字面翻译可能是'即时'？ 所以我原本知道的是 VC 的 JIT debugger 它可以在 exe 独立执行遇到错误时，呼叫 IDE 进来 （要不然只有在 IDE 内执行才能 debug,也很辛苦） 这里的是 JAVA JIT Compiler, 指的是 JAVA 的最佳化技术 ※ 编辑: HuangJC (60.251.197.63), 09/26/2014 10:29:02