andreyg / ifc-reader Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
Currently ifc-reader depends on boost-iostreams for memory mapping the ifc file.
I propose letting this be application defined, and which means they can use boost-iostreams themselves, or use something more lightweight like mio, or just reading a file the normal way.
Then the ifc-reader would only need to accept a const char*
, similar to raw_pdb for example.
We could still have boost-iostreams as a dependency for our examples & unit tests. Just have it not be required for any applications that want to use this as a library.
Let me know what you think!
I ran into an issue where I wanted to access the conversion function name, which wasn't exposed yet.
So I fully implemented the Name
kinds and structures, submitted as PR #34.
Partly a stylistic choice, but it's commonly agreed that structs meant for more "Plain old data" and classes are meant for types with functions.
This is also supported by the C++ Core Guidelines C.2.
Hi @AndreyG,
Thanks for the great work you've done on this project so far, it looks seriously awesome!
I'd be interested in playing around with some of your code, but I'm hesitant to do so without their being a license on the repo -- would you be able to add one? MIT would be awesome, if you'd be happy with that.
Thanks!
In principle, reflifc wraps an AbstractReference
with the accompanying ifc File
. These both have sane defaults. An AbstractReference
has AbstractReference::is_null()
and the file can be nullptr
.
I wanted to start a discussion, if making these types default constructible was something you had already considered. I've found it nice if I can default construct them.
All reflifc types combine the ifc::File
and some pointer/index, however the file is never exposed.
This might be partly a design decision, but for my current use case I need to check if a certain type/declaration from a certain module (so ifc::File
, or reflifc::Module
). To determine if a type is visibility or reachable.
Do you have any concerns with adding this to the API?
Currently I see that most types have a reference back to their file as ifc::File const&
. This is considered bad practice because it makes the type not copy/move assignable. I suggest keeping the references in the constructor to keep the invariance, but store a pointer in the class.
This is also backed up by the C++ Core Guidelines C.12.
It would be good to have some unit tests to maintain the library, as you mentioned too.
The simple approach would be to upload a bunch of .ifc
files for specific tests.
However, I'd argue it's also important to build those .ifc
's from source code. So you are verifying a platform instead of just the platform of the developer who uploaded that specific .ifc
file. So I prefer this approach.
My issue is I am not aware of a reliable way to get the path to a .ifc
file from a .ixx
file.
Eg Visual Studo Open Folder (so with Ninja as the build system) will follow relative subfolders to the .ifc file, and a .sln build will plonk everything in the intermediate directory.
Do you think this be abstracted in the MSVCEnvironment? we could have different defines identifying if we are running from CMake, Visual Studio, Ninja or MSBuild for example.
(Incidently this linking of an .ixx
to it's .ifc
file is something I need to solve for my own side project too.
With cl.exe
@ 19.30.30705.0
, compiling the following:
cl.exe /W4 /WX /experimental:module /interface /sourceDependencies . /std:c++latest /EHsc /MD /c mod_moo.cpp
where the argument to /sourceDependencies
is .
, then MSVC gives you:
mod_moo.cpp.json
There are two things here:
ifc-reader
looks for the suffix .d.json
, but the output from MSVC is just .json
ifc-reader
looks for <ifc_name>.<suffix>
but MSVC generates <src_file_name>.<suffix>
(that is, the name of the output file is the name of the source file and not the name of the IFC file)Maybe a suggested fix here should be that ifc-reader
could take an additional argument for the path to the source dependencies file?
I've just been revisiting my steps from:
which work apart from the MSVC hello.cpp.json
needs to renamed to hello.ifc.d.json
(but that's fine).
However, when I run dump-decls
on this example:
export module hello;
import std.core;
export namespace hello {
void say_hello(uint32_t count);
}
I get:
IFC Version: 0.43
File contains 18 partitions
Global Scope Index: 1
Total declarations count: 2
Scopes count: 2
Count of declarations from all scopes: 2
-------------------------------------- Global Scope --------------------------------------
Namespace 'hello' {
Function 'say_hello', type: void(Unsupported DeclSort '8')
}
So I'm surprised I'm seeing Unsupported DeclSort '8'
rather than uint32_t
(the 8
is also weird, because if this was bytes it should be 4
).
Is this expected? Should I be able to see uint32_t
here?
The IFC was generated with:
cl.exe /Bv
Microsoft (R) C/C++ Optimizing Compiler Version 19.40.33521 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
Compiler Passes:
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\cl.exe: Version 19.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\c1.dll: Version 19.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\c1xx.dll: Version 19.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\c2.dll: Version 19.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\c1xx.dll: Version 19.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\link.exe: Version 14.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\mspdb140.dll: Version 14.40.33521.0
Z:\home\avj\visual_studio\MSVC\14.40.33521\bin\Hostx64\x64\1033\clui.dll: Version 19.40.33521.0
For my use cases I really need to cache declarations etc to avoid circular dependencies. While traversing all types.
Most of the reflifc types are build as: ifc::File*
+ ifc::SomeIndex
or ifc::PartitionData*
.
Those two numbers can easily be hashed together with a hash combine. But I cannot do it outside the library as the members are private.
Would you like me to work on a pull request for this? Or would you prefer to put it in yourself.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.