The aim of this post is to provide an insight into various aspects of the LLDB plugin, so that it is better understood, and can be used by more people. Should anyone want to improve it or add more features, he/she will also find useful technical details here.

In general, the LLDB plugin teaches KDevelop to talk to the standalone LLDB MI Driver (lldb-mi), so that it’s possible to use LLDB as an alternative debugger backend for KDevelop.

The rest of the post is orgainzed as follow

• Setting Up provides necessary information on how to get everything work from source code
• Features gives a detailed description of available features implemented in the LLDB plugin
• Roadmap lists some future works.

Setting Up

Custom Build of LLDB

First thing first, you need a working LLDB before you can use it inside KDevelop. For the LLDB MI Driver (lldb-mi), while it’s a standalone executable, its code is inside the LLDB repository and thus should come with a normal LLDB installation.

However, as the current release of LLDB MI Driver contains several bugs, you have to build LLDB from source, with patches applied. Please refer to Building LLDB for more detailed information on how to compile.

To apply patches, after checking out the source code, run

cd llvm/tools/lldb/tools/lldb-mipatch -i /path/to/patch.patch

Right now, only the patch for Bug 28026 is mandatory for stable reason, but there are patches fixing other minor problems available, too, please refer to Current Status of LLDB Plugin for KDevelopfor a complete list.

Build KDevelop From Source

While the LLDB plugin has been merged into the master branch in KDevelop repository, it is not included in any release yet, so you need to build KDevelop from source. You can find step-by-step guides on the community wiki. Also, if you don’t want to use kdesrc-build, be sure to refer to my post for how to avoid messing up with system installed KDevelop.

Features

This section gives a detailed introduction for important features.

Config Page

As already covered in my previous post, the LLDB plulgin provides the same configuration interface as the good old GDB one. When editing a Debug configuration, the combox at the top-right corner in the Edit Launch Configuration dialog lets you select either GDB or LLDB as backend.

While the defaults should work in most cases, the LLDB backend is configurable in many aspects. Options are grouped into three categories.

• Debugger: settings about where to find the debugger executable and how to launch it.
• Options: settings that control various behaviors during a debugging session.
• Remote Debugging: settings specific to remote debugging.

Breakpoints

Breakpoints is a must for any debugging tool to be useful. And the LLDB-powered debugging backend also provides good breakpoint support. Apart from setting breakpoints by clicking on the left side of the source file, the breakpoints tool view shows all breakpoints in the project as usual.

Framestack

Easily getting lost when debugging multi-threaded program? Framestack tool view comes to rescue. Navigating among threads and frames is as easy as clicking the corresponding item. A little difference from GDB is, low level functions like _start and __libc_start_main are also shown in the list.

Variables

The variables tool view shows local variables in the current frame, as well as values of manually set watches. Thanks to the newly written data formatter (equivalent to pretty printers in GDB), the LLDB backend understands common STL and Qt types, as well as a few KDE types. This means, std::string and QString are shown as string. Array-like types (various list/vector) and dictionary-like types (various map/set) are also shown in a human readable format.

By hovering mouse on a variable name in the source file, it’s value is revealed in a popup, correctly formatted. Clicking Watch this adds this variable as a manually set watch. Unfortunately, Stop on change doesn’t work yet, due to the lack of necessary commands in the LLDB MI Driver.

Debugger Console

The debugger console is totally reworked. The new ‘repeat’ mode can save you a few types if you want to resend the last command.

Remote Debugging

Remote debugging has also been redesigned and should be easier to use. The configuration is largely simplified. After specifying the address to the remote debugging server and a writable working directory, KDevelop will take care of uploading and starting the inferior.

Known limitations

However, there are a few limitations in this version.That post also has a comprehensive list of related bug reports in LLDB.

Roadmap

Other than finishing up missing functionalities in the LLDB plugin, the TODO list is as follow:

• Get bugs in lldb-mi fixed
• Global debug config for attach to process and examine core file

For a comprehensive technical TODO list, please refer to plugins/lldb/TODO.txt in the repository

2018.3.20:Now KDevPlatform repo is merged into the KDevelop repo, and there is no need to go through the steps mentioned in this post to get things working.However, the last section still applies in order to not load plugins from the system-wide KDevelop installation.

KDevelop is tightly coupled with KDevPlatform and from time to time you need to hack them both when developing. But then without caution, you’ll link against the system bundled KDevPlatform libraries and spend the whole day trying to find out why the hall the code you wrote didn’t have any effects.

That’s annoying and here’s how to make sure you are linking to the right copy.

Compile & Install KDevPlatform

Your awesome super hacked KDevPlatform need to be compiled and installed to somewhere first, say ~/stage. Don’t install it to any standard path like /usr or /usr/local just to avoid messing with the rest of the system. As a rule of thumb, if you need sudo privilege when doing make install, then you probably should consider somewhere else.

mkdir build && cd buildcmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=~/stage ..make install

This should give you bunch of files in ~/stage, like bin, include, lib64 and share, somewhat similar to your system root.

Compile & Install KDevelop

cmake makes life easier by its find_package mechanism that automatically find required libraries for you. But sometime you need more control over that.

What find_package actually does is to find a cmake file provided by the library you required that can configure itself. (read the doc if you are interested in the exact detailed procedure). In our case, the files are:

tree ~/stage/lib64/cmake/KDevPlatform~/stage/lib64/cmake/KDevPlatform├── KDevPlatformConfig.cmake├── KDevPlatformConfigVersion.cmake├── KDevPlatformMacros.cmake├── KDevPlatformTargets.cmake└── KDevPlatformTargets-debug.cmake

We just need a way to tell cmake where they are by appending that path to CMAKE_PREFIX_PATH when configuring KDevelop.

mkdir build && cd buildcmake -DCMAKE_PREFIX_PATH=~/stage/lib64/cmake \                         -DCMAKE_BUILD_TYPE=Debug \                         -DCMAKE_INSTALL_PREFIX=~/stage \                         ..make install

This way cmake will find your newly built KDevPlatform.

Hint: you can locally change KDevPlatform version to a higher number than the one in the system and modify KDevelop to require at least that number. Then you can be sure that you are building against the custom build of KDevPlatform.

Run Newly Built KDevelop

In order to run KDevelop built this way, you have to specify various paths so that system can load correct version of dynamic libraries and kdevelop itself can find its data in correct place.

env QT_PLUGIN_PATH=~/stage/lib64/plugins \                       LD_LIBRARY_PATH=~/stage/lib64 \                       XDG_DATA_DIRS=~/stage/share:$XDG_DATA_DIRS \                       ~/stage/bin/kdevelop

2017.1.6:Some of the bugs are fixed, see here

After several months’ working, LLDB plugin is now usable for basic debugging use cases. There are less than two weeks left, and it’s time to do a overall status update for the LLDB plugin.

Config Page

Using LLDB as the debugger backend is as easy as using the good old GDB debugger. Simply selecting LLDB in the combox at the top-right corner when editing the debug launch configuration should get things work in most normal cases.

Additionally, you can set Debugger Executable pointing to a specific version of LLDB. Note that this path should point to the lldb-mi executable, which is usually in the same folder as the normal lldb executable. Should you need any special configuration, Arguments and Environment let you fine tune the running environmnet of LLDB.

For common options, Config script lets you execute almost any command right after the debugger starts up. Break on start and Start debugger with (the same as GDB) options also come in handy.

The remote debugging part has been reworked and is largely simplified compared to the GDB one. You only need to start the remote debugging server (lldb-server gdbserver) and set hostname and port in the config page along with a writable folder on the remote machine. KDevelop will take care of uploading and starting your program.

Debugging

After started the debug session, you will be taken to the familiar KDevelop debug mode, with similar tool views available, backed by LLDB.

Variables and Framestack tool views should work as expected. In case you need to execute some complex command directly in LLDB, there’s the reworked Debugger Console.

!!! info “Tips”There’s a “repeat” mode in the Debugger Console. If you check the small button left to the command edit, you can press enter directly to repeat the last command.

Feature Implementation Status

Known Issues

• Debugger console
  • Debugger CLI stdout isn’t shown, due to Bug 28026
• Remote debugging
  • When using lldb-server gdbserver as remote server, server exits once debug session ended.
  • When using gdbserver as remote server
    • Remote work path can’t contain space
    • Can’t actually start inferior
• Variables view
  • Variables and expression won’t get updated when their values change, possibly due to lldb-mi doesn’t report them in the changelist result.
  • Variables may not be updated when jumping between frames and threads, due to Bug 28621
• Breakpoints
  • Pending breakpoints doesn’t work (Bug 28702, Bug 28703), as well as anything relies on it, i.e. ~break on start~ (break on start is fixed to work even without pending breakpoint support) .
    • Can still manually set pending breakpoints
  • Breakpoint hit count is not updated timely (Bug 28860)
  • No watchpoint support
    • Can still manually add watch point
• Changing working directory has no effect (Bug 30265)

Upstream Bugs

Actually most non-working issues are due to some kind of upstream bugs in lldb-mi. There’s a debugers/lldb/TODO.txt in the repo which contains more detailed description of current limitations and link to related LLDB bug reports. But here’s a quick list of opening bugs.

Some of these bugs already have patch available, so be sure to check out their bugzilla page.

• Bug 25000 - lldb-mi does not receive broadcasted notification from Core/Process about process stopped if StopAtEntry was requested (“process launch -s” OR “-exec-run --start”)
• Bug 28026 - LLDB-MI doesn’t properly output CLI command response using console-stream-output stream
• Bug 28621 - lldb-mi can’t get variables of a frame (-stack-list-* MI-commands) if the thread didn’t cause the stop event
• Bug 28698 - [lldb-mi] -break-insert with -f (pending flag) requires additional parameter
• Bug 28702 - LLDB-MI: pending break point set with command break-insert -f doesn’t get resolved
• Bug 28703 - LLDB-MI: break-insert command flag -d (disabled) has no effect when combined with -f (pending)
• Bug 28718 - LLDB-MI: disassembly-flavor not supported by gdb-set and gdb-show
• Bug 28857 - LLDB-MI: break-enable doesn’t enable specified breakpoints
• Bug 28858 - LLDB-MI: no notification about process stopped if attaching to a process
• Bug 28859 - LLDB-MI: data-disassemble command doesn’t accept “$pc” as start and end address parameter
• Bug 28860 - LLDB-MI: no breakpoint-modified notification when a breakpoint is hit
• Bug 30265 - LLDB-MI: environment-cd doesn’t change working directory for inferior

Code, and more code

Lots of code, that’s what GSoC means, at least in my opinion. That’s exactly something I love. From time to time, I just feel like writing some code, for a somewhat big project, for something useful.

So that I can dig into the large code base, figuring out the relationships among classes, and then learn about the differences between the current design and the one I would architect, were I making the decision. This is definitely something I’m eager to experience.

In addition, the version history itself would tell good stories. Tracking down one particular file and seeing it evolves over the years, you’ll be surprised to find out that the code isn’t static anymore and there’re others’ efforts behind the scene continuously improving it, especially when reading through commit logs.

That’s the amazing feeling GSoC gives me, plus the additional benefit to contribute to the open source community.

Community, and more communication

While I did submit a few patches to open source projects previously, I never deeply involved in any related communities, just floated around and feeling afraid of talking to others. With GSoC, one is forced to interact with the community and get more involved. The best part of this is that I don’t fear talking to the public anymore, and only then did I meet many nice people.

My mentor Aleix has been so patient and kindly reviewed my sometimes large RR. When my commit broke the master branch, René and Kevin helped me debug and fix the issue. Big thanks to all of you!

Only when you are actually participate in the workflow, could you begin to know how it’s different from what you have learnt from textbook. The way working with the community is really a valuable experience for my study and work.

The most challenging part of communicating with others is that, as a non-native English speaker, it takes time to be familiar with and accustomed to various conventions used in communication, like mailing list, IRC and review boards. And I have to double check every time to make sure I’m using appropriate words and being polite. However, this is also a great practice for me to learn English. After all, you can only learn a language by using it.

Test, with more coverage

Enough words about non technical things. I really had a hard time coming up this many words. Let’s talk about something technical.

Unit testing, this is what I’m doing for a week or so. The basic infrastructure for lldb plugin was finished a few weeks ago, and I’m in a stage fixing various failing parts due to lldb-mi not conforming to the specification. There are some commands not implemented, and some others incorrectly implemented. I have to find ways to workaround these before it’s in a good shape to have a UI, not too far away though.

There are about two months left as the second-half of summer. And it’s good to know I’m not running late too much behind my initial schedule XD. Will keep working anyway. Let’s enjoy the summer and coding!

Available communication methods

As mentioned in my proposal, there are mainly three ways to talk to LLDB in a debug session.

• Use GDB Machine Interface
  • LLDB-MI implementation which exists in LLDB source tree
  • LLDBMI2, which is a third party implementation that has a simpler and smaller code base
• Use C++ interface directly

Yes, I meant the GDB Machine Interface, and here’s a little background.

MI is a line-based machine-oriented text interface to a debugger. The Gnu GDB debugger offers a reference implementation of MI emission. The MI interface is quickly becoming a de facto standard for integrating debuggers into a variety of environments. (From Debugger Machine Interface Wiki)

Being said that, the design decision about how we talk to LLDB is critical that affects the stability, maintainability and extensibility of the KDevelop debugger support. Thus it deserves careful assessment about the advantages and disadvantages.

Advantages and disadvantages

Currently, KDevelop is using the MI to talk to GDB to provide debugging support in IDE. So using the same MI method talking to LLDB has the advantage of large percentage of code reusing.

On the other hand, Neither choices (LLDB-MI, LLDBMI2) is a comprehensive nor complete implementation, which might lead to difficulties if we must use something not yet implemented.

Linking directly to the C++ API avoids this problem completely, as it is the official API supported from the beginning. The drawback of direct linking is also non-negligible, however, as we can’t easily protect ourselves from debugger crashes. This can be a problem, because one reason we are debugging a program is to find why it crashes, and it’s not rare to see the debugee also turns the debugger into a unstable state.

The following table summarizes the pros and cons of each choices.

Let’s talk about each of these. For the C++ API, it’s the most promising one if we can somehow figure out how to do crash protection. The problem with that is, the most reliable way to protect ourselves is to move the library out-of-process. That is exactly what the Machine Interface does, and I don’t feel like reinventing the wheel.

The biggest issue with LLDB-MI is that only basic MI commands are implemented. However, the MI specification accepts arbitrary normal user commands to address this problem and fortunately LLDB-MI supports this feature. Except for the incomplete feature, LLDB-MI only supports remote debugging. For those not familiar with remote debugging,

Remote debugging refers to the act of debugging a process which is running on a different system, than the debugger itself. We shall refer to the system running the debugger as the local system, while the system running the debugged process will be the remote system. (From Remote debugging with LLDB)

While this sounds like a serious problem, it isn’t. Because LLDB on Linux and OSX uses the remote debugging stub even when debugging a process locally.The support for Windows is unclear though. And I don’t know whether it’s easy or not to launch a remote debugging session on Windows.

The actively developed LLDBMI2 is a third party implementation of the MI specification, while it seems promising, the hard limitation of only support OSX makes it not suitable for a cross-platform IDE like KDevelop.

Final decision

All these three methods talking to LLDB have their own pros and cons. However the LLDB-MI implementation seems providing most benefits while there are solutions to its short comes. Thus I’ll go with the LLDB-MI. As this blog is written, I already have a preliminary implementation of LLDB-MI parser, which shares a large portion of code with the existing GDB/MI parser. There are issues though, as the LLDB-MI doesn’t correctly output debugger output using stream. But I’m working on it and should be able to solve these later.

That all about it. I’ll keep you posted once I have something working and see you next time!

So I think it might be a good chance to also post this on the blog, which may probably keeps me writing more things and make the blog more… I mean, make it less like unmaintained XD

The big plan is, writing a series of articles as the project goes on and making them kind of status updates. Let see how far I can go though :P

Introduction

Enabling KDevelop to use LLDB as a debugging backend, which would be especially useful on Max OS X and Windows, where gdb support is rather scarce, and it can also help people that want to switch to lldb on linux (like me!) by adding decent IDE support.

Project Goals

LLDB support in similar feature-completeness as current GDB support. The user should be able to select what debugger to use intuitively on a per launch configuration base. The following function should be supported.

• Debug session management: begin, kill, restart
• Set breakpoints
  • breakpoint list
  • enable/disable breakpoints
  • conditional breakpoints
• Information inspection
  • Frame Stack: threads, call stack
  • Local variables
  • Symbol info when hovering mouse over the symbol
  • Disassembler
  • Register
• Debug commands: next, step, jump, run to the end of function, arbitrary lldb command
• Attach to a running process
• Examine core file
• Remote debug
• Drkonqi support

Implementation

The whole work can be broken down to three major parts.

• Communication with LLDB: Implement a wrapper class that hides all hassles communicating with LLDB and provide a consistent api that is agnostic to specific communication methods, be it inter-processes or direct library link.
• LLDB Specific Classes: Implementation of LLDB specific controllers and manager classes. This includes DebugSession and friends, *Controller classes and config page factories. This part is higher level than the first one, but still remains LLDB specific, thus must be implemented separately from GDB variants.
• UI and Other: Hook the UI with the LLDB backend built from the above two parts. This part has the potential to share a large amount of code with GDB. However, currently all UI widgets are bounded to GDB backend. Thus refactors on these classes are needed to split common code out.

Relation with current GDB Plugin

Right now the debugger code in kdevplatform only provides very basic facilities to build a debug plugin. Most heavey works are still done in GDBDebugger::CppDebuggerPlugin. An investigation into the code shows that there are planty part of code that is debugger backend agnostic, and could be reused by LLDB plugin.

The ideal/desired design would be extract all debugger backend agnostic into kdevplatform and let GDB and LLDB plugin built on top of that. But we risk breaking the existing GDB plugin which already does a good job. Therefore, I plan to first focus on implementation of LLDB plugin with a copy of all needed classes in kdevplatform, and only after the LLDB plugin reaches a rather mature state, shall we begin port GDB to use the new infrastructure.

Communication with LLDB

This can be done by expose a interface class with all available lldb commands and internally delegate the command execution to one of the LLDB interface mentioned below. Other parts of the LLDB debugger plugin will rely solely on the interface class to post lldb commands/jobs. This design is similar to what is used in GDBDebugger::CppDebuggerPlugin. This is the foundation of all other parts of the plugin, so I plan to make this part solid by my best effect before moving on to the next part.

Possible LLDB Interface to Use

LLDB released LLDB-MI on 2014, and there is another project LLDBMI2 that does the same thing. Along with those, there is the good old C++ API. Further investigation and evaluation is needed to finally determine on which one to use. Here just list a brief description of each choise.

• LLDB-MI
  • Included in the LLDB source code, which means better support
  • A good separation of input/factory/output
  • Seems only support remote debugging
  • Limited command implemented at the time of the blog written (might have been changed since then)
• LLDBMI2
  • Seems to be a simple MI interface to LLDB, which is more lightweight than LLDB-MI
  • Not official but actively maintained
  • Only support local debugging and only support Mac OS X
• C++ API
  • Directly link to LLDB, which should be fast and the API is mature
  • Must find a way to protect ourselves from debugger crashes
  • Write from scratch, can’t reuse MI code for GDB

Implement LLDB Specific Classes

These classes is higher level than the above, and is the major classes that teach KDevelop how to use LLDB to debug.

IDebugSession represents a specific debug session with a debugger of some type. Currently GDBDebugger provides an implementation DebugSession, but it contains GDB specific code. The same applies to other classes such as BreakpointController and FrameStackModel.

LLDB of course should be configured differently than GDB. Currently, the user can tune various options for GDB in the launcher configuration page. This should be extended to let the user change the debugger used for a particular debug launcher and configure separately.

Here is a brief list of related classes

• DebugSession
  • BreakpointController
  • VariableController
  • FrameStackModel
• ConfigPageFactory
• Launcher and jobs
  • DebugJob

Move non GDB Specific Classes to KDevPlatform

As said above, the GDBDebugger plugin contains many non GDB specific code. Rather than rewrite the same thing for LLDB debugger plugin, I plan to reuse these code as much as possible. This includes UI widgets for different tool views, context menu items and dialogs. Drkonqi and the glue code between user action and IDebugSession methods are other parts that can be potentially reused.

• UI
  • ToolViews
    • RegisterView
    • DisassembleWidget
    • GDBOutputWidget
    • MemoryViewDlg
  • Context Menu
  • Dialogs
    • DebugTracingDialog
    • SelectCoreDialog
    • ProcessSelection
• Drkonqi
• DebugSession management

PretteyPrinters

These scripts are used to make C++/STL and Qt objects easier for the user to read. Currently I’m not sure if they are still needed for LLDB. If so, this might need to be ported to LLDB data formatters.

Tests

The importance of tests can never be over emphasized. I’m going to start with the same unit tests as GDB when applicable and add other tests when find problems during the implementation.

Timeline

Milestones

• April 22 (2 weeks): If accepted, I will start by contributing little bug fixes to KDevelop to get familiar with the code base. Besides that, the most work for this period will be investigating and playing with different ways to talk with lldb. It is important to have this period before actually starting coding, as the decision of which LLDB interface to use would affect the overall stability and quality of the plugin, and it deserves some careful thought.
• May 6 (3.5 weeks): Around this time, I should have done some demos on talking to LLDB. Use this experience gained from previous weeks, I will start actually build the communication infrastructure with LLDB. This could be a totally rewrite from stratch or an extension of the previous demo depends on what method I choose.
• May 31 (3 weeks): We should have a final communication infrastructure with LLDB (part 1) now. And based on that, I can start implement most of the important controllers and managers for the plugin, including IPlugin, IDebugSession and friends.
• June 21 (4 weeks): Most of the important controllers and mangers (part 2) should have been implemented at this time. Although they may still contain stub methods which are related to UI setups and Drkonqi. I give this period the longest time because in my opinion, it is the UI that actually talks to users, and any small bug in it will frustrate them. Thus I not only need to implement them, but also polish them to some extent.
• July 19 (4 weeks): The whole plugin should work for simple use cases by then. And the last 4 weeks are used to revise and finialize the code to fix any remaining bugs as well as move non GDB specific classes into kdevplatform.git. This period also serves as a buffer as we are always optimistic in estimating works and it always turns out to take longer!
• Augest 15: Fine tune and bug fixes done, project finish.

Availability

I will stay at the university for research during the summer break, which basically is another project to do. However, the time schedule for the research is flexible, and two project at the same time is the regular workload for a normal semaster. So I believe I can manage my time accrodingly and there shouldn’t be a problem.

About me

My name is Peifeng Yu, a master student at the University of Michigan majoring in Computer Science. I’ve been using KDE as my major desktop for years and really enjoy the amount of customization it allows. As a programmer, I use KDevelop for most of my projects because of its better support for CMake based projects (and yes, sometimes QtCreator if I’m using qmake ;-) ). I was excited when it first announced the integration with clang compiler. Now here’s opportunity to integrate further with llvm toolchain and it would be exciting if I can contribute to it.

As for the skills, I’ve been programming in C++ for about 5 years and it’s my favorite language. I consider myself an experienced C++ programmer thanks to my experience on ACM/ICPC during my undergraduate, which sharpened my program skills and helped me gain more insight in algorithms.

And I love Qt, which makes coding a pleasure. Although not worked on very big projects (That’s why GSoC!), I have several little programs written in C++/Qt including my graduate project, which are all hosted on Github. Apart from that, I’m always curious about language implementation details and have read a lot about C++ and Qt internals. These knowledge seems unnecessary on the first sight, but they do help me handle tricky situations when the code goes wrong. CMake and Git are also my friends, which I use on a daily basis.

Besides that, I have a strong background on all basic software related fields, such as algorithm, data structure, compiler, computer archetecture and operating systems, as learnt in my undergraduate (Software Engineering, Xi’an Jiaotong University) and graduate (Computer Science, University of Michigan) study.

参考是Candesoft-BLOG

大体思路就是首先分点，记录同一位置不同剩余油量的花费。

int cost[N+1][N+1][K+1];

然后从起点开始一点一点扩展，分别判断有和没有加油站的情况走到4个方向上是否是更优的花费。有点儿类似Dijkstra最短路的感觉。

#include <iostream>#include <queue>#include <cstring>#include <cstdio>#include <cmath>using namespace std;#define ll long long//template<typename T>//inline T min(const T& a, const T& b) { return a < b? a:b;}//template<typename T>//inline T max(const T& a, const T& b) { return a > b? a:b;}const int N = 100;const int K = 10;const int dirs[][2] = {{ -1, 0}, {1, 0}, {0, -1}, {0, 1}};struct Position{    int x, y, k;};queue<Position> que;int cm[N + 1][N + 1][K + 1];int map[N + 1][N + 1];int inqueue[N + 1][N + 1][K + 1];int n, k, a, b, c;bool isValid(int x, int y){    if(x < 1            || x > n            || y < 1            || y > n)    {        return false;    }    return true;}void init(){    memset(cm, -1, sizeof(cm));    cm[1][1][k] = 0;    memset(map, 0, sizeof(map));    memset(inqueue, 0, sizeof(inqueue));    while(!que.empty())    {        que.pop();    }}void checkBetter(int x, int y, int k, int cost){    // If is better to go to (x, y) from (p.x, p.y)    if(cm[x][y][k] == -1 || cm[x][y][k] > cost)    {        cm[x][y][k] = cost;        if(inqueue[x][y][k] == 0)        {            Position tem;            tem.x = x;            tem.y = y;            tem.k = k;            que.push(tem);            inqueue[tem.x][tem.y][tem.k] = 1;        }    }}int driveCar(){    Position pos;    pos.x = pos.y = 1;    pos.k = k;    inqueue[1][1][k] = 1;    que.push(pos);    while(!que.empty())    {        Position p = que.front();        que.pop();        inqueue[p.x][p.y][p.k] = 0;        for(int d = 0; d != 4; d++)        {            int dx = dirs[d][0], dy = dirs[d][1];            int x = p.x + dx, y = p.y + dy;            if(isValid(x, y))            {                int cost = cm[p.x][p.y][p.k];                if(dx < 0)                {                    cost += b;                }                if(dy < 0)                {                    cost += b;                }                // No station.                if(p.k > 0 && map[p.x][p.y] == 0)                {                    // If is better to go to (x, y) from (p.x, p.y)                    checkBetter(x, y, p.k - 1, cost);                }                // Has station, ether a new built one, or one already exists.                cost += a;                if(map[p.x][p.y] == 0)                {                    cost += c;                }                // Add fuel and check again                checkBetter(x, y, k - 1, cost);            }        }    }    int mincost = 0x7fffffff;    for(int i = 0; i <= k; i++)    {        if(cm[n][n][i] > 0 && mincost > cm[n][n][i])        {            mincost = cm[n][n][i];        }    }    return mincost;}int main(){#ifdef ACM_LOCAL    freopen("input.txt", "r", stdin);    //freopen("output.txt", "w", stdout);#endif // ACM_LOCAL    while(scanf("%d%d%d%d%d", &n, &k, &a, &b, &c) != EOF)    {        init();        for(int i = 1; i <= n; i++)            for(int j = 1; j <= n; j++)            {                scanf("%d", &map[i][j]);            }        printf("%d\n", driveCar());    }#ifdef ACM_LOCAL    printf("Used time: %lf\n", clock() / (double) CLOCKS_PER_SEC);#endif // ACM_LOCAL    return 0;}

速度还是挺快的：

不过Candesoft-BLOG里说的分层图最短路的没有仔细看。

正好这两天复习算法，所以整理了一下。有些时候有这么一个模板还是挺方便的说。

直接上代码了

struct ForwardStarWGraph;struct Node;struct CallbackFunctor{    virtual bool shouldExtend(ForwardStarWGraph& graph, Node& toExtend) = 0;    virtual bool operator() (ForwardStarWGraph& graph, Node& curr) = 0;};struct Node{    int i;    int from;    int edge;    int totalWight;    vector<int> path;};const int N = 20; // max vertex conutconst int M = N*N; // max edge countstruct ForwardStarWGraph{    int to[M], nxt[M], head[N];    int wight[M];    int ecnt;    // Actual vertex number    int n;    void graphInit(int nn, int m)    {        ecnt = 0;        n = nn;        memset(head, -1, sizeof(head));    }    // Add an edge, vertex counts from 0    void addEdge(int u, int v, int w)    {        to[ecnt] = v;        wight[ecnt] = w;        nxt[ecnt] = head[u];        head[u] = ecnt;        ecnt++;    }    // Add an undirectional edge    void addBiEdge(int u, int v, int w)    {        addEdge(u, v, w);        addEdge(v, u, w);    }    int wightBetween(int a, int b)    {        if(a == b)            return 0;        for(int e = head[a]; e!= -1; e = nxt[e])        {            if(to[e] == b)                return wight[e];        }        return -1;    }    void bfs(CallbackFunctor& func)    {        queue<Node> Q;        Node tem;        tem.i = 0;        tem.from = -1;        tem.edge = -1;        tem.totalWight = 0;        tem.path.push_back(0);        Q.push(tem);        while(!Q.empty())        {            Node t = Q.front(); Q.pop();            func(*this, t);            for(int e = head[t.i]; e!= -1; e = nxt[e])            {                if(to[e] == t.from)                    continue;                Node t2;                t2.i = to[e];                t2.from = t.i;                t2.edge = e;                t2.totalWight = t.totalWight + wight[e];                t2.path = t.path; t2.path.push_back(t2.i);                if(func.shouldExtend(*this, t2))                {                    Q.push(t2);                }            }        }    }    void dfs(CallbackFunctor& func)    {        stack<Node> Q;        Node tem;        tem.i = 0;        tem.from = -1;        tem.edge = -1;        tem.totalWight = 0;        tem.path.push_back(0);        Q.push(tem);        while(!Q.empty())        {            Node t = Q.top(); Q.pop();            func(*this, t);            for(int e = head[t.i]; e!= -1; e = nxt[e])            {                if(to[e] == t.from)                    continue;                Node t2;                t2.i = to[e];                t2.from = t.i;                t2.edge = e;                t2.totalWight = t.totalWight + wight[e];                t2.path = t.path; t2.path.push_back(t2.i);                if(func.shouldExtend(*this, t2))                {                    Q.push(t2);                }            }        }    }};

附带一个测试小程序

int n, m;ForwardStarWGraph g;struct Routine : CallbackFunctor{    virtual bool shouldExtend (ForwardStarWGraph& graph, Node& toExtend)    {        return true;    }    virtual bool operator() (ForwardStarWGraph& graph, Node& curr)    {        cout<<curr.i+1<<endl;    }};int main(){#ifdef ACM_LOCAL    freopen("input.txt", "r", stdin);    //freopen("output.txt", "w", stdout);#endif // ACM_LOCAL    while(scanf("%d %d", &n, &m) != EOF)    {        g.graphInit(n, m);        for(int i = 0; i!= m; i++)        {            int a, b, w;            scanf("%d%d%d", &a, &b, &w);            g.addBiEdge(a-1, b-1, w);        }        Routine routine;        g.bfs(routine);    }#ifdef ACM_LOCAL    printf("Used time: %lf\n", clock() / (double) CLOCKS_PER_SEC);#endif // ACM_LOCAL    return 0;}

还是要注意边缘的情况，比如当(0,8)(18,18) 切割(18,0)(19,19)的时候，结果应该是得到三个矩形

• (18,19)(18,19) --> 面积为1
• (19,0)(19,19) --> 面积为20
• (18,0)(18,7) --> 面积为8

恩，其实我一直没搞懂为啥给数据的时候llx和lly是真正的坐标值，而urx和ury却必须减一之后再用…

/*ID: xjtuacm1PROG: rect1LANG: C++*/#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<set>#include<map>#include<vector>#include<cmath>using namespace std;const int M = 100000;const int N = 1000;struct rect{    int llx, lly;    int urx, ury;    int color;    rect(int lx = 0, int ly = 0, int rx = 0, int ry = 0, int c = 0)    : llx(lx), lly(ly), urx(rx), ury(ry), color(c) {}    int S()    {        return (urx - llx + 1) * (ury - lly + 1);    }}rects[M], cur;int tot;inline bool cross(const rect& r1, const rect& r2){    return !(             (r1.llx > r2.urx)             || (r1.urx < r2.llx)             || (r1.lly > r2.ury)             || (r1.ury < r2.lly));}inline void add(const rect& t){    rects[tot++] = t;}inline void del(int idx){    rects[idx] = rects[--tot];}void cut(const rect& t, bool vertical = false){    int k1, k2;    rect tem = t;    if(vertical)    {        k1 = max(t.lly, cur.lly);        k2 = min(t.ury, cur.ury);        if(t.lly < k1)        {            tem.ury = k1 - 1;            add(tem);        }        if(k2 < t.ury)        {            tem = t, tem.lly = k2 + 1;            add(tem);        }    }    else    {        k1 = max(t.llx, cur.llx);        k2 = min(t.urx, cur.urx);        if(t.llx < k1)        {            tem.urx = k1 - 1;            add(tem);        }        if(t.urx > k2)        {            tem = t, tem.llx = k2 + 1;            add(tem);        }        tem = t, tem.llx = k1 , tem.urx = k2;        cut(tem, true);    }}int main(int argc, char *argv[]){#ifdef ACM_LOCAL // Local    freopen("in", "r", stdin);#else    #ifndef  ONLINE_JUDGE // not HDOJ / POJ    freopen("rect1.in", "r", stdin);    freopen("rect1.out", "w", stdout);    #endif#endif    int a, b, n;    scanf("%d %d %d", &a, &b, &n);    add(rect(0, 0, a-1, b-1, 1)); // add the white sheet first.    while(n--)    {        scanf("%d %d %d %d %d", &cur.llx, &cur.lly, &cur.urx, &cur.ury, &cur.color);        cur.urx--, cur.ury--;        for(int i = tot-1; i>= 0; i--)        {            if(cross(cur, rects[i]))            {                cut(rects[i]);                del(i);            }        }        add(cur);    }    map<int, int> cnt;    for(int i = 0; i!= tot; i++)    {        cnt[rects[i].color] += rects[i].S();    }    for(map<int, int>::iterator it = cnt.begin(); it!= cnt.end(); it++)    {        if(it->second)            printf("%d %d\n", it->first, it->second);    }    return 0;}

BTW, 果然学新的算法就要跟着代码一行一行调试～虽然感觉上慢了点但是可以掌握透彻～

还有，IOI国家集训队论文2004年薛茅的讲线段树跟矩形切割的，很清楚，链接在这里。

参考了 http://www.2cto.com/kf/201209/156711.html 的代码，进行了一些修改，个人感觉更简洁且比较容易理解。

#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<set>#include<map>#include<vector>#include<cmath>using namespace std;const int M = 100000;const int N = 10000;struct line{    int l, r;    int color;    line(int ll = 0, int rr = 0, int c = 0) : l(ll), r(rr), color(c) {}}post[M], cur;int tot;bool used[N];inline bool cross(const line& l1, const line& l2){    return !(             (l1.l > l2.r)             || (l1.r < l2.l));}inline void add(const line& t){    post[tot++] = t;}void cut(const line& t){    if(t.l < cur.l)    {        add(line(t.l, cur.l-1, t.color));    }    if(t.r > cur.r)    {        add(line(cur.r+1, t.r, t.color));    }}int main(int argc, char *argv[]){#ifdef ACM_LOCAL // Local    freopen("in", "r", stdin);#else    #ifndef  ONLINE_JUDGE // not HDOJ / POJ    freopen("humble.in", "r", stdin);    freopen("humble.out", "w", stdout);    #endif#endif    int ncase;    scanf("%d", &ncase);    while(ncase--)    {        tot = 0;        int color = 0;        int n;        scanf("%d", &n);        while(n--)        {            scanf("%d %d", &cur.l, &cur.r);            cur.color = color++;            // 倒序，否则在cut操作中增加的线段也会再被检查一遍            for(int i = tot-1; i>= 0; i--)            {                if(cross(post[i], cur))                {                    cut(post[i]);                    post[i] = post[--tot];                }            }            add(cur);        }        memset(used, false, sizeof(used));        int cnt = 0;        for(int i = 0; i!= tot; i++)        {            if(!used[post[i].color])            {                used[post[i].color] = true;                cnt++;            }        }        printf("%d\n", cnt);    }    return 0;}

BTW，按说注释中提到的那个循环改成顺序的应该也可以的，只是会慢一些，但实际提交了却是RE。目前还不清楚原因。

/*ID: xjtuacm1PROG: agrinetLANG: C++*/#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<set>#include<map>#include<vector>#include<cmath>using namespace std;const int MAXDIS = 100000 + 10;const int N = 100;const int M = N * (N - 1) / 2;int n, m;int e;int u[M], v[M], w[M];int wr[M];void initGraph(){    e = 0;}void addEdge(int x, int y, int cost){    u[e] = x;    v[e] = y;    w[e++] = cost;}class UnionFind{    int n;    int fa[N];    int r[N];public:    UnionFind(int nn)        : n(nn)    {        init();    }    void init()    {        memset(r, 0, sizeof(r));        for(int i = 0; i!= n; i++)            fa[i] = i;    }    int Find(int x)    {        if(x != fa[x])        {            fa[x] = Find(fa[x]);        }        return fa[x];    }    void Union(int x, int y)    {        Link(Find(x), Find(y));    }private:    void Link(int x, int y)    {        if(r[x] > r[y])        {            fa[y] = x;        }        else        {            fa[x] = y;            if(r[x] == r[y])                r[y]++;        }    }};bool cmp(int a, int b){    return w[a] < w[b];}int kruskal(){    UnionFind uf(n);    for(int i = 0; i!= m; i++)        wr[i] = i;    int ret = 0;    sort(wr, wr+m, cmp);    for(int i = 0; i!= m; i++)    {        int ed = wr[i];        if(uf.Find(u[ed]) != uf.Find(v[ed]))        {            ret += w[ed];            uf.Union(u[ed], v[ed]);        }    }    return ret;}int main(int argc, char *argv[]){#ifdef ACM    freopen("in", "r", stdin);#else    freopen("agrinet.in", "r", stdin);    freopen("agrinet.out", "w", stdout);#endif // ACM    scanf("%d", &n);    m = n * (n - 1) / 2;    for(int i = 0; i!= n; i++)        for(int j = 0; j!= n; j++)        {            int t;            scanf("%d", &t);            if(i > j)                addEdge(i, j, t);        }    printf("%d\n", kruskal());    return 0;}

重点是添加新的边之后的field的直径等于

1.原来两个field的直径2.新的边长加从它的两个端点可以延伸的最大长度

这其中的最大值。

/*ID: xjtuacm1PROG: cowtourLANG: C++*/#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<set>#include<map>#include<vector>#include<cmath>using namespace std;const int N = 150;const double DINF = 1e30;struct Point{    int x, y;} pes[N];int adj[N][N];int color[N];double dis[N][N];double maxDis[N];double dia[N];int n;void floodfill(int cur, int tag){    color[cur] = tag;    for(int i = 0; i!= n; i++)    {        if(adj[cur][i] && color[i] == -1)        {            floodfill(i, tag);        }    }}int find_component(){    int cnt = 0;    for(int i = 0; i < n; i++)        if(color[i] == -1)            floodfill(i, cnt++);    return cnt;}double dist(int a, int b){    if(!adj[a][b])        return DINF;    return sqrt((pes[a].x - pes[b].x) * (pes[a].x - pes[b].x)                + (pes[a].y - pes[b].y) * (pes[a].y - pes[b].y));}void floyd(){    for(int i = 0; i!= n; i++)        for(int j = 0; j!= n; j++)            dis[i][j] = dist(i, j);    for(int k = 0; k!= n; k++)        for(int i = 0; i!= n; i++)            for(int j = 0; j!= n; j++)                dis[i][j] = min(dis[i][j], dis[i][k] + dis[k][j]);}int main(int argc, char *argv[]){#ifdef ACM    freopen("in", "r", stdin);#else    freopen("cowtour.in", "r", stdin);    freopen("cowtour.out", "w", stdout);#endif // ACM    scanf("%d\n", &n);    for(int i = 0; i!= n; i++)    {        scanf("%d %d\n", &pes[i].x, &pes[i].y);    }    for(int i = 0; i!= n; i++)    {        char line[N + 1];        gets(line);        for(int j = 0; j!= n; j++)        {            adj[i][j] = (line[j] == '0'? 0 : 1);            dis[i][j] = dist(i, j);        }    }    memset(color, -1, sizeof(color));    int ncom = find_component();    floyd();    for(int i = 0; i!= ncom; i++)        dia[i] = 0;    for(int i = 0; i!= n; i++)    {        maxDis[i] = 0;        for(int j = 0; j!= n; j++)        {            if(i!= j && color[i] == color[j])            {                maxDis[i] = max(maxDis[i], dis[i][j]);            }        }        dia[color[i]] = max(dia[color[i]], maxDis[i]);    }    double diameter = DINF;    for(int i = 0; i!= n; i++)        for(int j = 0; j!= n; j++)    {        if(color[i] == color[j])            continue;        double d1 = 0;        double d2 = 0;        for(int k = 0; k!= n; k++)        {            if(i != k && color[i] == color[k])                d1 = max(d1, dis[i][k]);            if(j != k && color[j] == color[k])                d2 = max(d2, dis[j][k]);        }        double dist = sqrt( (pes[i].x - pes[j].x) * (pes[i].x - pes[j].x)                           + (pes[i].y - pes[j].y) * (pes[i].y - pes[j].y) );        diameter = min(diameter,                       max(dist + d1 + d2,                           max(dia[color[i]], dia[color[j]])));    }    printf("%.6lf\n", diameter);    return 0;}

BTW，对复杂代码的掌控能力还是不够。。虽然这道题有了完整思路，但是写不出完整的代码，最后还是参考了题解才写完…

/*ID: xjtuacm1PROG: comehomeLANG: C++*/#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<set>#include<map>using namespace std;const int INF = 0x3f3f3f3f;const int M = 10000;const int N = 52;// Graph structureint n;int to[M], nxt[M], head[N];int w[M];bool vis[N];int e;int dist[N]; // Distance arraystruct cmp{    bool operator() (int a, int b)    {        return dist[a] > dist[b];    }};void init(){    memset(vis, false, sizeof(vis));    memset(head, -1, sizeof(head));    e = 0;}void addEdge(int u, int v, int c){    to[e] = v;    nxt[e] = head[u];    w[e] = c;    head[u] = e++;}void addBiEdge(int u, int v, int c){    addEdge(u, v, c);    addEdge(v, u, c);}void dijkstra(int src){    // Reset distance array    memset(vis, false, sizeof(vis));    for(int i = 0; i!= n; i++)        dist[i] = INF;    priority_queue<int, vector<int>, cmp> que;    vis[src] = true;    dist[src] = 0;    que.push(src);    int pnt = src;    for(int i = 1; i!=n; i++)    {        for(int j = head[pnt]; j!= -1; j = nxt[j])        {            int v = to[j];            if(!vis[v] && dist[pnt] + w[j] < dist[v])            {                dist[v] = dist[pnt] + w[j];                que.push(v);            }        }        while(!que.empty() && vis[que.top()])            que.pop();        if(que.empty())            break;        pnt = que.top(); que.pop();        vis[pnt] = true;    }}set<char> cows;int r[N];bool indirectCmp(int a, int b){    return dist[a] < dist[b];}int toIdx(char ch){    if(ch != tolower(ch))        return ch - 'A';    else        return ch - 'a' + 26;}char toChar(int idx){    if(idx < 26)        return idx + 'A';    else        return idx - 26 + 'a';}int main(int argc, char *argv[]){    freopen("comehome.in", "r", stdin);#ifndef USACO    freopen("comehome.out", "w", stdout);#endif // USACO    int p;    scanf("%d\n", &p);    n = N;    init();    while(p--)    {        char f, t;        int c;        scanf("%c %c %d\n", &f, &t, &c);        if(f == t)            continue;        bool flag = false;        for(int edge = head[toIdx(f)]; edge != -1; edge = nxt[edge])            if(to[edge] == (toIdx(t)))        {            w[edge] = min(w[edge], c);            flag = true;            break;        }        for(int edge = head[toIdx(t)]; edge != -1; edge = nxt[edge])            if(to[edge] == (toIdx(f)))        {            w[edge] = min(w[edge], c);            flag = true;            break;        }        if(flag)            continue;        addBiEdge(toIdx(f), toIdx(t), c);    }    dijkstra(toIdx('Z'));    for(int i = 0; i!= n; i++)        r[i] = i;    sort(r, r+n, indirectCmp);    for(int i = 1; i!= n; i++)    {        if(r[i] < 26)        {            printf("%c %d\n", toChar(r[i]), dist[r[i]]);            break;        }    }    return 0;}

一开始想到的是dijkstra，在两个出口分别运行一次，取每个点到两个出口距离中最短的，再去其中最大的即可。

然后想到其实分别从两个出口作BFS，标注每个点的距离即可。

/*ID: xjtuacm1PROG: maze1LANG: C++*/#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<set>#include<map>using namespace std;const int W = 38;const int H = 100;const int INF = 0x3f3f3f3f;const int dir[4] = { 1, 2, 4, 8};int stage[H][W];int color[H][W];int h, w;struct Point{    int x, y;    Point(int xx = 0, int yy = 0) :x(xx), y(yy) {}    bool operator<(const Point& rhs) const    {        if(x == rhs.x)            return y < rhs.y;        return x < rhs.x;    }    bool connect(int d) const    {        return !(stage[x][y] & dir[d]);    }    Point next(int d) const    {        switch(dir[d])        {        case 1:            return Point(x, y-1);        case 2:            return Point(x-1, y);        case 4:            return Point(x, y+1);        case 8:            return Point(x+1, y);        }        return Point();    }};void init(){    for(int i = 0; i!= h; i++)        for(int j = 0; j!= w; j++)        {            stage[i][j] = 0xF;            color[i][j] = INF;        }}void addEdge(const Point& u, const Point& v){    const Point& a = u<v ? u : v;    const Point& b = u<v ? v : u;    if(a.x == b.x)    {        stage[a.x][a.y] ^= 1<<2;        stage[b.x][b.y] ^= 1;    }    if(a.y == b.y)    {        stage[a.x][a.y] ^= 1<<3;        stage[b.x][b.y] ^= 1<<1;    }}void bfs(const Point& src){    color[src.x][src.y] = 1;    queue<pair<Point, int> > que;    que.push(make_pair(src, 1));    while(!que.empty())    {        Point pt = que.front().first;        int dis = que.front().second;        que.pop();        for(int i = 0; i!= 4; i++)        {            if(pt.connect(i))            {                Point nxt = pt.next(i);                if(dis+1 < color[nxt.x][nxt.y])                {                    color[nxt.x][nxt.y] = dis + 1;                    que.push(make_pair(nxt, color[nxt.x][nxt.y]));                }            }        }    }}int main(int argc, char *argv[]){    freopen("maze1.in", "r", stdin);#ifndef USACO    freopen("maze1.out", "w", stdout);#endif // USACO    scanf("%d %d", &w, &h); getchar();    init();    Point extCell[2];    int extCnt = 0;    char line[2*W + 2];    // first line    gets(line);    for(int i = 0; i!= strlen(line); i++)    {        if(line[i] == ' ')            extCell[extCnt++] = Point(0, (i - 1) / 2);    }    for(int i = 0; i!= 2 * h - 1; i++)    {        gets(line);        if(i & 1)        {            for(int j = 0; j != strlen(line); j++)            {                if(line[j] == ' ')                {                    addEdge(Point((i-1)/2, (j-1)/2),                            Point((i+1)/2, (j-1)/2) );                }            }        }        else        {            if(line[0] == ' ')            {                extCell[extCnt++] = Point(i / 2, 0);            }            if(line[strlen(line) - 1] == ' ')            {                extCell[extCnt++] = Point(i / 2, w - 1);            }            for(int j = 2; j< strlen(line) - 1; j+= 2)            {                if(line[j] == ' ')                {                    addEdge(Point(i/2, j/2 - 1),                            Point(i/2, j/2) );                }            }        }    }    // last line    gets(line);    for(int i = 0; i!= strlen(line); i++)    {        if(line[i] == ' ')            extCell[extCnt++] = Point(h-1, (i - 1) / 2);    }    bfs(extCell[0]);    bfs(extCell[1]);    int m = 0;    for(int i = 0; i!= h; i++)        for(int j = 0; j!= w; j++)        m = max(m, color[i][j]);    printf("%d\n", m);    return 0;}

• http://www.cppblog.com/Yuan/archive/2010/09/02/125667.html?opt=admin
• http://blog.csdn.net/acm_cxlove/article/details/8101710

$X_1...X_{n-1}$，这是题中所说的未给出的$n$个数，维护一个带权的并查集，每个点有一个权$w$

保证有w[k] = Xk ^ Xfa[k]，Xfa[k]表示Xk的父亲。

对于

I p q v

则对p, q进行Union操作，并利用v维护各自的权w

对于

I p v

可以加入虚拟节点$n$，令Xn = 0， 这样任意以该节点为父亲的节点均有w[k] = Xk;

这样就转化成I p n v了

而对于每次查询

Q k p1 p2 ... pk

结果ans = Xp1 ^ Xp2 ^ ... ^ Xpk = w[p1] ^ w[p2] ^ ... ^ w[pk] ^ (Xfa[p1] ^ Xfa[p2] ^ ... ^ Xfa[pk]).

这里利用了性质：

任取整数a，有

a ^ a = 0;

a ^ 0 = a;

又因为 w[p1] ... w[pk] 是已知的, 只需判断 Xfa[p1] ... Xfa[pk] 是否已知即可，即看这些节点是否以Xn为根。

注意的一点是 Xfa[p1] ... Xfa[pk] 中会有重复的，只要出现了偶数次就不用计算，只用考虑出现奇数次的就行了。

另一点注意的是输入输出的形式以及输入行尾换行符的处理，我就在这个地方WA了n多次= =

#include<iostream>#include<stack>#include<cstring>#include<cstdio>#include<queue>#include<algorithm>#include<map>using namespace std;const int N = 20000 + 1;const int K = 15;const int LINELEN = 150;int fa[N], w[N];int n,q;int nfacts;char line[LINELEN];void init(){    for(int i = 0; i<= n; i++)        fa[i] = i;    memset(w, 0, sizeof(w));    nfacts = 0;}int Find(int x){    if(x != fa[x])    {        int t = fa[x];        fa[x] = Find(fa[x]);        w[x] ^= w[t];    }    return fa[x];}bool Union(int p, int q, int v){    int rp = Find(p);    int rq = Find(q);    if(rp == rq)    {        return  v == (w[p] ^ w[q]);    }    if(rp == n) swap(rp,rq);    fa[rp] = rq;    w[rp] = w[p] ^ w[q] ^ v;    return true;}bool info(int a, int b, int c){    bool rt = Union(a, b, c);    if(!rt)        printf("The first %d facts are conflicting.\n", nfacts);    return !rt;}int main(int argc, char *argv[]){#ifdef ACM    freopen("ttwo.in", "r", stdin);#endif // ACM    int ncase = 1;    while(scanf("%d %d", &n, &q), n != 0 || q != 0)    {        printf("Case %d:\n", ncase++);        init();        bool conflict = false;        while(q--)        {            char tp[5];            scanf("%s", tp);            if(tp[0] == 'I')            {                nfacts++;                getchar();gets(line);                int a, b, c;                int rt = sscanf(line, "%d %d %d", &a, &b, &c);                if(rt == 2)                {                    c = b; b = n;                }                if(conflict) continue;                conflict = info(a, b, c);            }            else if(tp[0] == 'Q')            {                int k;                int para;                map<int, bool> fas;                bool known = true;                int ans = 0;                scanf("%d", &k);                for(int i = 0; i!= k; i++)                {                    scanf("%d", &para);                    if(conflict) continue;                    fas[Find(para)] = !fas[Find(para)];                    ans ^= w[para];                }                if(conflict) continue;                for(map<int, bool>::iterator it = fas.begin(); it != fas.end(); it++)                {                    if(it->second)                    {                        ans ^= w[it->first];                        if(!(known = (Find(it->first) == n)))                            break;                    }                }                if(!known)                {                    puts("I don't know.");                }                else                {                    printf("%d\n", ans);                }            }        }        putchar('\n');    }    return 0;}