the requirement for pre-processing makes me a bit suspicious, it's going to be a pain to interact with other parts of the toolchain, so i would hope there's a very good reason for it. i would make this at the top of the README.md.

The same comments apply to a lesser extent to the C++14 requirement- does your framework really benefit from using C++14 features over say C++11 ? Again I would make this clear at the top of the README.

You are right. I'll make it clear in the README. The preprocessing can be easy done by hand for those who want to skip the use of the preprocessor, it is actually pretty simple:

[...]

@test

[...]

is equivalent to:

iod_define_symbol(test, _test)

[...]

s::_test

[...]

Their is 3 reason for implementation of the @ syntax:

  - Not having to pre-declare all the symbols.

  - Replacing s::_ by @

  - Suggesting a new simple but powerful feature to 
    the teams writing clang++ and g++.

And yes, silicon needs generic lambda function from C++14 . But this is less a problem since this is already in g++, clang++, and soon in the visual studio c++ compiler.

I'm too lazy/not interested enough in this to give it a try, and am not sure at all that they are powerful enough to do what you want, but have you considered using user-defined literals? The way I understand these work,

  "test"@

could return an object that allows one to write

  "test"@("hello"!)

The constructors called could, of course, also link that object in a global store.

Could it not have been expressed with just a macro?

EDIT: Down votes? lol

Here is the tranformation done by the preprocessor: https://gist.github.com/matt-42/a53cc0b0a8d8f1cf673f

It would be really convenient to have it done by the C preprocessor, but it seems impossible to me to get it with macro only. Am I wrong?

It seems like you could do something like:

    #define IOD_SYM(name) iod_define_symbol(name, _##name);
    #define S(name) s::_##name;

Then use S(test) instead of @test and any files that need these symbols defined could just have IOD_SYM(test) at the top or something.

#define S(name) is a bit dangerous. It would affect any C/C++ function called S.

Actually using [ZLang](https://github.com/pfultz2/ZLang), you could define them like this:

    #define IOD_DEFINE_SYMBOL(name) iod_define_symbol(name, _##name)
    #define IOD_S(name) s::_##name

    #define ZLANG_iod_define (IOD_DEFINE_SYMBOL)
    #define ZLANG_iod_s (IOD_S)

And then compiling with `-DZLANG_NS=iod` you can call it like this:

    // Define symbols
    $(define hello)
    $(define message)

    auto hello_api = make_api(

        // The hello world procedure.
        $(s hello) = [] () { return D($(s message) = "Hello world."); }

    );

Also, ZLang can be supported without a need for a dependency on ZLang.

If the author has seen Facebook proxygen[1] (another C++ http framework), a comparison to it would be helpful.

At first glance, it looks like the Silicon dependency microhttpd is somewhat analogous to proxygen. Is the Silicon value-added proposition the extra layers on top such as auto gen of client-side code, etc?

[1] https://github.com/facebook/proxygen

Indeed, Silicon should be seen as a glue between low level http libraries, a message encoding format, others externals resources like databases, and your actual API.

You can use it with microhttpd, or any other network libraries (the current version provides backends to cpp-netlib and mimosa https://github.com/abique/mimosa). Future integration with websocket library is planned.

Don't know much about proxygen but it seems like the goal of the project are similar: Ease the writing of high performance C++ web APIs. However, when reading proxygen echo sample [1], I would say that silicon has a higher level of abstraction.

[1] https://github.com/facebook/proxygen/tree/master/proxygen/ht...

I like the concepts behind this framework, even if the '@' symbol is debatable. I think, combined with something like CodeSynthesis' ODB ORM (which apparently supports migrations now), something like this could be used to create some really efficient, light weight web applications that give frameworks like node.js a run for their money.

I like the idea of running a light C++ application on a crappy $5/month VPS and squeezing out every last drop of performance, built on top of the idea that modern C++ developers can crank out solutions as fast as Ruby or Python developers. From interviewing and talking to people, I don't think the vast majority of developers really understand how far C++ has come in the last 15 years.

The real PITA with web frameworks is how they interact with the database. Now that C++ has some decent ORMs, an improved feature set, and some strong renewed interest, I think we can make C++ a "web language".

I'll write more about it later, but silicon actually has a nice way to deal with databases. It currently only support sqlite, but it has:

- a sqlite middleware: See the example here: https://github.com/matt-42/silicon#middlewares

- a sqlite ORM middleware: https://github.com/matt-42/silicon/blob/master/silicon/sqlit...

- a generic CRUD implementation (relying on the ORM): https://github.com/matt-42/silicon/blob/master/tests/crud.cc

The mysql, redis, postgresql equivalents will come soon.

That is pretty awesome! Something for postgresql would be great.

My stack heavily relies on pg and the other ORMs performance have been disappointing, I need to use something like this.

The @ definition is insane, something which would never fly in large scale projects. And who names a library function D? If the authors feels typing full meaningful function names is too much he should stay with Javascript. Good C++ is code which is readable by 3rd parties not just yourself.

This whole library smacks of #define BEGIN { #define END }

Thanks for you feedback. The @ is just a convenient syntaxic sugar. I will explain in the README how to use silicon with plain C++ code.

I really enjoy the C++ language but am incredibly rusty since I haven't had a job in a very long time that requires the knowledge of use of the language. I was actually thinking about writing my own web framework for fun and learning (a bonus if it became useful but I wasn't holding my breath) but now that I see this I'm going to play around with it and see if it doesn't want I wanted or if I'll still work on one.

Not a huge fan of the preprocessor usage but still very interesting and very cool!

Even if it not clear in the readme. The preprocessor is optional. I posted the plain c++ version of the hello_word example here: https://github.com/matt-42/silicon/issues/2#issuecomment-705...

I will add a note in the readme about the preprocessor and how to bypass it.

I have to admit, I have no idea what the @ symbol does. Can anyone clarify?

It can't be a macro, so I assume it's a C++14 feature I'm not aware of.

It is not part of C++14, it is a small syntaxic sugar that compiles to iod symbols. A compiler convert it to plain C++. In short, their are empty objects holding a unique C++ type. More info here: https://github.com/matt-42/iod

Pretty interesting Matt, would you consider uploading to biicode (a C++ deps manager) so that C++ programmers reuse it in there projects?

Nice idea. I probably do so after I fix the first batch of issues.

This is the getting started guide:

http://docs.biicode.com/c++/gettingstarted.html

Hope you find it useful.

This is so exciting! I wanna test it out right now and I have so many questions.

are there any more docs than the description on Github readme?

I know this sounds very n00b of me, but can I use this as an Api layer for raw data?

I'd love to see more middlewares built around it. I used the 'Tree frog framework' for a while, I felt my work flow was not too efficient due to different api layers.

Thanks for your enthusiasm, you can post your questions here. The project is still young and not funded so I do not have much time to write a comprehensive doc, but I'll do my best.

What do you mean by Api layer for raw data?

you actually answered on my question on another reply. I want to make a postgres adapter and use this to retrieve the data, since my current API is written in ruby and it's a bit too slow.

For the funding part! I'd love to help, perhaps a good start would be using it inside some solution :)! Been there done that. Either way kudos.

Where are the benchmarks? Seriously, I'd expect this thing to fly.

The perf depends on the backend. However the overhead of the framework is almost 0. I'll publish the benchmark but with microhttpd I was able to serve 280k req/second with the hello work example and a 4 cores I5 processor

> I was able to serve 280k req/second

Please don't forget to measure latency - both averages and percentiles :)

the point of this kind of thing is that it can allow super fast performance for critical endpoints:

Suppose your app consumes a JSON api and it turns out that one or two endpoints constitute most of the server load.

Rewriting one or two endpoints using a lightweight, fast framework can be a great solution, so long as you are already being smart about caching and there aren't other bottlenecks in your architecture.

why not Assembly? it's faster... :)

I guess you meant that C++ is verbose.. But silicon is designed such that you do not write more lines than you would in Go, Nodejs or Ruby frameworks.

New features like auto and lambdas reduce C++'s verbosity to manageable levels. In many cases it's less verbose than Java.

Could you give an example of the Arc Challenge[0] with it? I would like to see something we could use as a comparison to those other langauges.

[0] http://arclanguage.org/item?id=722

Building on an unused standard ensures failure and is little more than masturbation. The use of preprocessor sugar proves this yet further.

This isn't useful. All new systems start with no software available for them, and they only stop being "unused" when someone starts using them. Like this is doing.

This actually looks like a really neat project.

That was the useful comment of the day :D Seriously, share your failure with the world so we can understand your point.

That c++ grew the way it did by providing a slow moving target for developers.