百科问答小站 logo
百科问答小站 font logo



为什么大多数的 C++ 的开源库都喜欢自己实现 string? 第1页

  

user avatar   skywind3000 网友的相关建议: 
      

C++不是号称不限制你的开发方式么,每个库想怎么搞就怎么搞,这明明就是 C++的优势,不知道你们抱怨个啥?哈哈

接着说 std::string 的性能问题,举个具体例子吧,之前接手过一个项目,别的部门同事自己撸的一套 DirectUI 系统,用 tinyxml 解析界面节点,项目简单的时候没啥,随着ui越来越复杂,数千个节点,每个xml节点若干属性,每个属性就是一个字符串,我记得好像有500+ KB的 xml要解析,而且这部分界面还没法延迟初始化,必须启动加载时做完,启动十分慢。profile下来,很多时间卡在 tinyxml上,整个过程接近 3秒,费时最前的操作卡在处理各种字符串的操作上。

把 tinyxml 换成其他 xml库 ?没那么容易,项目各处模块都在依赖 tinyxml的各种接口和类。一开始觉得内部的 TiXmlString 实现有问题,换成 std::string,vc 2012下时间从3秒增加到4秒,更不靠谱(vs2012应该已经有所谓SSO了),所以人家 tinyxml 这里用自己的 TiXmlString 肯定也是比较过的,不然干嘛不用 std::string 。

但问题总得解决,所以还得优化字符串实现:

1. 自己重新给 TiXmlString 实现了一套新的 SSO ,因为 xml里面很多小字符串,10个字节以内的占比很多,这部分用 TiXmlString 里面一块静态空间存储,随着capacity变化,超过限制长度的字符串才会开辟新的空间存储,这样避免了大量的内存分配,和碎片,总解析时间从3秒下降到 2秒。

2. 还是嫌慢,又把 tinyxml 继续改写,增加把文本 xml编译成二进制格式的功能,平时开发用xml,实际发布用二进制版本的 xml,免去整个文本解析过程,时间进一步从2秒缩短到 0.8 秒。

3. 还嫌不够快,接着改进二进制 xml文件结构,扫描整个 xml里面用到的所有字符串,统一做一个字符串常量表放在文件最前面,这样,二进制 xml文件里涉及到字符串的地方从缘来一段内存变成字符串表的一个索引 int,整个 TiXmlString 也变成对字符串常量表里某个索引的引用,这样彻底避免了字符串分配和维护操作,而且总内存变小了,比如 "type", "button", "label" "text" 等高频字符串只存储一遍,以前 1000个 "text" 字符串要解析1000遍,还要创建分配 1000次内存,有了常量表以后,所有的 "text" 都是一个引用,不需要1000便解析,更不需要1000次构造,时间从 0.8秒继续下降到 0.2秒。

运营常识,客户端项目,启动时间直接和用户流失率成正比,tinyxml字符串优化,前后把优化前的 3秒下降到优化后的 0.2秒,基本xml解析不再是一个瓶颈。

为什么不同的库要实现不同的字符串呢?从这个小例子可见一斑。

后来呢?嗯,后来有一天我不能忍了,我把整个项目的 gui系统弄成 Qt 的了,ui描述文件直接编译成代码,再也不用烦这些事情。

在结合看楼上高票说的 QString,可以感受下。

所以大家才会说:人在做,天在看,信 Qt,保平安。。。。。


user avatar   paintsnow 网友的相关建议: 
      

补充一点:ABI的需要。

其实ABI中最麻烦的就是传递sized-buffer,其他的都还好说。

如果你用STL中的容器来传,那么就要面临不同runtime的兼容性问题。


user avatar   ZgblKylin 网友的相关建议: 
      

std::string并没有实现字符串应该做的事,而仅仅只是用STL风格的容器类接口封装了一下char[]罢了,其他std::xxstring同理。
与其说它是个字符串,还不如说它是个处理二进制数据的buffer,基本等同于std::vector<char>
std::string连内部统一编码都做不到,根本没法拿来做文本处理,一直到c++11,在algorithm、regex、localization、chrono这么一大堆类库的支撑下,才勉强可堪一用
所以,凡是有文本处理需求的framework,都必须自己搞一个string类。
相反,题主所说的高性能场景下,std::string借助STL的支持,反而是很强力的,也许在极端需求下需要自己写,但大部分场景下足够使用,比起文本处理方面实在强太多了。所以我觉得std::string更像是一个buffer。

这里,我就用我见过的最强大的字符串类,Qt的QString做下对比吧:

  • 基础单元不是char,是QChar,储存的是utf-16字符。即,内部统一编码为unicode,再无编码之累。
  • 任何常用字符串输入,不管std::string、std::u16string、std::u32string、char*、wchar_t、char32_t、CFString、NSString等,都有对应的接口转换为QString,并且转换时需指定编码(可以用latin1、utf8或者local8bit,local8bit一般是系统本地编码,比如windows下的ansi)。
  • 编码转换方面,采用单一职责原则,通过专门的QTextCodec类进行。但有特例——Unicode和latin1之间的转换,是用asm/sse默认提供的。
  • 支持从QChar*的rawData指针构造字符串,此时不分配内部存储,而是直接使用rawData指针作为数据内容。QChar大小为16bit,所以可以直接从双字节字符串指针强转为QChar*。
  • QChar提供了海量的字符操作方法,如isDigit、isLower、isSpace、isMark、isPrint等。
  • 提供了split、left、right、mid、chop等等各种分割方法。
  • 提供了contains、find、indexOf等字符串搜索方法。
  • 提供toUpper、toLower、trimmed、simplified、repeat等格式化方法。
  • 由QString的方法切割、搜索等生成的字串,是由QStringRef构成的,共享原字符串的内存,在做出修改操作时才会实际拷贝过去。
  • QString的拷贝构造是隐式共享,通过引用计数共享同样的内部成员,在进行非const操作时才会触发深拷贝。因此可以放心的到处乱传,不用担心拷贝开销。
  • 同样支持容器类应有的正向/反向迭代器,以及reserve和squeeze(即shrink)。
  • 性能上么……可以下个Qt查看下QString的源码,注意要下Qt5的。源码里的私有函数,几乎全是用asm/sse写的。
  • 提供完美的格式化输出方式。不是sprintf这种落后的,无编译校验的写法,而是QString("%2 %1 %2 %3).arg(1).arg(3.14).arg("hello world")这样的,arg方法会依次替换%1到%99的对象,比如这里输出就是"3.14 1 3.14 hello world"。arg方法可以附带更多的参数,用来指定整数进制、位数、填充字符、浮点表示格式、浮点位数……
  • 提供QString tr(QString str)函数,和本地化框架对接,可以把输入的字符串翻译为当前语言的目标字符串。翻译来源为外部加载的翻译文件,若无对应则保留原始内容。
  • QString.arg()这种可以通过 %1 %2 到 %99 任意对替换参数排序的机制,也是Qt Linguist本地化框架的核心。在编写多语言版本的翻译文件时,可以任意替换关键字的顺序,从而完美满足不同语言的语法顺序。比如形为"%1 the %2"的英文字符串,在中文模式下翻译为"%2%1",于是同样是str.arg(name).arg(title),三个字符串拼接之后,在英文模式下是"Geralt the witcher",在中文模式下就是"狩魔猎人杰洛特“。
  • 提供QStringLiteral(str)宏,可以在编译期把代码里的常量字符串str直接构造为QString对象,于是运行时就不需要构造开销。
  • QString并没有使用sso,因为隐式共享内存占用更少,拷贝构造性能也更好。至于单对象,不产生拷贝构造时的性能么,就需要一波benchmark了。


至于说到处理二进制数据么……Qt有个比QString更底层的QByteArray类,和std::string效果相同:

  • 内部存储是char*。
  • 同样具有和std::string类似的简单的字符串操作接口。
  • 同时也有QString的各种丰富的分割、搜索、格式化接口。
  • 不限定编码,和QString互相转换时需指明编码。
  • 具有toHex/fromHex方法,可以把二进制数据转换为可视化的十六进制数,如""转换为"00"。
  • 具有PercentEncoding转换接口,将特殊字符转义为%形式,从而生成URI/URL风格的字符串。
  • 具有base64转换接口。
  • 提供qCompress/qUncompress全局函数,通过zlib算法对QByteArray进行压缩/解压。
  • 提供qCheckSum全局函数,用来计算CRC-16。
  • 同样提供类似QString的,迭代器、reserve、squeeze等容器类接口。
  • 同样具有fromRawData接口,通过char*源码直接构造QByteArray——和C API混合编程的神器,可以在不需要额外分配内存的情况下,直接把char*的字符串或者buffer封装为QByteArray,从而可以使用最灵活的高级封装来直接处理最底层的二进制数据,这方面也就C#的linq可以更胜一筹了。
  • 同样通过隐式共享降低参数传递开销。


对了,顺便说下辅助类QTextCodec和QLocale吧

  • QTextCodec提供字符串编码转换。
  • QLocale提供本地化功能,见下:
  • 提供目标区域的日期时间格式转换。
  • 提供目标区域的货币格式转换。
  • 提供目标区域的数字格式转换(比如每三位一个逗号)。
  • 提供度量衡转换。


以上各个类(QString、QByteArray、QLocale等),每个类的源文件也就三五个,全都包含在QtCore模块中。该模块的relase版dll只有4M,并且可以通过编译选项裁剪到1M级别。
而QtCore中的其他类,也都是如斯强大的,比如处理URI的QUrl,比如c++17才有的std::any(QVariant),比如IPC所用的QSharedMemory,比如说逐线程数据存储QThreadStorage,比如c++17才有的filesystem,比如支持全反射的元对象系统,比如比异步时间循环还高级的信号槽机制,比如xml流式处理,比如json处理(有人和rapidJson做过对比,大约为rapidjson耗时的1.4倍),比如定时器,比如DateTime……
QtCore.dll,4M大小,涵盖了c++11到17,除了network之外的所有东西,并且全都比标准库中的更加强大,就问你是不是物超所值?

好吧我偏题了。
总之,相比起来,std::string是什么渣渣?我还从没见过有比QString更强力的字符串类,尤其是加上QByteArray、QLocale这些相关类之后。
(动态语言,利用更高级的语言特性,可以比QString更顺手,但不会有太大差距,主要是类似linq的语法上的优势,在功能性上并没有差距,而QString的性能则远高于前者。只有正则上QString是弱项——或者说整个c++在正则上都是弱项,因为动态语言可以把正则JIT到机器码……)

附:
QJson vs RapidJson vs JSON.parse 该文章里处理的json文件只有5kb。如果是大文件,则还需要考虑双方使用的容器类的性能差异。在不专门特化allocator的情况下,Qt和STL的容器类基本不存在性能差距——论Qt容器与STL

追加:
Benchmark来啦——std::string/QString/QByteArray - 知乎专栏


user avatar   pansz 网友的相关建议: 
      

其实这原因主要有这些:

1,C++诞生于1979年,STL在1994年才进入C++标准库,两者相隔15年。早期的C++库都必须实现一个自己的string类,既然实现了,也就一直沿用下来了。这应该是最重要的原因。

2,C++标准库的string类的部分功能依赖STL自身的算法。而STL算法早期用起来也是非常不方便的,那时候也没有lambda。——所以开源库希望有一个比较纯粹的字符串类,能够不依赖任何其他模块就完整完成字符串功能的。

3,觉得C++标准库的string缺少自己需要的功能又难以扩展。必须直接改stl代码才好做,但这样就不如干脆自己重新做一个。又由于「破窗效应」的原理,既然已经有了那么多第三方字符串实现,自己额外重新实现一个也是一件平常的事情了。


user avatar   zhangyachen 网友的相关建议: 
      

首先这是Fed一月 memo

先说结论:

FOMC 维持利率在 0-0.25% 不变。且确定 3 月完全停止 QE,同时 3 月加息也是箭在弦上,基本会后声明皆符合市场预期,没有太多的意外。

Powell 记者会确实是偏一点点的小鹰派,但我也认为,Powell 的说法不至于拉升市场加息预期至 5次 、并拉升缩表预期至上半年,反而比较像是在强化加息 4 次之预期。

另外我个人觉得,一些中文媒体似乎误读了Powell 记者会的部分片段,下面 Allen 再进一步说明。


1. 3 月加息停止 QE 早已定价

本次会议 Fed 再次确认 3 月将准备第一次加息,并同时停止 QE。

Fed 也再次重申,货币政策是要支持美国经济达到充分就业、与通膨长期均值维持 2.0% 的两大目标。

这部分我想市场早已定价,这裡完全不会是问题,所以我们不讨论太多。


2.未来加息在每次会议都可能发生 (?)

Powell 的原文说法是:Won't Rule Out Hike Every Meeting.

但我有看到部分中文媒体写:不排除每次会议都加息的可能性。

上述我想或许是误读了 (还是其实是我自己误会中文的意思 ?)

我的理解是:Powell 是说加息在未来每场会议都可能发生,指的是“不会在特定月份才加息”,不是说每场都要加息。

Powell 说得很合理,经济本来就是动态的,加息本就不会侷限在什麽月份才启动,端看当时的经济状况而定。

我认为Powell 上述说法,并未延展今年加息预期至五次或更多,若有这种想法,那绝对是误读了。


3.更大规模的缩表?

Powell 在记者会上提到,Fed 需要更大规模的缩表,但请大家不要恐慌,因为我又觉得部份中文媒体过度解读了。

我认为Powell 说到的“更大规模缩表”,在思维上指的是:

因为当前 Fed 资产负债表高达 8.9 万美元,这是新冠疫情爆发之前的两倍大,显然在绝对规模上是非常巨大的。

而上一轮 2017-2019 年 Fed 缩减资产负债表,是自 4.4 万亿美元缩到 3.7 万亿美元停止,缩表的幅度大概是 15.9%,共缩减了约 7000 亿美元。

确实每次缩表的经济背景绝对是不一样的,所以幅度也绝对不会相同,但我们随便抓,假设本轮缩表将缩减 10% 资产负债表规模,那麽这也要降低 8900 亿美元,规模当然很大。

但我认为,不需要过度恐慌在“更大规模缩表”这几个字上。更重要的,我认为是“Fed 缩表的速率是多少?”

我相信缩表没问题,缩表太快才是问题,因为缩表速度若太快,将直接影响的会是美债殖利率升速、以及殖利率曲线的斜率。

这点Powell 也非常清楚,Powell 在记者会上也不断强调,联准会内部尚未具体讨论到一切缩表的进度,要等到 3 月再说。


4.缩表比较可能落在下半年

Powell 在记者会上说明,希望在加息至少一次之后,再来开会讨论缩表的事情,且委员会至少将讨论一次,才会做最终拍板。

更重要的,Powell 希望缩表的进程是有秩序的、是可被预见的过程。

从上述Powell 丢出的时间表看,我个人认为缩表将落在 2022 下半年,最快可能是 6 月份,因为在 3 月加息后,Fed 才会来讨论缩表。

我个人相信 Fed 现在内部早已在讨论缩表,但委员会显然尚未准备好来与市场沟通缩表的前瞻指引。

而缩表这麽大的事情,我个人认为 Fed 需要起次跟市场沟通 2 次,并把缩表规划说得非常清楚之后,才会开始进行,所以比较合理的缩表时间,估计将会落在下半年。


5.最大风险:高通膨

Powell 在记者会上,大概提到了 800 万次的“高通膨压力”,并认为目前美国通膨风险仍在上升阶段,但预计 2022 通膨还是会回落。

Powell 说明,目前美国通膨居高不下,主要仍是供应链所致,白话来说就是供需仍然失衡,且供给侧 (Supply Side) 改善的速度是低于预期。

Powell 强调,目前美国高通膨持续存在,而美国经济要的是长期扩张,所以若要长期扩张,物价势必需要保持稳定。

这边开始进入正题了,我认为这是本次会议的最重要核心,是让我体感上,觉得 Fed 鹰派的地方。我认为 Fed 承认自己落后给菲利浦曲线 (Behind the curve),简单而言,Fed 这次的加息速度大幅落后给通膨。

由于 Fed 在 2021 年对于通膨的误判,先前 Fed 在 2021 年认为通膨在年底就可望自然回落,但也就是因为这件事没有发生,反而通膨还更为严重,所以目前才有使用加息来追赶通膨的压力。但当前宏观环境看,通膨的压力是来自于缺工、供应链紧俏等问题,再加上拜登政府的大力推行财政刺激在那边推波助澜~

所以这一次的通膨是来自于实体经济上的供需失衡问题,并不是金融市场过度投机、企业超额投资等问题,我认为 Fed 在这次的通膨问题上,能做得空间非常有限。

这裡将产生一个不确定性的较大风险,就是 Fed 只能靠货币紧缩去压通膨预期,但实体经济的根本性通膨问题,还是没有获得解决。变成最终 Fed 只能再用更剧烈的紧缩政策,去引导通膨预期走低后,尝试来压低实际通膨率,所以这裡将让 Fed 的紧缩路径,存在著较大不确定性。

比较好的处理方式,应该是直接去解决实体经济上的缺工和供应链/例如我之前提到的塞港问题,让实际通膨率自己走低、而不是靠 Fed 挤压通膨预期之后去引导。

谁可以去把坐在白宫裡疑似患有阿兹海默的白髮老头一巴掌打醒...还我特~


结论:我个人认为 Fed 今年将加息四次,不至于加息五次,而加息四次之预期,相信市场应该已经定价;至于缩表,相信市场尚未定价,估计将落在 2022 下半年,最快可能是 6 月。

如果 Fed 今年加息五次,我会感到非常意外,因为这意味著 Fed 很可能在 2023 年底、2024 年初,就因为美国经济放缓太快而需要降息,Fed 这波操作就会变得非常韭。

最后说说股市的想法目前 Nasdaq 已经插水一段时日,抑制通胀是当务之急,而股市所谓修正才多久已出现V转。对通胀而言意义不大,修正数月才可能有帮助~所以我之前一直描述为“恐慌”。因此对白髮老头而言,怎麽做才有利于中期选举就很清晰了。

最好还是坚持认为市场或已定价加息四次之预期,但缩表预期则是尚未定价的观点。

配置上美股我倾向持有科技权值股,一些 Megacap 的估值我认为合理、前景确定性较高,而这样也可以让你的收益贴著 QQQ 走。

考虑到一堆成长股腰斩,我也愿意加仓接刀成长股,但建议佔据投资组合的比例,或许不要超过 15%,如果选股功力不错,这裡就会开始让你的收益拉开与 QQQ 之类的差距。

最后,我相信人人都会想在市场下跌的环境裡接刀,接刀不是不行,但若接刀失败,斩缆我建议速度要快,我个人不考虑价投的话一次斩缆的比例都是 50% 以上。


user avatar   wo-he-suan-nai-bu-tian-gai-85 网友的相关建议: 
      

首先这是Fed一月 memo

先说结论:

FOMC 维持利率在 0-0.25% 不变。且确定 3 月完全停止 QE,同时 3 月加息也是箭在弦上,基本会后声明皆符合市场预期,没有太多的意外。

Powell 记者会确实是偏一点点的小鹰派,但我也认为,Powell 的说法不至于拉升市场加息预期至 5次 、并拉升缩表预期至上半年,反而比较像是在强化加息 4 次之预期。

另外我个人觉得,一些中文媒体似乎误读了Powell 记者会的部分片段,下面 Allen 再进一步说明。


1. 3 月加息停止 QE 早已定价

本次会议 Fed 再次确认 3 月将准备第一次加息,并同时停止 QE。

Fed 也再次重申,货币政策是要支持美国经济达到充分就业、与通膨长期均值维持 2.0% 的两大目标。

这部分我想市场早已定价,这裡完全不会是问题,所以我们不讨论太多。


2.未来加息在每次会议都可能发生 (?)

Powell 的原文说法是:Won't Rule Out Hike Every Meeting.

但我有看到部分中文媒体写:不排除每次会议都加息的可能性。

上述我想或许是误读了 (还是其实是我自己误会中文的意思 ?)

我的理解是:Powell 是说加息在未来每场会议都可能发生,指的是“不会在特定月份才加息”,不是说每场都要加息。

Powell 说得很合理,经济本来就是动态的,加息本就不会侷限在什麽月份才启动,端看当时的经济状况而定。

我认为Powell 上述说法,并未延展今年加息预期至五次或更多,若有这种想法,那绝对是误读了。


3.更大规模的缩表?

Powell 在记者会上提到,Fed 需要更大规模的缩表,但请大家不要恐慌,因为我又觉得部份中文媒体过度解读了。

我认为Powell 说到的“更大规模缩表”,在思维上指的是:

因为当前 Fed 资产负债表高达 8.9 万美元,这是新冠疫情爆发之前的两倍大,显然在绝对规模上是非常巨大的。

而上一轮 2017-2019 年 Fed 缩减资产负债表,是自 4.4 万亿美元缩到 3.7 万亿美元停止,缩表的幅度大概是 15.9%,共缩减了约 7000 亿美元。

确实每次缩表的经济背景绝对是不一样的,所以幅度也绝对不会相同,但我们随便抓,假设本轮缩表将缩减 10% 资产负债表规模,那麽这也要降低 8900 亿美元,规模当然很大。

但我认为,不需要过度恐慌在“更大规模缩表”这几个字上。更重要的,我认为是“Fed 缩表的速率是多少?”

我相信缩表没问题,缩表太快才是问题,因为缩表速度若太快,将直接影响的会是美债殖利率升速、以及殖利率曲线的斜率。

这点Powell 也非常清楚,Powell 在记者会上也不断强调,联准会内部尚未具体讨论到一切缩表的进度,要等到 3 月再说。


4.缩表比较可能落在下半年

Powell 在记者会上说明,希望在加息至少一次之后,再来开会讨论缩表的事情,且委员会至少将讨论一次,才会做最终拍板。

更重要的,Powell 希望缩表的进程是有秩序的、是可被预见的过程。

从上述Powell 丢出的时间表看,我个人认为缩表将落在 2022 下半年,最快可能是 6 月份,因为在 3 月加息后,Fed 才会来讨论缩表。

我个人相信 Fed 现在内部早已在讨论缩表,但委员会显然尚未准备好来与市场沟通缩表的前瞻指引。

而缩表这麽大的事情,我个人认为 Fed 需要起次跟市场沟通 2 次,并把缩表规划说得非常清楚之后,才会开始进行,所以比较合理的缩表时间,估计将会落在下半年。


5.最大风险:高通膨

Powell 在记者会上,大概提到了 800 万次的“高通膨压力”,并认为目前美国通膨风险仍在上升阶段,但预计 2022 通膨还是会回落。

Powell 说明,目前美国通膨居高不下,主要仍是供应链所致,白话来说就是供需仍然失衡,且供给侧 (Supply Side) 改善的速度是低于预期。

Powell 强调,目前美国高通膨持续存在,而美国经济要的是长期扩张,所以若要长期扩张,物价势必需要保持稳定。

这边开始进入正题了,我认为这是本次会议的最重要核心,是让我体感上,觉得 Fed 鹰派的地方。我认为 Fed 承认自己落后给菲利浦曲线 (Behind the curve),简单而言,Fed 这次的加息速度大幅落后给通膨。

由于 Fed 在 2021 年对于通膨的误判,先前 Fed 在 2021 年认为通膨在年底就可望自然回落,但也就是因为这件事没有发生,反而通膨还更为严重,所以目前才有使用加息来追赶通膨的压力。但当前宏观环境看,通膨的压力是来自于缺工、供应链紧俏等问题,再加上拜登政府的大力推行财政刺激在那边推波助澜~

所以这一次的通膨是来自于实体经济上的供需失衡问题,并不是金融市场过度投机、企业超额投资等问题,我认为 Fed 在这次的通膨问题上,能做得空间非常有限。

这裡将产生一个不确定性的较大风险,就是 Fed 只能靠货币紧缩去压通膨预期,但实体经济的根本性通膨问题,还是没有获得解决。变成最终 Fed 只能再用更剧烈的紧缩政策,去引导通膨预期走低后,尝试来压低实际通膨率,所以这裡将让 Fed 的紧缩路径,存在著较大不确定性。

比较好的处理方式,应该是直接去解决实体经济上的缺工和供应链/例如我之前提到的塞港问题,让实际通膨率自己走低、而不是靠 Fed 挤压通膨预期之后去引导。

谁可以去把坐在白宫裡疑似患有阿兹海默的白髮老头一巴掌打醒...还我特~


结论:我个人认为 Fed 今年将加息四次,不至于加息五次,而加息四次之预期,相信市场应该已经定价;至于缩表,相信市场尚未定价,估计将落在 2022 下半年,最快可能是 6 月。

如果 Fed 今年加息五次,我会感到非常意外,因为这意味著 Fed 很可能在 2023 年底、2024 年初,就因为美国经济放缓太快而需要降息,Fed 这波操作就会变得非常韭。

最后说说股市的想法目前 Nasdaq 已经插水一段时日,抑制通胀是当务之急,而股市所谓修正才多久已出现V转。对通胀而言意义不大,修正数月才可能有帮助~所以我之前一直描述为“恐慌”。因此对白髮老头而言,怎麽做才有利于中期选举就很清晰了。

最好还是坚持认为市场或已定价加息四次之预期,但缩表预期则是尚未定价的观点。

配置上美股我倾向持有科技权值股,一些 Megacap 的估值我认为合理、前景确定性较高,而这样也可以让你的收益贴著 QQQ 走。

考虑到一堆成长股腰斩,我也愿意加仓接刀成长股,但建议佔据投资组合的比例,或许不要超过 15%,如果选股功力不错,这裡就会开始让你的收益拉开与 QQQ 之类的差距。

最后,我相信人人都会想在市场下跌的环境裡接刀,接刀不是不行,但若接刀失败,斩缆我建议速度要快,我个人不考虑价投的话一次斩缆的比例都是 50% 以上。




  

相关话题

  Qt QTime的toString是如何实现的? 
  为什么当年 Android 选择用 Java 作为开发语言? 
  为什么c++中要分为heap(堆)和stack(栈)? 
  游戏程序员必须要修 C# 吗?我徘徊在先开始 C++ 还是 C# ? 
  如何评价网易校招C++的笔试题? 
  某些团队规定c++语言不让写注释,你怎么看? 
  GitHub 上有哪些优秀的 Python 爬虫项目? 
  如何解决Linux下信号产生的死锁? 
  怎么看待 Linus 和 Richard Stallman 对 C++ 的态度? 
  Windows C++如何直接写分区表? 

前一个讨论
为什么美国灾难片主角们很多是离异家庭?
下一个讨论
如今 Windows 软件开发究竟该用什么库,C#、Qt,还是其他?





© 2024-11-21 - tinynew.org. All Rights Reserved.
© 2024-11-21 - tinynew.org. 保留所有权利