while loop in software

[zapta]

If that is all that you are going to use C++ for, then as Howardlong stated, you can use naming conventions to get the same result in C. After all that's all the name mangling does.

When you program in C++, do you use naming conventions instead of namespaces? Let me guess, no, because namespaces are more intuitive and are cheap in runtime resources. What about C++ references, do you also avoid them when you program in C++? No, because in some instances there are more intuitive than pointers and again have insignificant runtime cost.  And we keep going with other C++ features such as overloading and others. The bottom line is that C++ has extensions of C that are useful and cheap, even in resource sensitive applications.

[Rigby]

As for blaming C as the cause of exploits, I doubt it, I don't see many servers running C, most likely is badly coded php that allows SQL injections. And that doesn't mean buffer overruns, it just means bad programming that would allow you to do a for * query.

All kinds of server run C in the form of lib*.so or lib*.dll or whatever that is used by the language that the application coding was actually done in or the server the applications run on.  This is how Heartbleed had such a huge surface attack area: libSSL.so.

In Perl, there is the concept of "taint checking."  You can force a Perl script to disallow the use of user input before it has been "checked" via a regular expression.  That was added well over a decade ago, it is a simple thing, and yet no other language (that I know of) utilizes taint checking.  Taint checking alone, (if not worked around by a developer) would eliminate SQL injection, because it would force the developer to validate the query string against a regex.  Maybe a regex isn't the best vehicle for this, but I hope my point is coming across. We could add things to stop common bugs, but we continue to rely on the developer to remember more and more and more, when the tooling could (and arguably should) handle a great deal of it.

[Marco]

PHP is a whole different class of bad...

The latest Drupal SNAFU is pretty funny ... write a framework to separate arguments from commands (with escape character filtering of the arguments being done by the framework) to avoid SQL injection ... then have the code interpret the arguments as something other than pure strings. Good show.

[westfw]

Stick to pure C/C++ (libc and friends), write some abstraction layer, and you'll have to only (re)write the platform specific sections.

yeah; right.  I'm looking at porting some code from the relevant era, and it has separate Make targets for BSD, SYSV, Ultrix, AIX, Next, HPUX, and more.  And I was serious about field days caused by new compiler versions; I think it was going from 2.95 to 3.x where gcc decided that string constants could no longer include newlines (hundreds of files with built-in but not normally compiled "full description" fields for error messages.  Sigh.)  Even with up-to-date versions of all the compilers involved, you can find queries on AVRFreaks and equivalent about how to rewrite C from Codevision to Imagesoft to gcc to mikro-C.   It's not the code that has been very carefully written by experts cognizant in the subtleties of portability between a dozen environments that gets you, it's the code written in an entirely reasonable way by people who are less aware (and that's a lot of code.)

[Mechatrommer]

portability is a theoritical ideal. in practice its not that ideal...
1) code have to be bloated with #if switch and you cant think what system you are going to target in the future
2) new thoughts or condition in the future will change the language spec and mostly inevitably will screw past spec for portability. basics is good example i know (even c/c++) but i'll stick to one revelation and forget portability, so long my app is working and aiding me in my system. its manmade anyway, man makes mistake, so there's nothing wrong sticking with older revelation
3) even if the old code are portable, do you care to recompile 20yrs of app code for your new modern app? no! at most you'll use it as reference. even big companies make a complete rewrite in new version from the older version just few not so old yrs ago.

i heard some people saying PHP is bad, then what option do i have for programming web interface? i already bought the PHP book yet to be learnt :|

[theoldwizard1]

Ahh, you youngsters !

All modern "structured" languages are actually decedents of ALGOL !

First language to have "free form" input,  "blocks" (BEGIN ... END), and nested (reenterant) functions !  Nested function required the first use on a "stack" for parameter passing and return addresses.  It also introduced the Bacus-Naur Form, a definitive method of specifying computer languages.

It was extensively used by Burroughs (yeah, who?) "large systems" starting in 1961.  They even had the concept of data memory versus program memory that were protected from each other (GOSH, no chance of executing off of the end of the stack or memory space not allocated to you process  !)

[miguelvp]

Really? if you want to go to the past, not that it's going to be MCU friendly anyways, at least talk about Fortran that predates Algol and actually was used and taught to EEE students.

[Howardlong]

...although I'm not sure I'd rate Fortran particularly highly as promoting structured programming.

I never have really figured out the popularity of Fortran, maybe it's because the "programmer" can choose to ignore machine limitations much of the time and concentrate on enormous array based processing, with the compiler desperately papering over the cracks.

Algol 60 was my first programming language, using paper tape for input and output. Back in the 70s I still remember being taught GOTO in one of the first exercises. Oh dear!

[zapta]

Really? if you want to go to the past, not that it's going to be MCU friendly anyways, at least talk about Fortran that predates Algol and actually was used and taught to EEE students.

Apparently it's still alive  http://en.wikipedia.org/wiki/Fortran#Fortran_2015 , just like Aramaic.

[jaxbird]

There is merit in trying to avoid stored procedures and functions, but really, what matters is, when your queries include joins on 100 million row tables, that you get the query execution plan right. i.e. use the best join order, the right indexes, don't pull fields you don't need etc. It's pretty bad when such queries result in large table scans. And once a heavy, cached plan, query goes wrong it will seriously affect the performance.

It's much more than that in the SQL world. Fundamentally it's understanding the data and its distribution, then being able to read query plans, avoiding index scans as well as table scans, knowing when and how to force a plan, the effect of parameterisation, the nuances of the optimiser, undertanding IOs and spindle management to name a few. Unfortunately, in my experience of over two decades with my primarily role on SQL Server, code developers are not generally great SQL coders, but are frequently let loose.

While functionally a coder's SQL might work, you can bet your ass they won't have any clue how it will perform of a representative dataset, and will never have looked at a query plan let alone understand one. It's not their fault, it's just a specialised area, and while 95% of their SQL might work reasonably well 5% won't. I remember 15 or so years ago when the marketing mantra over databases was that the optimisers were so darned good, I almost thought I was out of a job. Actually what it meant that the edge cases were even more difficult to identify, and when they were they were a bitch to resolve. Instead it made my apparently mundane DBA job more challenging and interesting.

Anyway I digress. In general the performance thing has been my specialty for a very long time, and if I can't understand a system from the keyboard through the app, OS, network all the way through back up the server side and whatever else is going on, I would't feel qualified to make a call on a troubleshooting situation. Coder: "It's a network problem". Network guy: "It's an app problem". Server guy: "It's not the server". You must've been there. I guess it's also why I'm so at home with coding C, and, maybe once or twice a year I end up writing a bit of assembler on the very rare occasion it isn't performing quite how I wanted, and again this is a matter of understanding your data, although I debug at the machine level pretty much every day for understanding performance in embedded systems. I like my C to reflect what I think the machine's going to be doing, even though I know when I finally switch the optimiser on I can be sure under the hood it'll have generated gobbledegook.

I agree with defining certain standards like naming conventions, file locations etc but there it mostly ends for me I'm afraid. Perhaps it's because I used to define standards, but it didn't take long to discover that there were much more important battles to fight in the mega corp greasy pole than some petty layout mantra that that was more likely to make me sound anal (which I certainly am about my own code!) to the bosses than be a positive facet. As I say, if you've hired some half decent programmers they'll deal with it. If you have programmers that struggle to read and maintain reasonably written code then you've probably hired the wrong guys, maybe they should take up knitting or something.

I agree, designing well performing queries for large databases is a very complex task, in general my preferred approach is to have devs work on a database with random data using approximately the same distribution and size as any enterprise would potentially generate. That results is much less implementation issues than working on a 10 row per table database during dev. Also the whole working on a several thousand table DB needs to be strictly controlled, as in tracking all changes for client updates and in case something goes bad, you need to be able to roll it back.

The SQL server is often a performance bottle neck in a large system, as in, you can cluster it, but still it needs to be synchronized. And you need to be able to do backups while keeping it online and in more extreme cases you need to be able to fail over to a 2nd set of servers in case of emergencies. Much easier to scale clients and middle tier.

The code standard thing is more of a preference I stick to based on experience (I'll do the same for any SQL review). When you deal with millions of lines of code and you need everyone to be able to dive in a fix something, often written by someone else, and preferably without creating any regression bugs, part of my job is to make their job as easy as possible. It's really not an issue in a professional environment.

[westfw]

at least talk about Fortran

I don't think that anyone considers (historical) ForTran to have been a "Structured Programming Language."
It's interesting that Algol managed to be the parent of structured programming, without being (AFAIK) much of a commercial success itself.  Although I guess that in those days, success in academia WAS indeed "Success."

[Howardlong]

The SQL server is often a performance bottle neck in a large system, as in, you can cluster it, but still it needs to be synchronized. And you need to be able to do backups while keeping it online and in more extreme cases you need to be able to fail over to a 2nd set of servers in case of emergencies. Much easier to scale clients and middle tier.

Clustering in a SQL Server context has nothing to do with performance or scalability, it is for high availability alone, in an active/passive configuration per instance, and even then it'll only work across locally connected nodes, so if you have a site outage you're buggered anyway. Somehow Microsoft managed to sell SQL Server clustering to an awful lot of folk, and at a serious premium too both in terms of software licensing and the hardware required to support it. Only when it was too late did many managers realise the fundamental flaws in it.

While people talk a out active/active clustering on SQL Server, it will be on separate instances, only one node on each instance is ever active at one time. There is no load balancing per the classical definition. To my mind this was one of the more underhand marketing bullshits to come out of Microsoft.

As you say, doing 24/7 on a transactional SQL Server implementation is not easy, especially if you also want high availability. It is possible these days at the database engine level, but in the not too distant past, it had to be done by implementation specific methods which were very hard to maintain.

[jaxbird]

The SQL server is often a performance bottle neck in a large system, as in, you can cluster it, but still it needs to be synchronized. And you need to be able to do backups while keeping it online and in more extreme cases you need to be able to fail over to a 2nd set of servers in case of emergencies. Much easier to scale clients and middle tier.

Clustering in a SQL Server context has nothing to do with performance or scalability, it is for high availability alone, in an active/passive configuration per instance, and even then it'll only work across locally connected nodes, so if you have a site outage you're buggered anyway. Somehow Microsoft managed to sell SQL Server clustering to an awful lot of folk, and at a serious premium too both in terms of software licensing and the hardware required to support it. Only when it was too late did many managers realise the fundamental flaws in it.

While people talk a out active/active clustering on SQL Server, it will be on separate instances, only one node on each instance is ever active at one time. There is no load balancing per the classical definition. To my mind this was one of the more underhand marketing bullshits to come out of Microsoft.

As you say, doing 24/7 on a transactional SQL Server implementation is not easy, especially if you also want high availability. It is possible these days at the database engine level, but in the not too distant past, it had to be done by implementation specific methods which were very hard to maintain.

Sure, the most common, simple active/passive single instance cluster, is purely for redundancy. But the active - active can improve performance, in the case where your system is designed to run on multiple databases, as in you can balance the load across multiple servers/databases and in case of hardware failure (or maintenance) you can run all the instances on a single node. However you do need to evaluate the added cost of distributed transactions as you are likely to need to maintain some level of data integrity across these databases. But then again, it's common to have distributed transactions including message queues, file systems and databases across a number of server clusters in large systems.

Anyway, while for my part interesting and happy to exchange real experience with large system architecture options, I think we might be getting into a pissing contest here Probably not much related to uC and FPGA programming.

Edit: Merry Christmas

[Howardlong]

Agreed, merry Christmas to you too.

Cheers!

[Mechatrommer]

christ was not born 25dec

[jaxbird]

christ was not born 25dec

True, but these days, in the western part of the world Christmas less of a religious event and more about a tradition being nice to everyone and sharing a moment of joy, happiness and celebration with family and friends. I'm sure you have similar events in your part of the world if not, you should adapt the spirit of Christmas.



 

[paulie]

christ was not born 25dec

Also unlikely he or any relation was involved with creation of the space time continuum or even the homo sapien species. I'm not saying impossible, just unlikely.

BTW It's very important to keep important threads like this on topic.

[zapta]

christ was not born 25dec

... which brings us back to the should-I-use-the-while-loop dilemma, what would Christ do?

[jaxbird]

... which brings us back to the should-I-use-the-while-loop dilemma, what would Christ do?

And not to underestimate the existential question of what is the condition used in the while loop of the Universe?

while (forever?)
{
  Expand();
}
otherwise
{
  Contract();
}

So is the universe as we know it just a poorly coded expansion loop or are the Hindis correct that it was meant to be an infinite loop of expansion and contraction?

 

[westfw]

what would Christ do?

God writes in LISP code: 
(I especially like the description of assembler...)

[jpelczar]

christ was not born 25dec

... which brings us back to the should-I-use-the-while-loop dilemma, what would Christ do?

Yes. By all means - use it. If someone says that for is faster than while (or *x++ is faster than a=*x; x++;, or goto is slow), then he must have spent last 10 years under a rock or is high on cocaine. If some compiler produces non-optimized code in either case, it should be shredded, thrown into a volcano and forgotten about - no sane compiler these days cares about this and it means you are using worthless piece of crap, which would probably be acceptable during Atari 2600 era. Code is expanded into various machine and language independent forms and optimized from there. Modern compilers have optimizers. If your program works incorrectly when you turn optimization on - it means your program has a bug. Shitty code with loops like while(i-->0); do make "delay" is reduced to nothing. Expressions without side effects are mercilessly exterminated. If something can be evaluated during compilation time (even function calls), they're removed and replaced with the result.

[zapta]

...Shitty code with loops like while(i-->0); do make "delay" is reduced to nothing.

Not if if i is volatile, right?

If something can be evaluated during compilation time (even function calls), they're removed and replaced with the result.

As a matter of style I avoid #define whenever possible (which is almost always the case) and leave it to the compiler to optimize it. For example

const int kSize = 10*3;   // rather than #define SIZE (10*3)
...
char buffer[kSize];

[Kjelt]

const int kSize = 10*3;   // rather than #define SIZE (10*3)
...
char buffer[kSize];

I rather have a long #define list in the header file than a long list of consts in the c file but that is a choice. Most important for me is that the programmer chooses a relevant name for the value instead of larding his code with magic numbers.

[0xdeadbeef]

As a matter of style I avoid #define whenever possible (which is almost always the case) and leave it to the compiler to optimize it. For example

const int kSize = 10*3;   // rather than #define SIZE (10*3)
...
char buffer[kSize];

This creates worse code than the define since the compiler can't replace the constant variable by a constant offset.
E.g. if this was a struct array, the multiplication with the size of struct can't be optimized.
The qualifier "constant" just means that the value doesn't change during runtime. It doesn't mean it's fixed during compile time.
This is heavily used in embedded projects to exchange only the constants without touching the code ("calibration").
-> Using defines is a perfectly valid way of optimization in C and not bad style at all if you use it in a sensible way.

[zapta]

The qualifier "constant" just means that the value doesn't change during runtime. It doesn't mean it's fixed during compile time.

Why it's not fixed value at compile time? What other values can it has?