Warp wrote:

> std::string someText(1000, ' ');
> someText += "Hello";
> someText.at(10) = 'A';
> 
> std::vector<int> anArray(1000);
> anArray.at(10) = 5;
> 
> std::vector<std::string> anArrayOfStrings(1000);
> anArrayOfStrings.at(10) = "Hello";
> 
> std::cout << someText << "\n" << anArrayOfString.at(10) << "\n";
> 
>   Lots of dynamically allocated data, no pointers anywhere.

So what's the lifetime of the data? The scope of the variable?

As I say, my major problem with C is that as soon as you need anything 
other than an int or a char, you start getting segfaults. (By the way... 
char, unsigned char, long char... WTF?)

>> Regarding rule 4... does this mean C++ at least manages to provide some 
>> standard containers *other* than arrays?
> 
>   Dynamically allocated vectors, strings, doubly-linked lists, binary trees
> (as sets, multisets, maps and multimaps) and double-ended queues. None of
> them requiring any pointers or 'new' to use. (The upcoming C++ standard
> will also include hashmaps as a new data container.)

Well that's something then.

>>> These rules should be broken only when you get very fluent
>>> with the language and know what you are doing.
> 
>> But you can 100% guarantee that any code you read that was written by 
>> somebody else will be full of such exceptions. ;-)
> 
>   Don't make the same mistakes as others.

But surely if I make whole *new* mistakes, nobody will have already 
worked out a solution for me? ;-)

(Only kidding...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> Warp wrote:

> >   The basic design principle in C++ is that you don't have to pay for
> > what you don't use.
> > 
> >   C++ supports dynamic binding if you need it, but it's not shoved down
> > your throat by force.

> I prefer the Eiffel way, where the compiler looks at your program and 
> automatically decides which things can be bound statically (with all the 
> optimisations that follow), and which things actually require dynamic 
> binding.

  That's incompatible with precompiled and dynamically loadable libraries.

  I have always wondered why so many "fancy" languages seem to completely
disregard the idea of dynamically loadable libraries. The idea with them
is that the OS loads them only *once* into memory for all programs to use.
For example, linux (afaik) loads libc.so only once into memory, and all
the myriad of programs which require libc.so use that single copy in memory
rather than each one loading it separately. (Given that libc is something
like 2 megabytes in size and the amount of programs depending on it and
running at any single time in a typical system is counted on the hundreds,
that's a significant memory usage saving.)

  Of course it makes the size of the executable files smaller (because
libc and other standard libraries don't need to be linked into them),
saving disk space (and making loading times faster).

> Does it actually build a seperate copy of the function for each data 
> type, or just build one generic version that works with all of them?

  How could it use one generic function for all possible data types,
given that the data types can have different sizes and even have completely
different implementations for their operators, etc?

  One common misconception people have about templates is that they
increase the size of the executable because the functions are created
for each used type. However, this is only true in some cases.

  In many cases, however, template functions actually *reduce* the size
of the executable. If you have 20 regular functions somewhere, and you
call only one of them, all the 20 will nevertheless be compiled in the
object file. Then it's up to the linker to remove the ones which are not
called at all. Many linkers don't do this (eg. the gcc linker doesn't),
and those unused 19 functions will be linked into the executable,
incrementing its size, even though they are not used.

  If they were template functions, however, the ones which are never
called are never instantiated. No trace of them whatsoever will be
compiled into the object file nor the executable file. They just don't
exist. Thus they don't increase the size of the executable, unlike
regular unused functions do.

  Inlining can also help reducing the size of the executable, besides
making the program faster.

  The great thing about templates is that the compiler is able to optimize
the code on a per-type basis. For example, if you sort an array of integers,
the compiler will most probably be able to compile each comparison into
a CPU register comparison opcode. If you sort an array of strings, then
it will have to perform a string comparison function call. However, the
original sorting function code was the same. Templates just allow the
compiler to perform better optimizations based on the type.

> >   Yes, debug checks are nice. They are nicer if you can turn them off
> > for a final release.

> There is certainly something to be said for that.

> The problem is that, certainly with C anyway, there's no switch to turn 
> it ON in the first place. :-(

  It depends on the compiler. Some compilers do insert checks in debug
mode.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> So what's the lifetime of the data? The scope of the variable?

  Yes.

-- 
                                                          - Warp

Post a reply to this message

Orchid XP v8 wrote:
> Really? There isn't some iPhone SDK that just gives you an emulator?

Yep. I think it's installed as an addon to Xcode (Mac's IDE). Only works on
Intel Macs running OS X Leopard.

Or, you can use unofficial SDKs (someone even ported gcc to run *on* the
iPhone), but then you don't get a simulator, or proper documentation, etc.

Post a reply to this message

Invisible wrote:
> Haskell is a small, simple, logical language. C++ is a huge, messy,
> complex language. I don't see how learning an easy language should
> enable me to learn a hard language.

Don't state that as a fact. I looked at Haskell once, only shortly because
it looked like a big hairy mess.

Probably because I didn't look for long enough.

Go look at C++ for long enough.

Post a reply to this message

Invisible wrote:
> Wait... you mean they made it a class?

Want the technicality?

std::string is not a class. It's a typedef for std::basic_string<char>,
which is a template for a class.

...but pretend it's just a class to avoid an early headache...

Post a reply to this message

Orchid XP v8 wrote:
>>> The macro preprocessor?
>> 
>>   You usually don't need it in C++.
> 
> Well, from what little I've seen, you "usually" don't need it in C
> either. Unless you want symbolic constants...

const int FOO = 42;

Post a reply to this message

Warp wrote:
>> (And that you can *query the size* of an array?)
> 
>   Getting the size of a vector, string, deque and binary tree is O(1).
> (For doubly-linked lists it's not guaranteed.)

And libstdc++ developers decided to keep list::size as O(n) as a tradeoff
(otherwise mutating operations would have to keep the size up-to-date,
making *them* slower).

Post a reply to this message

>> If you can learn an obscure language like Haskell, you can learn C++.
>
> I see. And what do you base this observation on?
>
> Haskell is a small, simple, logical language. C++ is a huge, messy, 
> complex language. I don't see how learning an easy language should enable 
> me to learn a hard language.

Heh, Haskell looks complicated and hard to learn to me. I guess it's 
relative to your current experience. I just think that if you have the brain 
to understand all of the constructs Haskell provides and why they're cool or 
interesting, you have the capability to do the same with any other language, 
especially a commonly used one.

> I already *know* Java. ;-)

Oh; aren't there Java programming jobs around?

>> Why don't you put the time into it?
>
> What makes you think I haven't?

The fact that you haven't learned C++ yet. =)

> Actually, at college we spent a whole semester programming in C. I'm sure 
> I've recounted the tale before. Basically C is a language designed for 
> experts. If you do something dumb, it will make absolutely no attempt to 
> save you. It will just merrily produce garbage, and leave you with no hope 
> of finding out why. Apparently there are people who know the Secret 
> Techniques for debugging C programs, and even writing C programs that are 
> correct in the first place - but this wasn't part of the syllabus.

Well, aside from having a good debugger, you just need to be honest with 
yourself about what parts of your program you do or don't understand. If 
it's not working right, then there must be something about it that you don't 
understand, and you need to identify what it is. Prints help with that (If 
you're using C++ and not just C, then use cout for simplicity) because they 
let you confirm that any given part of the program is working the way you 
expect. If you have to ask questions to understand something, pile up a list 
and ask them here once in a while. Just be honest with yourself about it: 
don't let yourself gloss over an expression that you may have seen somewhere 
but only partially understand. That's the sort of thing that will hurt you. 
Understand every character of every line in every program you write.

And of course, getting started is always hard. It took me at least two 
attempts (separated by learning other languages like JavaScript and VB) to 
learn C++.

> As I say, the trouble is that if your program doesn't work, there is no 
> way you can ever find out why.

Honestly, binary search with prints works in a lot of cases. If you know 
what the program is supposed to do, then you can identify the places it does 
something wrong.

> (Especially if you're using something like OpenGL. It's an extremely 
> complicated API, and unless you pay money it's not possible to get hold of 
> useful documentation.)

OpenGL can be difficult because if you do something wrong it will sometimes 
silently fail. And yeah, it's hard to get good documentation (I learned it 
by taking a class), but it's fun once you can use it so it may be worth 
buying a book on.

Ultimately my point is this: I think you *can* learn it, and if you're 
looking for a good programming job, I think you have a lot to gain by doing 
so.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

> Manual memory management?

Less necessary in C++ than in C, with all the container STL libraries 
around. When you do need it, I find new and delete to be more intuitive than 
malloc and free.

> Pointers vs references?

References are easier than pointers and there's not too much to learn to use 
them. C only has pointers.

> Copy constructors and assignment constructors?

These can be difficult. They do mirror concepts used in C though.

> The macro preprocessor?

I think that's more of a C thing than a C++ thing, though it's available in 
both.

> Method overrides that don't actually override unless you insert special 
> code?

I'm with Warp on this one: what?

> Templates?

They can cause some difficulties. But they can make your life a lot easier 
too (STL again).

> Untrapped numeric overflows?

I think C and C++ both have this property. In practice you barely ever have 
to worry about it.

> Unchecked array indicies?

Also a C and C++ thing. If you want your array indices checked, and you're 
using the std::vector class, you can use the vector.at(index) function. (In 
practice though, I usually just add my own asserts.)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message