Loading [MathJax]/jax/output/CommonHTML/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >深入理解Tcl中的置换

深入理解Tcl中的置换

作者头像
Lauren的FPGA
发布于 2019-10-31 05:07:20
发布于 2019-10-31 05:07:20
1.6K0
举报
文章被收录于专栏:Lauren的FPGALauren的FPGA

Tcl语言中有三类置换:变量置换(点击这里复习:变量置换)、命令置换(点击这里复习:命令置换)和反斜杠置换(点击这里复习:反斜杠置换)。可以说“置换”是Tcl的灵魂,同时也是让初学者容易感到困惑的一个难点。很多初学者常会碰到这样的情形:不希望发生置换时却发生了或者希望发生置换时却没有发生,加之一些Tcl解释器调试功能欠佳,往往让初学者受挫,觉得自己的脚本发生了诡异的行为。实际上,Tcl的置换机制很简单,其行为也很容易预测,只需记住如下两条规则:

规则1:Tcl在解析一条命令时,只从左向右解析一次,进行一轮置换,每一个字符只会被扫描一次;

规则2:每一个字符只会发生一层置换,而不会对置换后的结果再进行一次扫描置换

看一个典型的例子,在这个例子中,变量x被赋值为10,变量a被赋值为字符x。之后,给变量b赋值$$a。根据上述规则,Tcl从左向右对命令”set b $$a”进行解析,扫描所有的字符,发现$$a时,执行变量置换,得到$x,同时只发生一层置换,不会对置换后的结果$x再进行扫描置换(否则$$a中最左侧也就是第一个$将被扫描两次,与规则1冲突,)。因此,最左侧的$并不会触发变量置换,最终变量b的值将会是$x,而不是10。

根据上述两个规则,理解如下脚本的执行结果。

从Tcl代码风格的角度看,应尽可能地将置换简单化,这意味着尽可能地将多层次嵌套的置换分解为更简单的层次置换,这可通过命令分解实现。同时避免在同一条命令中出现太多的置换,尤其避免出现太多复杂的不同类型的置换,这对代码维护十分不利。此外,值得考虑的方法是建立“过程”,将复杂的操作隔离开来,从而增强代码的可读性和可维护性。看这样一个例子,计算两个字符串的总长度,这里用到了三个命令:set、expr和stringlength。在计算str_len时,使用了变量置换和命令置换,同时出现了命令嵌套。

对比另一种写法,将嵌套拆分,代码的可读性便跃然纸上。

结论:

Tcl在解析一条命令时

-每个字符只会被扫描一次

-每个字符只会发生一层置换

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-05-10,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Lauren的FPGA 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
对DDD(领域驱动设计)分层架构的理解(适合新人)
目前团队大多数项目都是基于DDD分层架构开发的,而不是传统的MVC模式,这就让很多之前没有接触过DDD思想的同学在刚开始接触项目的时候有点懵。那么什么DDD?这种DDD项目结构和之前的有哪些不同,我该如何开发我的代码,开发不同职责的代码该放在哪里?下面就我的理解,说一说DDD的分层架构。
架构之家
2022/09/27
2.2K0
对DDD(领域驱动设计)分层架构的理解(适合新人)
优秀的代码都是如何分层的?
说起应用分层,大部分人都会认为这个不是很简单嘛 就controller,service, mapper三层。看起来简单,很多人其实并没有把他们职责划分开,在很多代码中,controller做的逻辑比service还多,service往往当成透传了,这其实是很多人开发代码都没有注意到的地方,反正功能也能用,至于放哪无所谓呗。这样往往造成后面代码无法复用,层级关系混乱,对后续代码的维护非常麻烦。
程序员小明
2019/10/10
3.8K0
优秀的代码都是如何分层的?
分层架构
最近连续做了两个新项目,借着新项目的机会,重新审视一下之前一些实践方法,进而寻求一下背后的理论支撑
码农戏码
2021/03/23
6570
由Spring应用的瑕疵谈谈DDD的概念与应用(一)
多数有经验的程序开发者都应该听说过DDD,并且尝试过将其应用在自己的项目中。不知你是否遇到过这样的场景:你创建了一个资源库(Repository),但一段时间之后发现这个资源库和传统的DAO越来越像了,你开始反思自己的实现方式是正确的吗?或者,你创建了一个聚合,然后发现这个聚合是如此的庞大,它为什么引用了如此多的对象,难道又是我做错了吗?
aoho求索
2019/03/07
9320
领域驱动设计,让程序员心中有码(四)
分层,一直以来是一个非常经典的软件工程学问题,提到分层,无论是资深或者新入门的开发者,或多或少都有自己的理解。
MavenTalker
2019/07/19
4460
领域驱动设计
本文对《领域驱动设计-软件复杂性应对之道》一书进行高度凝练,梳理了领域驱动设计的架构图、基本要素和重要概念。从细节入手,以小见大,你想知道的定义,这里都有。
kaiwest
2025/01/16
1290
电商微服务体系中分层设计和领域的划分
比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点,软件体系知识显得很“湿”,似乎人人都有自己的认识,但又很少有人能说完整。
用户4283147
2022/10/27
4920
电商微服务体系中分层设计和领域的划分
软件架构设计分层模型和构图思考
对于架构思维本身仍然是类似系统思维,结构化思维,编程思维等诸多思维模式的一个合集。由于架构的核心作用是在业务现实世界和抽象的IT实现之间建立起一道桥梁,因此架构思维最核心的就是要理解到业务驱动技术,技术为最终的业务服务。要真正通过架构设计来完成业务和技术,需求和实现,软件和硬件,静态和动态,成本和收益等多方面的平衡。
肉眼品世界
2021/03/26
2.2K0
人人都在跟风学微服务,却不知道DDD领域驱动设计?
最先介绍领域驱动设计(domain-driven design)的是在程序员 Eric Evans 2004年出版的《领域驱动设计:复杂软件核心复杂应对之道》书籍中,领域驱动设计是领域概念的扩展和应用,并且将它应用在软件开发中。它的目标是将软件相关部分连接到不断发展的模型中,以此更容易创建复杂的应用。
Lvshen
2022/05/05
4610
人人都在跟风学微服务,却不知道DDD领域驱动设计?
领域驱动模型(DDD)
2004年Eric Evans 发表《领域驱动设计——软件核心复杂性应对之道》(Domain-Driven Design –Tackling Complexity in the Heart of Software),简称Evans DDD,领域驱动设计思想进入软件开发者的视野。领域驱动设计分为两个阶段:
高广超
2018/12/12
3.9K0
电商系统中微服务体系中的分层设计和领域划分
看标题感觉这个东西很理论,比起“高并发、多线程”、“分布式CAP、一致性、Paxos”、“高可用SLA”等具体的干货技术点,软件体系知识显得很“湿”,似乎人人都有自己的认识,但又很少有人能说完整,有一点可以确定的是,如果你未来需要独立设计一个复杂的系统中台,并使之未来能快速应对各种需求变化的话,科学合理的领域划分和边界界定需要我们“处女座级”的坚持下去,这对防止人力失控、减少项目烂尾很有帮助。合理的界定了边界后,即便某个微服务很糟糕,也可以就输入输出以很少的人力投入进行重构,相反的就是牵一发而动全身,加上业务需求频繁而来,很容易烂尾或是达不到如期的效果。
架构之家
2022/07/12
5540
电商系统中微服务体系中的分层设计和领域划分
探秘微信业务优化:DDD从入门到实践
引言 | 本文作者从微信团队维护的带货类项目所遇卡点出发,尝试用领域驱动设计方法(简称DDD),保障在快节奏、多人协作的项目迭代中,维持系统的可维护性、可拓展性、高内聚低耦合和稳定性。作者首先剖解相关概念原理,之后代入亲身参与的微信团队实际项目、围绕DDD方法进行优化实操。 DDD 全称 Domain-Driven Design,中文叫领域驱动设计,是一套应对复杂软件系统分析和设计的面向对象建模方法论。它由Eric Evans于2003年提出,但一开始不愠不火。直到MartinFowler于2014年发表论
腾讯云开发者
2022/12/09
1.1K0
探秘微信业务优化:DDD从入门到实践
系统服务化构建-项目整体框架
本篇文章旨在讨论如何组织通用型项目代码结构,以PHP YII2框架为例做说明,设计思想与语言本身无关。
needrunning
2019/07/04
7260
系统服务化构建-项目整体框架
Go实战抢红包系统(三)-架构设计
DDD(Domain Driven Design,领域驱动设计)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型。在正确实现的情况下,我们通过DDD完成的设计恰恰就是软件的工作方式。
JavaEdge
2019/06/23
1.8K0
Go实战抢红包系统(三)-架构设计
DDD领域驱动设计实战-分层架构
整洁架构、CQRS、六边形架构等微服务架构都旨在“高内聚低耦合”。那DDD分层架构又如何?
JavaEdge
2021/01/22
1.9K0
DDD领域驱动设计实战-分层架构
单体分层应用架构剖析
Tech 导读 分层单体架构风格是分层思想在单体架构中的应用,其关注于技术视角的职责分层。同时,基于不同层变化速率的不同,在一定程度上控制变化在系统内的传播,有助于提升系统的稳定性。但这种技术视角而非业务视角的关注点隔离,导致了问题域与工程实现之间的Gap,这种割裂会导致系统认知复杂度的提升。
京东技术
2023/09/11
3930
单体分层应用架构剖析
DDD领域驱动设计如何进行工程化落地
前面几篇文章中,笔者给大家阐述了DDD领域驱动设计的三大过程,重点围绕如何通过战略设计与战术设计进行DDD领域模型分析以及沉淀,但是还没有涉及到工程层面的落地。所有的这些架构理论或者设计模式到最后都是为了让我们的代码结构更加清晰,扩展性以及维护性更强。从而开发出bug少稳定性更好的应用。因此本文重点介绍如何进行DDD工程化落地。
慕枫技术笔记
2023/03/20
6830
DDD领域驱动设计如何进行工程化落地
干货 | 后微服务时代,领域驱动设计在携程国际火车票的实践
Ma Ning,携程国际火车票后端开发工程师,关注系统架构、微服务、高可用等技术领域。
携程技术
2021/08/13
1K0
软件架构分层,你的项目处于什么阶段?
只要从事软件开发的工作,系统架构是必备知识。有朋友说可能会说,我只是一个搬砖的,怎么会接触到架构知识呢?其实,除了架构的设计者(也就是架构师),作为普通的开发者也是在时刻践行着系统架构的理论。毕竟,再好的架构,都需要码农去实施。只不过当你没有系统了解软件架构时,可能感知不到而已。
程序新视界
2021/12/07
3.8K0
软件架构分层,你的项目处于什么阶段?
领域驱动设计(DDD)靠谱么?
DDD(Domain Driven Design,领域驱动设计)作为一种软件开发方法,它可以帮助我们设计高质量的软件模型。在正确实现的情况下,我们通过DDD完成的设计恰恰就是软件的工作方式。
架构精进之路
2021/11/16
7370
领域驱动设计(DDD)靠谱么?
推荐阅读
相关推荐
对DDD(领域驱动设计)分层架构的理解(适合新人)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档