【牛客CM11】链表分割

【牛客CM11】链表分割

刷爆LeetCode系列

牛客CM11:

github地址

有梦想的电信狗

前言

本文用C++实现牛客CM11


题目描述

题目链接https://www.nowcoder.com/practice/0e27e0b064de4eacac178676ef9c9d70?tpId=8&&tqId=11004&rp=2&ru=/activity/oj&qru=/ta/cracking-the-coding-interview/question-ranking

在这里插入图片描述

题目与思路分析

目标分析

  1. 编写代码,给定链表的头指针pHead以给定值x为基准,将链表分割成两部分,所有小于x的结点排在大于或等于x的结点之前
  2. 不能改变原来数据的顺序
  3. 返回分割后的新链表的头指针
  4. 要求:时间复杂度为O(n),空间复杂度为O(1)

思路:创建两个哨兵位的头结点guardLessguardGreater,遍历链表,小于 x 的结点尾插guardLess,大于 x 的结点尾插guardGreater,最终再将两个链表连接起来,尾插的时候注意记录tail结点

操作

  • 空链表检查if (pHead == nullptr) return nullptr;
  • 创建两个哨兵位的头结点
ListNode* guardLess =newListNode(-1); ListNode* guardGreater =newListNode(-1);
  • 分别创建两个链表的尾结点,方便尾插时无需频繁找尾
ListNode* lessTail = guardLess,*greaterTail = guardGreater 
  • curNode为移动指针,用于遍历链表
    • 小于 x 的结点尾插到 guardLess 链表中,同时尾指针 lessTail 向后移动
    • 大于等于 x 的结点尾插到 guardGreater 链表中,同时尾指针 greaterTail 向后移动
    • 每次循环中curNode指针向后移动curNode = curNode->next
  • 连接两个新链表lessTail->next = guardGreater->next
  • 最后一个结点的 next 指针需要置空,防止链表带环greaterTail->next = nullptr
  • 保存新链表的头结点pHead = guardLess->next
  • 释放手动开辟的哨兵位头结点
  • 最终返回新链表的头结点return pHead
delete guardGreater;delete guardLess;
在这里插入图片描述

代码实现

classPartition{public: ListNode*partition(ListNode* pHead,int x){if(pHead ==nullptr)returnnullptr; ListNode* guardLess =newListNode(-1); ListNode* guardGreater =newListNode(-1); ListNode* lessTail = guardLess,*greaterTail = guardGreater; ListNode* curNode = pHead;while(curNode){if(curNode->val < x){ lessTail->next = curNode; lessTail = lessTail->next;}else{ greaterTail->next = curNode; greaterTail = greaterTail->next;} curNode = curNode->next;}// 链接两个链表 lessTail->next = guardGreater->next;// 最后一个结点的 next 指针需要置空,防止链表带环 greaterTail->next =nullptr;// 释放哨兵位的头结点 pHead = guardLess->next;delete guardGreater;delete guardLess;return pHead;}};

算法代码优化

  • 以上代码和思路已足够精简,无需优化

以上就是本文的所有内容了,如果觉得文章对你有帮助,欢迎 点赞⭐收藏 支持!如有疑问或建议,请在评论区留言交流,我们一起进步

分享到此结束啦
一键三连,好运连连!
你的每一次互动,都是对作者最大的鼓励!征程尚未结束,让我们在广阔的世界里继续前行! 🚀

Read more

Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案

Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 meeting_place_core 的适配 鸿蒙Harmony 实战 - 驾驭分布式会议引擎、实现鸿蒙端高性能协作空间与复杂信令分发方案 前言 在后疫情时代的协同办公浪潮中,视频会议已经从单一的垂直应用演变为鸿蒙(OpenHarmony)生态中“泛在协作”的核心基础设施。当你在鸿蒙平板上开启一场跨国技术评审,或者在鸿蒙车机上紧急连线公司晨会时,支撑这一切流畅运行的,是底层极其复杂的会议核心引擎。 meeting_place_core 是一套工业级的、专为多端同步设计的会议核心抽象包。它不负责 UI 渲染,而是专注于房间管理(Room Management)、成员状态流转、信令推送及媒体流的逻辑编排。 适配到鸿蒙平台后,结合鸿蒙强大的分布式能力,meeting_place_core 能让你的 App 轻松实现“手机开会,大屏投映,

By Ne0inhk
从海量时序数据到无人值守:数据库在新能源集控系统中的架构实践

从海量时序数据到无人值守:数据库在新能源集控系统中的架构实践

文章目录 * 引言 * 关于金仓数据库 * 金仓数据库在新能源行业的技术解读 * 1. 应对海量时序数据:分区存储与高效查询 * 2. 支撑高并发访问:读写分离与自治调优 * 3. 保障业务连续性:跨地域高可用与容灾 * 4. 实现平滑迁移:高度兼容与自动化工具 * 案例分析:金仓数据库赋能新能源智慧运维 * 案例一:中广核新能源生产运维系统——应对“整合、高并发、高可用”三大挑战 * 案例二:国家能源集团龙源电力——186个新能源场站集控系统国产化替代 * 案例三:国家电投集团甘肃新能源——“无人值守”风电场集控系统 * 结语 引言 谈到“双碳”与能源革命,风电,光伏这些新能源产业显然是当下最为炙手可热的风口,若想在该赛道跑得更远,更快,数字化和智能化转型并非可选,而是必备功课,要知道,从远程操控成千上万台风电机组,到及时分析大量的设备数据,直至把整个生产运维流程管理得井井有条,哪一步能离开稳定,高效且安全的数据“大后方”

By Ne0inhk
Flutter 组件 tw_queue 的适配 鸿蒙Harmony 实战 - 驾驭分布式高并发任务队列、实现鸿蒙端流式任务调度与生产级持久化断点续传方案

Flutter 组件 tw_queue 的适配 鸿蒙Harmony 实战 - 驾驭分布式高并发任务队列、实现鸿蒙端流式任务调度与生产级持久化断点续传方案

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 tw_queue 的适配 鸿蒙Harmony 实战 - 驾驭分布式高并发任务队列、实现鸿蒙端流式任务调度与生产级持久化断点续传方案 前言 在鸿蒙(OpenHarmony)生态的工业级应用或是大型协同办公软件中,我们时刻面临着“海量任务堆积”的挑战。例如:在 0307 批次的博文自动化生产线中,160 个文件、上百万字的博文生成、图片压缩以及云端同步任务,如果全部无脑地开启并发,会瞬间撑爆鸿蒙设备的内存句柄(OOM),同时也可能触发后端的限流封禁。 我们需要的是一个具备“理智”与“弹性”的交通管制系统。 tw_queue 是一套专为高性能、分布式任务调度设计的流水线工具。它不仅能控制并发数(Concurrency),更具备了任务持久化、失败自动重试、甚至是带权重的优先级调度能力。在鸿蒙适配实战中,tw_

By Ne0inhk
Flutter 组件 ubuntu_service 适配鸿蒙 HarmonyOS 实战:底层系统服务治理,构建鸿蒙 Linux 子系统与守护进程交互架构

Flutter 组件 ubuntu_service 适配鸿蒙 HarmonyOS 实战:底层系统服务治理,构建鸿蒙 Linux 子系统与守护进程交互架构

欢迎加入开源鸿蒙跨平台社区:https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 ubuntu_service 适配鸿蒙 HarmonyOS 实战:底层系统服务治理,构建鸿蒙 Linux 子系统与守护进程交互架构 前言 在鸿蒙(OpenHarmony)生态迈向工业互联、智能车载及深度客制化终端的背景下,如何实现 Flutter 应用对底层 Linux 服务(如 Systemd/DBus)的受控访问、在端侧治理长驻守护进程,已成为提升应用系统级集成能力的“技术门槛”。在鸿蒙设备这类强调内核级安全防护与微内核分布式调度的环境下,如果应用仅能实现表层 UI 的交互,而无法感知、重启或监控底层硬件驱动相关的后台服务,就无法在大屏中控、工业看板或服务器管理设备中胜任“控制塔”的角色。 我们需要一种能够穿透沙箱壁垒、支持 DBus 通信协议且具备高可靠服务状态感知能力的系统治理方案。 ubuntu_service 为

By Ne0inhk