 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
server
Guest
|
 Posted: Fri Jan 27, 2006 9:32 pm Post subject: stoopid begineer with a question |
 |
|
message unavailable |
|
| Back to top |
|
 |
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: stoopid begineer with a question |
|
|
WToma wrote:
| Quote: | Do you know how many gourp members does it take to change a light bulb?
|
That is a hardware issue and has nothing to do with C++. Certainly the
standard neither states, nor implies, anything about light bulbs. You
should ask your question in a group specific to your specific lighting
management system. |
|
| Back to top |
|
|
Aaron Graham
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Comment on style |
|
|
| Quote: | Which I find more readable foe one thing and find it easier to comment out a
block of code because
} else if(c.foobar()) {
y();
} else if(c.mybar()) {
requires you to edit the "} else if(c.foobar()) {" line to place the "else"
statement on a separate line in order to comment out the line or insert a
"/*" in the middle of the else line, whereas
}
else if(c.foobar())
{
y();
}
else if(c.mybar())
simply requires you to place a /* ahead of the "else if(c.foobar())" line
and a "*/" after the closing brace.
|
Or...you could just do this:
// } else if(c.foobar()) {
// y();
} else if(c.mybar()) {
The problem with the "every brace gets its own line" philosophy is that
reading the code requires a lot more scrolling. It's extremely
aggrivating trying to figure out a piece of code where half of all the
lines are just braces, because there's never very much information on
one page.
I find that It's easy to tell how often someone has to read/debug other
peoples' code by how he structures his his own code. If he uses a
separate line for every brace, tabs all over the place (or worse yet,
spaces mixed with tabs), hungarian notation, etc., then he probably
hasn't spent much time looking at someone else's code.
And, no offense, but generally, people who code in a vacuum like that
don't often write good code. In fact, the best coders I know don't get
to write their own code very often. They spend most of their time
fixing someone else's bugs, since they're the only ones who can.
| Quote: | Finally I hate single character variable names, even in example code, even
though I sometimes (rarely) use them myself 
|
There's nothing wrong with it if its scope is very localized. If I can
see what 'x' is simply by looking at the line of code above where it's
used, there's no reason to give 'x' a long name; it's just clutter.
Aaron |
|
| Back to top |
|
|
shaun roe
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Comment on style |
|
|
In article <1138352969.484397.312110 (AT) g47g2000cwa (DOT) googlegroups.com>,
pocmatos (AT) gmail (DOT) com wrote:
| Quote: | Hi all,
While I was programming 5 minutes ago a recurring issue came up and
this time I'd like to hear some opinions on style. Although they are
usually personal I do think that in this case as also to do with making
the code easier to read.
Imagine a function returning void (for example) and it's body is a big
if with lots of special cases:
void foo(const MyClass &c) {
if(c.bar()) {
x();
} else if(c.foobar()) {
y();
} else if(c.mybar()) {
z();
}
}
The question is if you prefer to see like I've wrote it or with a
return; after a call to x(), and another one after a call to y(), etc
etc... ?
Cheers,
Paulo Matos
|
definitely as you wrote it, and with the braces, in case you decide you
need an extra action in there later. On the other hand, a lot of such
structures (maybe not your particular case) can be written as a find in
a map of function pointers, which can clarify the body of the code. |
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Removing elements in a list that are also in another lis |
|
|
Patrick Kowalzick wrote:
| Quote: | Hello Pete,
I was wondering if somebody could tell me if there is an efficient way
to do the following. Say I have a list(or vector) A and a list B, I want
to remove any elements in B, that are also elements in A.
Sort both lists and use 'set_difference'.
For set_difference you have to create a target list/vector. Do you know a
solution to remove the elements in B directly?
Assuming you've already sorted the two lists, you do essentially what
set_difference does: start with the first element from the selector list,
and walk through the target list until you reach an element that isn't
less than that one. If it's equal, remove it and move to the next element.
Move to the next element in the selector list. Repeat until done.
"remove" in the sense of the Standard Library (pushing non removed elements
as far to the front as possible?).
|
No, remove as in remove from the list. We're dealing here with a
container, so we're not limited to the thngs you can do with a sequence.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com) |
|
| Back to top |
|
|
Pete Becker
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Forward iterators and past-the-end iterator |
|
|
Mark Stijnman wrote:
| Quote: | I have a question about forward iterators and what one should do or not
do with them. I'm planning on writing a container that, when all boils
down to it, stores a sequence of strings. I want threads to be able to
read this sequence from start to end, and when they reach the end, wait
until new data is added to the end. If so, it should pick up reading
where it left off. The question is, is it valid and moral to do
something like this from a reader thread (synchronization code is left
out here for brevity/clarity):
|
If your iterator's increment blocks until there's a new element
available, then it looks a lot like a stream iterator reading from the
standard input stream. The only time the iterator compares equal to the
end iterator is when there's not going to be anything further, such as
when you press whatever magic key combination tells the input system
that it's at end of file.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com) |
|
| Back to top |
|
|
loufoque
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Socket class done the C++ way |
|
|
Mikael S. H. a écrit :
| Quote: | I've been trying to make a socket class. So far, it's been up and down,
getting many different pieces of advice along the way.
Now I've made it a bit functional, although it is doing nothing to check
for errors, and is probably done terribly badly with fds and FILE*s.
Now, I've found out it should inherit the streambuf class. I've found a
class doing this, but it is way too complicated for my learning
capabilities.
Could someone please direct me to the Path that is C++?
I'm not including code, since it's probably crappy, and uses a lot of
files not relevant to this question. If you want it, just ask.
|
You might want to check out ASIO too.
http://asio.sourceforge.net/ |
|
| Back to top |
|
|
JustBoo
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: stoopid begineer with a question |
|
|
On 27 Jan 2006 09:31:24 -0800, roberts.noah (AT) gmail (DOT) com wrote:
| Quote: |
WToma wrote:
Do you know how many gourp members does it take to change a light bulb?
That is a hardware issue and has nothing to do with C++. Certainly the
standard neither states, nor implies, anything about light bulbs. You
should ask your question in a group specific to your specific lighting
management system.
|
YOU! [Moe voice] Why I oughtta'! Bwha! 
Um... Merry Christmas you bastard! <g>
[That's a little... um, just a little um... joke. sigh]
Admit it, right before you clicked on this when you saw my moniker,
just for a split second you thought, oh... :-D
"One night I walked home very late and fell asleep in somebody's
satellite dish. My dreams showed up on TVs all over the world."-sw |
|
| Back to top |
|
|
Matthias Kluwe
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: positions of attributes |
|
|
Hi!
"Axel F" <fix (AT) iff (DOT) fhg.de>:
| Quote: | class Cvec3
{
public:
float* begin() { return &x; }
operator float*() { return &x; }
public:
float x,y,z;
};
and I want to use c-function which take a pointer to float like some gl
functions. So I have defined the function begin(). I know this works and I
had never problems with this.
Somebody of my team says now, that it is not secure to do this, cause the
compiler can reorder the members x,y,z or can change pack alignment. He says
that nothing can be found about this in the c++ standard.
|
Hmm, I can't call me an expert, but do you want do rely on (c being an Cvec3 object) c.begin()+1 pointing to y? That looks risky to me.
Regards,
Matthias |
|
| Back to top |
|
|
mickey
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: class design question |
|
|
Jay Nabonne wrote:
| Quote: | On Thu, 26 Jan 2006 22:10:13 -0800, WittyGuy wrote:
Actually, on embedded devices, a lot of dynamic memory usage can be a
detriment - you may eventually fragment the (relatively small,
non-virtual-memory) heap, resulting in system failure. Not to say dynamic
allocations are bad; you just have to be careful about what you're doing.
(I'm a little unclear on the "most effective way of using memory" comment,
but we don't really have to go there.)
- Jay
|
Completely true and that is one of things I try to avoid, memory
fragmentation, which can be the cause of failure in an embedded device.
Most desktop developers seem to have little understanding of that.
But having the static member array also requires a larger contiguous
memory chunk as opposed to the dynamic allocation scheme.
-Mickey |
|
| Back to top |
|
|
JustBoo
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: stoopid begineer with a question |
|
|
On 27 Jan 2006 02:12:51 -0800, "Geo" <gg (AT) remm (DOT) org> wrote:
That would be for production code correct? Let's parse the real
meaning of the emulating monkey-sheep-speech designed to impress the
perceived Alpha Males.
Argh: You are a stupid fool and I am more superior than you. [While
the monkey-sheep looks back for approval and acceptance from the
perceived Alpha Males.]
Let's examine some code from the good Doctors site:
From Bjarne Stroustrup's C++ Style and Technique FAQ
http://public.research.att.com/~bs/bs_faq2.html
<quote>
How do I write this very simple program?
[small bit of verbage snipped]
#include<iostream>
#include<vector>
#include<algorithm>
| Quote: | using namespace std;
int main() |
{
vector<double> v;
double d;
while(cin>>d) v.push_back(d); // read elements
if (!cin.eof()) { // check if input
failed
cerr << "format error\n";
return 1; // error return
}
cout << "read " << v.size() << " elements\n";
reverse(v.begin(),v.end());
cout << "elements in reverse order:\n";
for (int i = 0; i<v.size(); ++i) cout << v[i] << '\n';
return 0; // success return
}
</quote>
And another:
<quote>
#include<iostream>
#include<string>
| Quote: | using namespace std;
int main() |
{
cout << "Please enter a word:\n";
string s;
cin>>s;
cout << "You entered " << s << '\n';
}
</quote>
You'll find his usage of "using namespace std;" all through his
examples.
If it's good enough for the "founder/creator" then it's good enough
for... well I guess we're going to find out.
I think it's clear, in short *example* programs it should not be a
constant myopic language lawyer wannabe's dream to constantly,
snottily, constantly, pedantically, constantly, humorlessly,
constantly beat that dead horse to a pulp.
"The land that had nourished him and had borne him fruit
now turned against him and called him a fruit. Man, I hate
land like that." -- Jack Handey |
|
| Back to top |
|
|
Gavin Deane
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Comment on style |
|
|
Aaron Graham wrote:
| Quote: | The problem with the "every brace gets its own line" philosophy is that
reading the code requires a lot more scrolling. It's extremely
aggrivating trying to figure out a piece of code where half of all the
lines are just braces, because there's never very much information on
one page.
|
And yet ...
The problem with the "every brace on the code line" philosophy is that
reading the code requires a lot more scrutiny. It's extremely
aggravating trying to figure out a piece of code where all the vertical
whitespace has been removed, because there's always too much
information on one page.
It really is just a matter of personal preference. What makes it harder
for you to read the code makes it easier for me, and vice versa. I
don't think that says anything about our relative abilities as
programmers.
Gavin Deane |
|
| Back to top |
|
|
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: Comment on style |
|
|
Gavin Deane wrote:
| Quote: | Aaron Graham wrote:
The problem with the "every brace gets its own line" philosophy is that
reading the code requires a lot more scrolling. It's extremely
aggrivating trying to figure out a piece of code where half of all the
lines are just braces, because there's never very much information on
one page.
And yet ...
The problem with the "every brace on the code line" philosophy is that
reading the code requires a lot more scrutiny. It's extremely
aggravating trying to figure out a piece of code where all the vertical
whitespace has been removed, because there's always too much
information on one page.
It really is just a matter of personal preference. What makes it harder
for you to read the code makes it easier for me, and vice versa. I
don't think that says anything about our relative abilities as
programmers.
|
I find it easier to establish where a block is as opposed to the the
statement that 'starts' it.
if (xxx) {
code
codesnthasonethua
aoeuaeou
}
is rather agrivating to read; the separation betweer "if..." and "code"
just isn't adiquate. In coding standards where I have to put the { on
the line with the if I go ahead and hit enter twice.
If you really want to save vertical space why not write it all on one
damn line anyway?
if (xxx) { code; codesntoheustnah; aeouaoeu; }
There, no waste of vertical space :p |
|
| Back to top |
|
|
Roland Pibinger
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: std::string performance (Sun implementation) |
|
|
On Fri, 27 Jan 2006 13:40:47 GMT, "Daniel T." <a (AT) b (DOT) c> wrote:
| Quote: |
The C++ standard does not specify the complexity of basic_string
operations, as such there is no guarantee that std::string will be as
fast as using a C char*.
|
Right, std::string is under-specified. That forces users to program
against a concrete string implementation, not against an interface.
Should you return a string by value? Depends on the implementation.
What is the performance of vector<string>? Depends on the
implementation.
| Quote: | Of course, this also means you can implement your own string classes and
have them conform to the standard rather easily. Back when I first
started using string classes, the popular thing to do was to use
reference counting internally,
|
The most important design decision is whether copying and assignment
should be 'cheap' or 'expensive'.
| Quote: | lately most strings are implemented
basically like a vector<char>, one could however implement it in terms
of a deque<char>.
|
deque<char> is an interesting idea, albeit .c_str() could become
expensive.
| Quote: | What is it you do with your strings in your program? In most programs,
different string like objects are used in different ways; some must be
able to resize, some are always a fixed size but must be able to mutate
their contents, and some always have a fixed size and fixed contents.
Some must be able to efficiently handle insertions in the middle (more
efficiently than vector<char>.
A reasonably large company with very tight performance requirements
would be best served by having several different string implementations,
using std::string for everything would probably not be the best choice;
nor would just using C char* for everything.
|
Well said! Call them (immutable) String, StringBuilder, and
(stack-based) Buffer.
Best regards,
Roland Pibinger |
|
| Back to top |
|
|
Daniel T.
Guest
|
| Posted: Fri Jan 27, 2006 9:32 pm Post subject: Re: class design question |
|
|
In article <xxtCf.116$s9.70 (AT) bignews8 (DOT) bellsouth.net>,
mickey <miguelportillaATpobrosDOTcom (AT) ignore (DOT) this> wrote:
| Quote: | Jay Nabonne wrote:
On Thu, 26 Jan 2006 22:10:13 -0800, WittyGuy wrote:
Actually, on embedded devices, a lot of dynamic memory usage can be a
detriment - you may eventually fragment the (relatively small,
non-virtual-memory) heap, resulting in system failure. Not to say dynamic
allocations are bad; you just have to be careful about what you're doing.
(I'm a little unclear on the "most effective way of using memory" comment,
but we don't really have to go there.)
- Jay
Completely true and that is one of things I try to avoid, memory
fragmentation, which can be the cause of failure in an embedded device.
Most desktop developers seem to have little understanding of that.
But having the static member array also requires a larger contiguous
memory chunk as opposed to the dynamic allocation scheme.
|
Those of use who used to program for MacOS 9 and earlier know full well
about memory fragmentation. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
