Let me clarify: code generation is not hard, especially if you have a low quality bar. Generating good general purpose code is extremely hard.

I know the code with a 1-sized array works fine. That's not my point. My point is it looks ridiculous to anyone who reads the code, and it's such a trivial transform to use a local variable instead of a 1-sized array that it makes me (personally) wonder what other shortcuts your code generation is taking that perhaps I would not want as a prospective client.

It isn't a regular bug and I don't think you're saying it's a performance bug... I don't say it is irrelevant, but more of a "would be nice."

I won't delve into the subject of whether or not the project is useful, but I'd be very cautious about using it given the quality of what it seems to put out.
[/quote]

This is more important
http://lists.boost.o...10/05/58858.php

That hasn't been addressed as of Boost 1.49 and I haven't seen any indication it will be in 1.50. As I note on this page, the boost-based program is more than 2.4 times slower than the equivalent Ebenezer version.

Sure, but being required to be connected to the internet to write code is so outrageous that it makes me leery of things that are less simple than that basic premise.

For most development these days, off-line option no longer exists.

For native apps, there's version control, build and test servers, deployment, etc...
For web apps, everything is on web - there are no local proxies for web APIs.
Even SDK and other large packages are increasingly "smart", providing you with installer and then bring stuff down piecemall. Fortunately, serious one still allow offline/enterprise installs.

And any third-party library will be linked via repository and while it may be cached locally, one still requires access to that server.


Having to be connected to internet is reality today.

Packaging and format of on-line service may vary, but realistically very little is still done off-line.


What's worse is that new ecosystems are completely runaway with no oversight. So using a certain API may require you to check out git, run a shell script to call wget, may provide some other script which unzips some tar, may rely on some third-party service.

It's surprising how anything post-Java became absurdly difficult to isolate since just about all fragments depend on opaque network dependencies. It's one of the reasons why there's a sharp divide between ecosystems used by enterprise environments and the rest.


And you might be surprised that 9/10 developers today don't even know this is happening. In many ways, that's a good thing. They don't know what it means to compiler, configure and mangle some library - instead they get stuff done by using a service of immense value (shopping cart, payment API, networking features).

Long term problems come from precisely this lack of standardization and oversight.

Sure, but being required to be connected to the internet to write code is so outrageous that it makes me leery of things that are less simple than that basic premise.

When free is what you can afford, there are tradeoffs. There are lots of intelligent, poor people in Russia, India, China, Ukraine, Greece, Spain, Egypt ...

The output from the C++ Middleware Writer is fairly well formatted code. If you lose your internet connection due to a storm or something, and need to keep working on your project, you can resort to hand-editing the last version of the generated code. Not ideal, but better than nothing.

Edit:

"[font="UsherwoodStd-Medium"][font="UsherwoodStd-Medium"]Where [/font][/font][font="UsherwoodStd-Medium"][font="UsherwoodStd-Medium"]something like model-driven development looks promising, [/font][/font][font="UsherwoodStd-Medium"][font="UsherwoodStd-Medium"]the generated code should be well-structured and [/font][/font][font="UsherwoodStd-Medium"][font="UsherwoodStd-Medium"]human readable—going directly to low-level code could [/font][/font][font="UsherwoodStd-Medium"][font="UsherwoodStd-Medium"]easily lead to too much trust in nonstandard tools." [/font][/font]

[font="UsherwoodStd-Medium"][font="UsherwoodStd-Medium"]That's another quote from Bjarne. I had the opportunity to meet him in 2003 and give him a demo of the C++ Middleware Writer.[/font][/font]

Sorry, but plenty of work still gets done on the plane/train/bus.

I don't think that's exactly a very important use case. For serious remote work, it's done from home over VPN. The rest is done on LANs.

Work without connection may apply to hobbysts or such.

Even if code writing does not require constant connection, email, instant messaging, etc... effectively ensures we're always connected these days.

Very little is done off-line, but frankly it's code generation. Code generation that needs the internet to work? WTF?[/quote]

WAN? Public internet? Probably not. Then again, BigCo. remote VPNs do exactly that and it's not unusual for high quality networks to be subsidized by employer. CISCO, VMWare and such offer some very big solutions.

Virtualization these days, even primarily intended for LANs or, again, VPNs is increasingly used, often via full remote desktop connection. And this applies to all work, including stuff like airline terminals at airport used by non-developers who cannot get anything at all done if network is down.

Network connection? Yes, almost always. If anything, programming is one of last domains where network connection is optional, since a lot of work can actually be completely detached. And programming is the lest interesting part, there's testing, building, deployment, updates, synchronization, ....

If brokers moving trillions every day work not only online, but with guaranteed uptimes, then there's nothing preventing programmers from doing so.

Compiling, resolving issues, looking over bug reports, talking to coworkers via IM even when they're at next desk, updating status...

Then there's Google Docs. Not ideal, but how many million users do they have? Apparently, it's not a big deal as far as technical issues go.



This is not to be mistaken with control over service. Whether it makes sense for some part of infrastructure to exist solely at some third-party. That's a different problem, but for anything important, there's always a local install (github, Atlassian, etc...). All such services provide a local (behind firewall) install.

But from business perspective, numbers aren't that clear anymore in many cases. Uptime provided by respectable third-parties is often considerably better than what local IT is capable of providing, all costs considered.

you can resort to hand-editing the last version of the generated code.[/quote]

That's wasted effort. First rule of generated code is to never edit generated code.

On bigger scale, never fork third-party libraries unless you take over ownership. After only a few remote changes, keeping things in sync becomes prohibitively expensive.

Free isn't terribly compelling when you're positioning yourself against another free library.

I've already mentioned some advantages of the C++ Middleware Writer (CMW). Look at how big the boost-based executables are compared to their Ebenezer counterparts. I've never seen a Boost Serialization based program that was smaller than the equivalent Ebenezer program. How well is the Boost library being maintained? I wrote that post about using move in serialization in May of 2010. It hasn't been addressed yet. Has anyone even opened a ticket for that yet? Meanwhile, the CMW has been getting an overhaul over the past year: there's support for emplace_back, move, unique_ptr, range-based for loops, scoped enums and some other things.

I believe the CMW has an advantage over the Boost library in portability. That's due to the much smaller amount of code that has to downloaded/maintained by users.