Thread: a C++ library of mine.

Originally Posted by citizen

Pardon me for speculating, but do you know what CGI is and what it does? Some types of web sites will require interaction with the user -- if you so much as utilize form data -- and as Google wants to prove with Chrome, the web is becoming more and more like an application platform. It's not cute to ignore the possibility that you would need to write some perl or something for a website.

And I really hope that you would choose an interpreted language for the web since it is much easier to use perl or php to interpret form data and draw pages on the fly.

I believe that was the point zacs was trying to make. But you did admit that every job has a tool ...

Yes, I do know what CGI (typically Perl) and PHP are.
I've used PHP + mysql myself.
Well yes, to be honest, I'd rather use C++ for server-side applications rather than PHP or Perl, if I could make it work. Honestly, I don't know how because I haven't done it.
Mostly the reason is speed (native vs interpreted) and syntax (Perl syntax confuses me with all its operators and all that).
If it was a job, then PHP or Perl would probably be used instead, part due to it being easier and part being that it's platform independent.
But with server-side, it's not a 50+ OSes you have to worry about, though, unlike web pages.

this is also why I like C++ - it can borrow and create strengths from other programming languages due to its flexibility. It doesn't support properties natively, but with some knowledge, I can emulate it.

Well, C++ supports... err... properties natively. Strange would be an OOP programming language not supporting data members.

The confusion you are drawing here is that you expect C++ to follow the semantics of other programming languages like VB. But that's obviously not the case, and "properties" in C++ are implemented through public data members or accessors. In fact the term property is even usually non-existing in the C++ OOP-related lingo. "Data Member" is the term used, regardless how it is interfaced.

I can understand you liking the syntax offered by these programming languages. But you are better off using those languages instead of trying to emulate their behavior on a programming language that has a different syntax. And you should really know this by now. I'm surprised we are having this talk.

As for opinions... maybe they aren't evil. But opinions can be dangerous.

Originally Posted by Mad_guy

No (I don't really do C++ that much and by association Boost) - could you provide me with a code example? If it can accomplish the same thing as succinctly and clearly I would be very impressed and interested in it (and I will retract my earlier point about not being able to do it as easily.)

If I understand your earlier example correctly, it checks that all sorts of brackets in a string are balanced.

That would look something like this:

Code:

namespace
{
  rule<> term = // Term is ...
    ('(' >> term >> ')') | // ... parentheses around a term ...
    ('[' >> term >> ']') | // ... brackets around a term ...
    ('{' >> term >> '}') | // ... braces around a term ...
    (~chset<>("()[]{}") >> !term); // ... or anything but those characters, followed potentially by another term.
}

bool is_balanced(const std::string &input)
{
  return parse(input, term).full;
}

Not quite as concise as the functional version, but quite good.

Originally Posted by Mario F.

I can understand you liking the syntax offered by these programming languages. But you are better off using those languages instead of trying to emulate their behavior on a programming language that has a different syntax. And you should really know this by now. I'm surprised we are having this talk.

I never change, do I? ;-)
Until I find a better language, I'm going to continue to try creating my own "special" language.

As for opinions... maybe they aren't evil. But opinions can be dangerous.

Oh yes, I'm fully aware. I remember how many times they've gotten me in trouble...

But with server-side, it's not a 50+ OSes you have to worry about, though, unlike web pages.

Off my head, I can think of 6 at least partially binary-incompatible OSs you may have to think of for server applications which are in common use for servers: Windows, Linux, FreeBSD, NetBSD, OpenBSD and Solaris.

I only know of Apache (typical Linux) and Windows Server. They seem to be the most popular if I'm not mistaken.

Those are web servers, not OSs (well, Windows Server is a Windows edition, but I think you mean IIS). Apache runs on any of the OSs I named.
Of course, for server applications there's Apache, IIS, lighttpd, five or six different servlet containers (Tomcat, Jetty, WebSphere, ...), and probably some more.

Not quite as concise as the functional version, but quite good.

I will very much say a lot better than I expected! :]

(nitpick: the example earlier was factor code, which is not a functional language but a stack based one, along the lines of Forth.)

The only place it can have a speed advantage is when you're using an x64 OS and the native app is written for 32bit.

Citation needed. Otherwise this is just nonsense.

Otherwise, native apps are often designed to check if a processor feature exists and if it does, they use that feature when it's useful.

I'm not quite sure what you mean by this. Do you mean the application determines at runtime if e.g. SSE4 instructions are available and use them? If so, I've never seen a compiler insert things like this into the code path - things like instruction availability (e.g. SSE/MMX) are generally speaking turned on by options at compiled time and if done that immediately makes it incompatible with processors that do not share the same specifics (you are likely to get illegal instruction errs or something of the sort.) If you are speaking of determining things like this at runtime then, again, citation needed.

(Unless of course you are talking about compile time, but determining such things is really more a function of your build system than anything I would imagine.)

mplayer does it. But the detection is hand-written, not compiler-supported. At startup, it detects the CPU capabilities and sets a few function pointers accordingly.

If so, I've never seen a compiler insert things like this into the code path

Intel compiler does this thing
It can compile 2 versions of the assembly code into the exe - 1 using some High-end processor intructions specified by compilation flag, another - using some basic set of instructions (for example any PIII) and adds the switch in the beginning of the main function - that selects the appropriate code to be working based on the CPU type installed

Originally Posted by Mad_guy

Citation needed. Otherwise this is just nonsense.

The source of this citation is me. But you can always prove me wrong if you want to.

Originally Posted by Mad_guy

If you are speaking of determining things like this at runtime then, again, citation needed.

I have seen it in media players, also I have seen it in the disassembly of games and other graphics applications.

Edit: This can be done with the cpuid instruction or by WinAPI function IsProcessorFeaturePresent(). cpuid instruction is often used in Windows applications because the WinAPI function for that was introduced in Windows NT, so this way it is compatible with older Windows versions.