Через try не нужно проверять, исключения вещь полезная, и в некоторых случаях необходимая, но оборачивать каждую строчку try-ем не стоит, не очень быстро работать будет.
На вскидку, Edges - это ваши списки смежности, т.е. Edges[v] это список вершин, смежных с v. Соответственно, этот массив надо заполнить перед запуском сортировки.
Затем, после обработки, результат можно будет увидеть в map-е Numbers. Структуры Stack и Color по-видимому следует инициализировать дефолтовым конструктором. Теперь укажите, с какого места вам непонятно. Разумеется, как уже сказал brainick, сначала разберитесь с понятиями теории графов, которыми пользуетесь.
DISaccount а чего им быть если вручную задекларены fooA и fooB в начале файла :). По теме: такие определения (которые внутри cpp и не должны быть видны за его пределами) надо оборачивать в анонимный неймспейс. Этот неймспейс будет свой для каждого из файлов, и коллизий не будет, сколько классов с одинаковыми именами не создавай. А так лично я проблемы не вижу в двух одинаково названных утилитарных классах, если их использование ограничено одним cpp
> статическая переменная класса
> находиться на стеке
как уже было сказано, это утверждение неверно. Статические переменные (что объявленные в классе, что внутри функции) имеют время жизни, независимое от стека. Вот локальные да, они находятся на стеке. Перечитайте еще раз источник или приведите цитату из него.
Соглашусь, что с ORM-кой проще, но если это в учебных целях, то пусть лучше сначала сам напишет пару INSERT-ов. Мапперы добавляют уровень абстракции, и если чтото идет не так, нужно понимать что происходит под капотом...
Ну в общем-то это вопрос стилистический и важен он конкретно в вашей ситуации. Это здесь у вас получилось так, что все, начиная от подключения и заканчивая ридером вы создаете в рамках одной функции и тут же их "выбрасываете". В более сложном приложении одна команда может быть использована и более одного раза, поэтому весь этот код уже не будет сосредоточен в одной функции. Впрочем, и тут вы можете разбить код, например, так:
using (SqlConnection con = ...)
{
List students = QueryStudents(con);
}
а в функции QueryStudents уже создавать команду и ридер. Если подобных функций будет несколько, то все эти using-и уже не смотрятся излишними)
опишите подробнее, это .Net приложение или же нативное. Тогда уже вам смогут посоветовать более конкретно, т.к. за "dll-кой" может скрываться и то, и другое
опишите что конкретно вас не устраивает в ресайзенных формах? если речь о кнопках Обновить и Добавить - возможно оттого, что у них и у лейбла "Папка с мангой.." разные предки, попробуйте поместить в одного, чтобы лейбл было всегда видно. Весь ресайз вертится вокруг политик размеров и лейаутов, например чтобы один элемент был всегда одной ширины, а другой тянулся, то их можно поместить в грид, и первой колонке грида указать размер "1", второй - "*", и тогда первая колонка будет постоянного размера, а вторая - ресайзиться, и т.д.
Посоветовать конкретно по libgd не могу, но думаю надо поискать, нет ли в этой библиотеке возможности назначать "прозрачный" цвет при сохранении в гиф (это скорее всего будет настройка для всего изображения в целом). В гиф, в отличие от того же PNG, нет полноценного альфа канала для каждого пикселя, в нем только один конкретный цвет можно задать как прозрачный. Тогда вы сможете залить нужные места каким-либо "ненужным" цветом и выдать его за прозрачный.
А в C++ были события?
Через try не нужно проверять, исключения вещь полезная, и в некоторых случаях необходимая, но оборачивать каждую строчку try-ем не стоит, не очень быстро работать будет.