Question

我注意到，使用emscripten，即使是相对较小的C ++文件也可以快速转换为相当庞大的JavaScript文件。例如：

#include <memory>
int main(int argc, char** argv) {
  std::shared_ptr<int> sp(new int);
}

使用像

这样的命令将其与最近的emsdk进行编译

em++ -std=c++11 -s DISABLE_EXCEPTION_CATCHING=1 -s NO_FILESYSTEM=1 \
     -s NO_BROWSER=1 -s NO_EXIT_RUNTIME=1 -O3 -o foo.js foo.cc

生成的文件超过400k。我可以使用-g

grep -n '^function _' foo.js | c++filt -_

看看我们在那里有什么样的功能。以下是一些例子：

std::__1::moneypunct<char, false>::do_thousands_sep() const
std::__1::locale::~locale()
std::__1::basic_string<wchar_t, …>::~basic_string()
std::__1::time_get<…>::__get_day(…) const
std::__1::codecvt<wchar_t, char, __mbstate_t>::codecvt(unsigned int)
std::__1::locale::__imp::install(std::__1::locale::facet*, long)
_printf_core

我自己并没有打电话给任何一个，但是所有的功能都包括在内。可能其中许多都包含在一些虚拟功能表中。其他可能是由于一些静态初始化器。

如果这是正常的代码链接到我的硬盘驱动器上的某个共享库;我不反对。但只需要一个共享指针，就可以传输半兆字节的JavaScript代码？必须有办法避免这种情况。

Answer 1

一个解决方案，实现了here，只是将C ++库分成几个部分。通过将处理I / O和locale的代码移动到一个单独的库中，所有可以在没有这个的情况下工作的代码可以避免I / O子系统的静态初始化器，这会导致依赖于上述功能。不幸的是，由于显而易见的原因，这也会影响strstream。

更新：由于上游commit 301e4ad（首次包含在1.30.6版本中），系统库不再编译为单个*.bc文件，而是作为*.a静态库，包含多个不同的对象。其中，只有所需的实际链接在一起，这对简单案例的代码大小减少了很多。

省略一些C ++子系统

1 个答案: